Subject: Linux-Development Digest #536
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Thu, 10 Mar 94 15:13:11 EST

Linux-Development Digest #536, Volume #1         Thu, 10 Mar 94 15:13:11 EST

Contents:
  Re: Help! GCC errors (Ron Smits)
  I'm developing UMSDOS Linux Pkg. (Whitstler)
  Re: Specialix driver (Nick Simicich)
  Re: ROMmable Linux? (Andre Skarzynski)
  Re: UDP report card (Alan Cox)
  Re: Amiga FileSystem, Anyone? (Alan Cox)
  Re: eth0: transmit timed out in PL15h (Christopher Samuel)
  Re: Amiga FileSystem, Anyone? (David Holland)
  Re: TTY overruns cost money. (Ken Pizzini)
  Re: AMD 486DX problem (with Linux?) (Wen-Chun Ni)
  Re: UDP report card (Alan Cox)

----------------------------------------------------------------------------

From: ron@draconia.hacktic.nl (Ron Smits)
Subject: Re: Help! GCC errors
Date: 8 Mar 1994 08:28:18 GMT

Rob Janssen (rob@pe1chl.ampr.org) wrote:
: In <dgardnerCM5sLs.HD6@netcom.com> dgardner@netcom.com (Dave Gardner) writes:

: >Dean Junk (us292121@bulldog.mmm.com) wrote:
: >: Take this as you wish ... piss off!  I can't beleive the attitude of some
: >: of the people on this newsgroup.

: >Dean, you're not alone.

: >I started using Linux about a year ago with SLS, before I and many others
: >knew just how broken it was. Many of us had lots of problems and asked
: >lots of questions, most answered much the same way as you got here. 
: >Rather than politely either answer the question, or point out where the
: >answer might be found, many Linux 'experts' chose to instead wield their
: >often questionable wit to insult.  And nobody, expert or newbie, likes to
: >be insulted; it has nothing to do with the thickness of the skin. 

: You must have missed that this newsgroup is about "Ongoing work on the
: Linux operating system", not about asking questions.  That largely explains
: the attitude towards people asking questions anyway, especially when they
: are so clearly answered in the read.me file that came with the package
: that they are asking about...

: Rob
: -- 
: -------------------------------------------------------------------------
: | Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
: | e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
: -------------------------------------------------------------------------

--

This may sounds strange, but I have to agree with everybody here:
 - This is col.development, the charter says development concerning the
   kernel. 
 - The answer is in the readme file and you should read it,really, It is
   vitally important, because messing up your shared libs, messes up your
   system (I just answered several posts to people who lost their links)
 - Oldies (so-called `experts') should be more polite and tolerant. Over the
   last few weeks many a flame war started because of unfriendly replies.
   But, the amount of articles seem to grow exponentially more then 400 
   articles yesterday!! I keep my articles for two weeks and du tells
   me that comp/linux/* -s 9 Megs!!!! So maybe some of the oldies are getting
   tired of seeing the same questions coming up again and again. 

I think that oldies, newbies and so-called `experts' should keep answering
questions as much as they can politely, and keep pointing the people, politely
to the correct FAQ, HOWTO and readmes. If a FAQ howto or readme is not clear
then tell the developer/maintainer. Tell him politely and exactly (as much as 
possible what you think is incorrect or incomplete, this way the faq can 
improve so other newbies will not have to ask questions and the oldies or 
so-called `experts' won't flamethrow the newbie




                Ron Smits
                ron@draconia.hacktic.nl
                Ron.Smits@Netherlands.NCR.COM

/*-( My opinions are my opinions, My boss's opinions are his opinions )-*/
/*-(                They might not be the same                         -*/


------------------------------

Crossposted-To: comp.os.linux.misc
From: slouken@talbot.cs.ucdavis.edu (Whitstler)
Subject: I'm developing UMSDOS Linux Pkg.
Date: Wed, 9 Mar 1994 19:45:47 GMT


        I need some feedback from all you folks in the Linux
community.

        I'm impressed with the cabability of UMSDOS to run
Linux in the MSDOS filesystem, and intrigued by the possibility
of "drop-in" linux for the PC.

        The problem with most of the current distributions is
that they are too big and comprehensive for the "drop-in"
Linux concept.  There is also no current way to easily install
them onto the UMSDOS filesystem.

        What I'm working on is a package that will fill 
these gaps:

Version 1:      A generic mini-linux with full X and networking
                but fine tuned for the new shared libraries and
                kernel.  It won't have lots of obscure and
                duplicated binaries like SLS.  It will follow 
                the new Filesystem Standard, for the most part.
                I'm shooting for about a 50 Meg installation.

Version 2:      My own personal customized system; this one, based
                on Version 1.  It will have lots of cool stuff 
                installed, such as dosemu, ghostscript, customized
                X startup, gcc commpilers, full manpages,  etc.

Version 3:      A miniature drop-in Linux for anyone who wants
                to quickly convert an existing DOS system into 
                a fully networked, X workstation.  It will fit
                into 25 Megs, including swap and boot setup.


One of the advantages of this concept is that if you don't like
Linux when you set it up, it is trivial to remove it from your
DOS filesystem.  If you like it, it is just as trivial to install
more functionality and eat up your existing DOS installation.

        When I first installed the umsdos distribution,
I ran into problems with corrupt filesystems because of the
distributed init/shutdown procedure.  I switched to the new
System V init package (2.5) and that fixed those problems.
Since then I have not had chkdsk report any problems. (Even
after a crash)

        Hats off to the developers of UMSDOS!

My distribution would not be based on any current distributions,
and I'm hoping to have it available as a base installation in
pkzip files, and then tar files that will install similarly to
SLS.  By building it from scratch, I'll be able to avoid the
feeping creaturism that seems to be in some of the other
releases and adhere to the new standards that are coming out.
(No flames to other dists intended)  I'll also be able to 
strip some of the packages (such as groff) into the necessary
parts.  My philosophy is get rid of everything, see what breaks
and then put back the parts that are necessary.  I've gotten
full X and networking into 20 Megs.  In the process, I've learned
a heck of a lot about the way Linux systems are put together. :)


I have a couple of questions for you folks on the net.  

1.  What do you think about this idea?  Would you be willing to
    beta test it?  Are there any developers out there with some
    suggestions on the best way to put this together?

2.  How do I set up a LILO disk?  I'm trying to put a UMSDOS
    aware kernel onto a floppy containing a mini filesystem,
    similar to the way SLS does it.  Anybody know how to do
    that? 

3.  For the zip distribution, is there any dos archiver similar
    to tar?  Pkzip doesn't seem to have the functionality I 
    need to zip files and subdirectories from widely varying
    parts of a filesystem into a single zip file and then 
    unzip them into the proper places.  Would it be worth it
    to get GNU tar and gzip for dos and use that for the dist?

4.  On a different note, I noticed that when using pl15h, I 
    have no problems when mounting a UMSDOS filesystem as the
    root filesystem, but when I use pl15j, the system randomly
    crashes.  (EIP: 0010:00000000)  I've been hanging out with
    pl15h, but it would be nice to upgrade to the latest 
    kernel.

Well, thanks all you crazy Linuxers. :)

        -Sam



------------------------------

Crossposted-To: gnu.misc.discuss
From: njs@scifi.uucp (Nick Simicich)
Subject: Re: Specialix driver
Date: Thu, 10 Mar 1994 07:46:48 GMT

In article <CLvBp5.Csv.3@cs.cmu.edu>, Doug DeJulio <ddj+@cs.cmu.edu> wrote:
>In article <2kp8ai$i0@ifi.uio.no>,
>Kjetil Torgrim Homme <kjetilho@ifi.uio.no> wrote:
>>+--- Doug DeJulio:
>>| Why should I, as a simple computer hobbyist, care if Linux ever does
>>| this?  I'm more concerned with making sure *I* have the source code
>>| to everything I can possibly get the source code for.
>>+-------
>>
>>So _you_ would never buy a Specialix product, or if you did, you would
>>start working on a free driver.  If we get commercial companies to
>>develop drivers _in_addition_ to all the voluntary work, we will all
>>benefit.
>
>Please explain -- how will *I* benefit?

Well, because then you would have the ability to use a Specialix card
to download all of the stuff you could have source for.  Other people
would be able to use things like Specialix cards, and this would mean
more use (and therefore more development) in Linux.

I believe that the next generation of personal modems will be in
almost exactly this predicament: You will get a card with a lot of DSP
power, some external interfaces for things like Microphones, phone
lines, and the like, and some ram.  What you have the card do will be
solely dependent on what programs are loaded onto the card.  You could
load a V.17 fax program onto the card.  Or a V.32bis modem code.  Or a
V.34 modem code (when that is available).  Or an echo-cancelling
speakerphone that can run full duplex without feedback.  And so forth.

Mail order prices on cards that can do this stuff are in the $238
range, right now.....

If you try to GPL code that is simply loaded onto the DSP boards
because someone wrote a driver to squirt the code on to the DSP, then
no one will write that driver, and you won't have the services of
those boards available.  You will lose.

Look, there is proprietary code, and there is GPL'd code, and there is
free code.  You decide which you want on your box.  Frankly, the
politics matter little to me.  My hope is that people would get the
development kits for the DSP cards and hack GCC to do code generation
for DSP's (you can now tell that I know nothing about DSP programming)
and write some free or GPL'd signal processing applications that
everyone could use and learn from, and make DSP programming available
to a lot more folks, and so forth.  But if you treat this code much
differently than code that comes on a ROM, you are only going to hurt
Linux.

Right now, there are major development projects whose goal it is to
make it possible for binary only software to run on Linux.  The WINE
folks, the folks who are doing ELF and COFF support all seem to have
that as a goal.  You benefit by being able to use software you
otherwise couldn't use.


-- 
Nick Simicich - njs%scifi.uucp@uunet.uu.net - njs@watson.ibm.com

------------------------------

From: abs@cs.sun.ac.za (Andre Skarzynski)
Subject: Re: ROMmable Linux?
Date: 10 Mar 1994 12:03:44 GMT

Uri Blumenthal (uri@watson.ibm.com) wrote:
: Hi,
:       Some time ago there was a discussion here about
:       how possible it was to make embedded Linux...

Hi, I am also interested in getting involved in an embedded Linux.

--
Andre B. Skarzynski  -- Information Technology, University of Stellenbosch --
abs@itu1.sun.ac.za   ------- Tel: +27 21 8084293 Fax: +27 21 8084102 --------

------------------------------

From: iiitac@swan.pyr (Alan Cox)
Subject: Re: UDP report card
Date: Thu, 10 Mar 1994 11:48:45 GMT

In article <2ll2hd$6q1@access3.digex.net> christop@access3.digex.net (Chris Anderson) writes:
>My code hashes on addresses.  Because the addrlen returned from recvfrom
>includes the pad at the end of inet addrs, my hash function hashes on it.
>The code in inet/udp.c doesn't zero the pad, so I get stack garbage.
>
Quick test shows:
1. The pad is included in the length
2. BSD zero's the pad
3. WinSockAPI stuff I tried, our SYSV box and a PC DOS stack also return
the full size with the pad area randomised.

If it worries you you can add

        memset(sin.sin_zero,'\0',sizeof(sin.sin_zero));
        
wherever you need it (ie tcp/udp/raw recvfrom()). I'm not sure its a good
idea to fix this in general since it would be better to hash by address
components for portability.

I'm open to suggests why I should fix it, but adding yet another 100 bytes
to the kernel for one incredibly trivial BSD side effect does seem 
dubious.

Alan
iiitac@pyr.swan.ac.uk



------------------------------

From: iiitac@swan.pyr (Alan Cox)
Subject: Re: Amiga FileSystem, Anyone?
Date: Thu, 10 Mar 1994 12:27:25 GMT

In article <2lkoeo$55r@infosrv.edvz.univie.ac.at> cprakt2@acpx5.exp.univie.ac.at () writes:
>In article <1994Mar3.174849.2359@swan.pyr>, iiitac@swan.pyr (Alan Cox) writes:
>>The amiga floppy is a single sector MFM encoded 80 track double sided disk.
>>It's beyond the standard PC hardware to drive
>>Alan
>
>I would guess from reading what is written on my disk package that PC disks
>have 9 _software_ sectors - it says "soft sectored" - so I don't see the 
>difference here.
>
Ah no. soft-sectored implies there isn't one hoie or sync mark physically
put ont the disk per sector. A PC has 9 independantly written sectors
all aligned relative to the single hole. Each has space before and after
as the controller will always miss by a bit and has preambles to mark each
sector.

The amiga has a single sector that starts wherever it got put and is a track
long (bar a small gap to allow a) for drive tolerance and speed and b)
because nothing handy fitted there). The amiga controller DMA's the entire
sector into memory starting at an arbitary point finds the true start from
the MFM preamble uses the blitter to shift and decode the buffer and answers
the IO request.

Alan


------------------------------

From: chris@rivers.dra.hmg.gb (Christopher Samuel)
Subject: Re: eth0: transmit timed out in PL15h
Date: 10 Mar 1994 12:54:16 GMT

In article <2l58o0$mv7@senator-bedfellow.mit.edu> of comp.os.linux.development,
        nygren@athena.mit.edu (Erik Nygren) doodled:

> Mar  3 11:16:50 foundation kernel: eth0: transmit timed out, \
>       tx_status 00 status 2000.

I'm seeing similar occasional errors when FTPing to a DELL 486DX66 with
a 3COM Etherlink III in it, running the ALPHA-pre-1.0 kernel. They don't
affect performance at all, but I see a much, much stranger problem.

The machine talks quite happily to any machine on the network, apart
from another ALPHA-pre-1.0 machine (Kamco 486DX50) with an NE2000 clone in it,
and similarly that NE2K pre-1.0 refuses to talk to it.

It *WILL* talk to a pl13 machine (another Kamco 486DX50) with an NE2000,
and the pl13 will talk to it quite happily.

Snooping the ethernet from a sun shows that when they try to connect to
each other they broadcast valid ARP requests, but will never answer one
from the other machine. They do answer ARP requests from any other
machine on the net.

I would swap the Etherlink III card for an NE2K clone to see if it makes
any difference, but I can't find any at the moment.

Has anyone seen anything similar, or have a clue they could lend me ?
Cheers,
Chris
-- 
Christopher Samuel                         CSE3 news, mail and systems admin
N-115, Defence Research Agency, St Andrews Road, Great Malvern, England, UK
Phone:  +44 684 895311                              chris@rivers.dra.hmg.gb

------------------------------

Subject: Re: Amiga FileSystem, Anyone?
From: dholland@husc7.harvard.edu (David Holland)
Date: 10 Mar 94 07:11:27


rob@pe1chl.ampr.org's message of Mon, 7 Mar 1994 20:21:12 GMT said:

 > >The network redirector is a mess, not well documented, and notoriously
 > >difficult to cope with. Why do you think we don't see alternate
 > >filesystems (such as for Mac floppies) for the PC that use it? All we
 > >have is a few network packages from big companies with lots of
 > >resources, like Novell and Sun.
 > 
 > Microsoft's policy is to not give out documentation about programming
 > interfaces except the most required ones.  While I agree that this is
 > not good, I don't agree that we don't see alternate filesystems.
 > Linux' dosemu *does* have a filesystem redirector.

Dosemu isn't at all the same thing, because it doesn't have to
actually implement a filesystem from DOS interrupt calls. We don't see
alternate filesystems for *DOS*, which was what I meant.

I believe the original point here was that DOS has no real workable
mechanism for handling alternate filesystems. I don't think the
existence of the network redirector qualifies, because it's obscure,
messy, not necessarily supported, and still limits you to 8+3
character filenames, and various programs randomly don't work with it.

Obviously, you disagree. But I don't see why that should mean I don't
know what I'm talking about.

 > Programs that do only file I/O have no problems whatsoever with redirected
 > drives.  Those that want to be 'clever' will lose.
 > E.g: those stupid N***** tools that insist on scanning the entire

I've seen various programs choke on network drives. I'd expect disk
utilities to, and sure enough most of them do. But various things that
*aren't* disk utilities, or even close, don't work either.
(Admittedly, these are rarer now that DOS networks are fairly common.)

--
   - David A. Holland          | "The right to be heard does not automatically
     dholland@husc.harvard.edu |  include the right to be taken seriously."

------------------------------

From: ken@halcyon.com (Ken Pizzini)
Subject: Re: TTY overruns cost money.
Date: 9 Mar 1994 16:16:22 -0800

In article <1994Mar7.031529.20875@void.tdcnet.nl>,
Nemosoft Unv. <nemosoft@void.tdcnet.nl> wrote:
>Since Linux 0.99 pl 15, I've seen these messages about 'tty overruns' with a
>number that's the minor of the tty-line. 
[...]
>First, a few observations:
>-overruns seem to be generated when there's heavy diskaccess.
>-also when a second serial line (on a different IRQ, yes) some heavy traffic
> is going on.
>-on my 2400 baud link, the overruns seem to be generated from an endless
> loop, rather than on a 'message per byte' rate.
>
>All serial ports are 16450s. Oh yeah: even with overruns, I don't loose
>data.

For what it's worth:  I too have encountered tty overruns in 0.99p15
that I haven't before.  My clues, in case this is fixable, are:
    The problem was most noticible while moving a large file between
     two physical disks while scrolling text over a V.32/V.42/V.42bis
     modem link.
    I'm using a no-name IDE controller with two 16450-ish serial ports
    I'm using a 386DX40 based processor (7.98 bogoMips)

I realize that using a buffered serial controller (such as one using
the 16550 chip) is the best long-term solution, but as I have been
doing fine with this setup from 0.96 to 0.99p14 I am disinclined to
take such measures just yet.

                --Ken Pizzini

------------------------------

From: wcn@cs.brown.edu (Wen-Chun Ni)
Subject: Re: AMD 486DX problem (with Linux?)
Date: Wed, 9 Mar 1994 19:16:42 GMT

In article <MCKESEY.94Mar8164342@imaphics.prior.com> mckesey@imaphics.prior.com (Gregory McKesey) writes:
>
>I managed to get ghostscript to work by recompiling it with the
>-msoft-float option.  This is not ideal but it works.
>


Weird. I got the newest gs from GNU site and compiled it without
any modification of the file unix*.mak (I don't have my linux
machine around so can't remember). The resulting program works
as before. Don't know what the difference is. 

-- 
Wen-Chun Ni, wcn@cs.brown.edu
===================================================================
  "Great spirits have always encountered violent opposition 
        from mediocre minds..."    -- Albert Einstein

------------------------------

From: iiitac@swan.pyr (Alan Cox)
Subject: Re: UDP report card
Date: Thu, 10 Mar 1994 14:20:35 GMT

In article <2llret$7nt@cmcl2.NYU.EDU> gans@acf2.nyu.edu (gans) writes:
>We've got a situation at NYU where a number of hostile entities 
>regularly broadcast 127.0.0.1 over the local net...  And some
>linux boxes, including mine, respond (which I do not think is
>correct behavior).
>
Linux is correct in answering 127.0.0.1 and complaining that is its
own address. If it worries you comment out the line that prints the
warning. Better still find out who is responsible and tell them to get
it fixed..

Alan
iiitac@pyr.swan.ac.uk




------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************
