Linux-Development-Sys Digest #791, Volume #8 Fri, 15 Jun 01 15:13:19 EDT
Contents:
Re: Kickstart from within Linux? (Kasper Dupont)
Re: changed section attributes for .modinfo (Kasper Dupont)
Re: pause the bootup (Aravindh)
configure the kernel for a serial console (Aravindh)
Re: VFS and mount (Petric Frank)
Re: PCI device register access (Grant Edwards)
Re: VFS and mount (Alexander Viro)
Looking for Security / Kernel level programmers in the BOSTON area for an innovative
SECURITY PRODUCT (Sagi)
Re: Supervising non-child processes w/wo procfs (Jeremiah DeWitt Weiner)
Re: How many CPUs can linux support? (Jeremiah DeWitt Weiner)
pwdb ("Alexis D.")
Re: PCI device register access (Kaelin Colclasure)
Re: PCI device register access (Kaelin Colclasure)
Re: Matt Blaze's CFS on Linux - readdir problem. (Kevin Buhr)
Re: PCI device register access (Kaelin Colclasure)
Re: pwdb
Re: PCI device register access (Grant Edwards)
Module zombies (Clifford Kite)
Re: lilo.conf append syntax ("D. Stimits")
----------------------------------------------------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Kickstart from within Linux?
Date: Fri, 15 Jun 2001 14:11:32 +0000
Wilfred Dee wrote:
>
> Is there any way possible to start Kickstart from within Linux? The
> reason I ask is because I need to run a script that determines some
> system information which is used to start Kickstart with a particular
> config file. I have to do it this way because I need to retrieve some
> information stored in the Non Volatile RAM and use that to determine
> which Kickstart config file to use. In the past I used a DOS boot
> disk and ran a script which in turn ran loadlin with the appropriate
> config file to start the Kickstart process. Is it possible to start
> Kickstart from within Linux? If not, is there any other way to work
> around the problem?
I think monte is the utility you are looking for
<URL:ftp://www.scyld.com/pub/monte/>
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: changed section attributes for .modinfo
Date: Fri, 15 Jun 2001 14:15:08 +0000
Massimiliano Caovilla wrote:
>
> Hi,
> as I stepped from kernel 2.14 to 2.16 (RedHat 6.2 to 7.0)
> When I compile some modules that I'm developing I get a weird warning,
>
> Assembler message:
> Ignoring changed section attributes for .modinfo
>
> Has anyone any hint where to look to get rid of this?
> It only happens to files that include module.h
>
> Ciao & thanks
>
> Massimiliano
I have seen that message lots of times, but it
doesn't seem to do any harm, the module still
works.
(If that is your only problem under RH7.0 you
are indeed a very lucky person.)
--
Kasper Dupont
------------------------------
From: [EMAIL PROTECTED] (Aravindh)
Subject: Re: pause the bootup
Date: 15 Jun 2001 07:21:39 -0700
> If your system has a serial port, try configuring your kernel for a serial
> console. Also, change the printk buf to not be static so you can look to see
Yes, my system has a serial port. But do you know what I need to
modify in the kernel to get it configured as a serial port?
Thanks
Aravindh
------------------------------
From: [EMAIL PROTECTED] (Aravindh)
Subject: configure the kernel for a serial console
Date: 15 Jun 2001 07:24:14 -0700
Hi,
I am trying to get Linux running on a proprietary system. My system
has a serial port. Is there anyway to configure the kernel for a
serial console?
Thanks
Aravindh
------------------------------
From: Petric Frank <[EMAIL PROTECTED]>
Subject: Re: VFS and mount
Date: Fri, 15 Jun 2001 16:51:16 +0100
Reply to my own post ...
Petric Frank schrieb:
>
> Hello Alexander,
>
> Alexander Viro wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > Petric Frank <[EMAIL PROTECTED]> wrote:
> >
> > >But how is Samba doing it ?
> > >As i digged out recently you can do a
> > > mount -t smbfs //MACHINE/SHARE <mount point>
> >
> > Do strace on it. You'll see that it's special-cased in mount - it
> > calls a separate helper (mount.smb) which passes it in the same
> > way normal mount would pass -o <options>.
>
> Thanks.
> I'll have a look to the mount source. I've seen a file named mount.smbfs
> which does the mount for samba.
> Maybe there is a generic rule in mount to call mount.<filesystem> if
> available ...
The generic rule is indeed the one i thought above.
mount is searching for a /bin/mount.<filesystem> file and if it is there
he calls it.
Here (in my distribution) it calls in case of samba the script
mount.smbfs which calls smbmount.
This one converts the parameters and calls smbmnt.
smbmnt does a system call mount (see man 2 mount) which passes in the
first parameter '//MACHINE/SHARE' (as like the original mount does).
Here i am stuck actually. I was not able to find the source of this
function. Is there anyone here in this echo which can give me a hint
where to find it ?
regards
Petric
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: PCI device register access
Date: Fri, 15 Jun 2001 15:07:25 GMT
In article <[EMAIL PROTECTED]>, Kaelin Colclasure wrote:
>At the moment, my interpretation of the HW spec leads me to
>believe this particular PCI device maps its registers both into
>IO space and into PCI memory. Is that typical?
It's not ununusual, but it's not universal either.
>Assuming the registers *can* be accessed either way, would it
>not make sense to prefer the memory mapped access, as that is
>supported on all platforms?
Memory mapped access is usually simpler from a programmatic
point of view. One sometimes handy thing you can do is allow
the memory block to be mmap()ed. You can also treat the block as
a struct, and that simplifies source code.
>And if the answer to this rhetorical-looking question is indeed
>``yes'' then why do none of the existing drivers I've looked at
>do it this way? Every single driver seems instead to define its
>own private set of inb/inw/inl and outb/outw/outl macros, to
>handle making memory references on platforms with no IO space
>and byte-swapping on big-endian platforms. Is this just an
>artifact of their age/heritage?
Yes.
>And finally, if the practice above is so common, why doesn't Linux have
>a standard set of macros for this somewhere? [Or why don't people use
>them?]
Good question.
--
Grant Edwards grante Yow! I'm protected by
at a ROLL-ON I rented from
visi.com AVIS...
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: VFS and mount
Date: 15 Jun 2001 11:16:55 -0400
In article <[EMAIL PROTECTED]>,
Kasper Dupont <[EMAIL PROTECTED]> wrote:
>> Currently - nowhere. IOW, you can't use it. It will change in 2.5.early,
>> but that requires API change.
>>
>
>Since it does show up in /proc/mounts it must
>exist somewhere.
Sure. In struct vfsmount. Which is unavailable when superblock is read.
For damn good reasons.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (Sagi)
Subject: Looking for Security / Kernel level programmers in the BOSTON area for an
innovative SECURITY PRODUCT
Date: 15 Jun 2001 08:53:27 -0700
Email:
[EMAIL PROTECTED]
------------------------------
From: Jeremiah DeWitt Weiner <[EMAIL PROTECTED]>
Subject: Re: Supervising non-child processes w/wo procfs
Date: 15 Jun 2001 16:50:09 GMT
Guido Ostkamp <[EMAIL PROTECTED]> wrote:
> within a process I want to supervise a large number of other processes,
What exactly do you mean by "supervise"?
> In SystemV based systems this can be solved easily, you just have to
> open /proc/<pid> for each process and select/poll on the file
> descriptors. Whenever a process dies, the supervising process is
> informed by kernel and returns from the select/poll.
...because it sounds like you mean "wait for it to die". And it just
so happens that I recently wrote a program to do this. Of course, my
solution was "stat /proc/<pid> && sleep", so it's not quite the way you
specify, but, as Linus said, it wins on points of being available now!
I assume you have looked at the way some SysV systems do it - I just
did a truss of pwait on a Solaris 7 system, and saw this
open("/proc/14956/psinfo", O_RDONLY) = 3
poll(0x100102A60, 1, -1) (sleeping...)
poll(0x100102A60, 1, -1) = 1
close(3) = 0
so it works the way you describe. The Linux and Solaris poll man
pages make them look reasonably similar. You've tried it and it didn't
work?
JDW
------------------------------
From: Jeremiah DeWitt Weiner <[EMAIL PROTECTED]>
Subject: Re: How many CPUs can linux support?
Date: 15 Jun 2001 16:55:54 GMT
Phil Ehrens <[EMAIL PROTECTED]> wrote:
> The 2.2.X series kernels had some strange problems with processes
> hopping about among cpu's which was not nice.
You can still do something similar, I think, by nicing a cpu-intensive
process. I've noticed on my dual-processor machine that a non-niced hog
tends to stay on one processor (due to soft affinity, I suppose), but a niced
one gets kicked off by less nice processes, forcing it to jump back and forth.
I don't know if that should really be considered a _problem_, but it's
interesting to observe.
JDW
------------------------------
From: "Alexis D." <[EMAIL PROTECTED]>
Subject: pwdb
Date: Fri, 15 Jun 2001 21:11:17 +0400
Hello.
My question would seem stupid and/or off-topic, but could anyone please tell
me where is the home site of the pwdb library?
I just can't find the 'original' one, and I have to get it from various
distributions.
Where is its main distribution point.
Any help will be appreciated.
(Yes, I know I'm lame :)
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Subject: Re: PCI device register access
Date: 15 Jun 2001 10:07:31 -0700
"Lee Ho" <[EMAIL PROTECTED]> writes:
> Kaelin Colclasure Wrote:
> >I am taking my first crack at writing a HW device driver, and I am a little
> >confused over the distinction between IO mapping and memory mapping of my
> >PCI card's register space.
> >
> >At the moment, my interpretation of the HW spec leads me to believe this
> >particular PCI device maps its registers both into IO space and into PCI
> >memory. Is that typical? [If it matters, the card is a Symbios SCSI host
> >controller.]
>
>
> Yes. PCI device can have PCI I/O space and PCI memory space, and
> typically use I/O space for register, and memory space for data.
> But many device map their register into memory space. Perhaps
> Symbios SCSI host controller (like LSI Logic NCRxxxx) maps register into
> I/O space, and script area into memory space.
>
> >Assuming the registers *can* be accessed either way, would it not make
> >sense to prefer the memory mapped access, as that is supported on all
> >platforms? And if the answer to this rhetorical-looking question is
> >indeed ``yes'' then why do none of the existing drivers I've looked at
> >do it this way? Every single driver seems instead to define its own
> >private set of inb/inw/inl and outb/outw/outl macros, to handle making
> >memory references on platforms with no IO space and byte-swapping on
> >big-endian platforms. Is this just an artifact of their age/heritage?
>
>
> It's just the choice of the hardware developer. And AFAIK, I/O space is
> mapped into memory area in which system does not support I/O port,
> so it doesn't make problem.
Hmmm, so you're saying that, e.g. the Sparc port of linux still
defines x86-style inb/outb APIs, so that a driver that uses them on
Intel architectures ``just works'' on the Sparc too?
> >And finally, if the practice above is so common, why doesn't Linux have
> >a standard set of macros for this somewhere? [Or why don't people use
> >them?]
>
>
> Linux defines standard APIs. There is inb()/inw()/inl() and oub()/outw()/outl()
> for accessing I/O space, ioremap() function for mapping I/O memory space
> into virtual memory, and readb()/readw()/readl()/readq(),
>writeb()/writew()/writel()/writeq()
> for accessing memory space.
And these ``do the right thing'' on processors that don't implement a
separate I/O space? This would seem to make sense -- but then why do so
many drivers go to such lengths to distinguish between architectures and
to define their own private APIs?
> >-- Kaelin
>
> *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
> Lee, Ho. Software Engineer, Embedded Linux Dep, LinuxOne
> Mail : [EMAIL PROTECTED] (work), [EMAIL PROTECTED] (personal)
> Homepage : http://flyduck.com, http://linuxkernel.to
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Subject: Re: PCI device register access
Date: 15 Jun 2001 10:09:07 -0700
<[EMAIL PROTECTED]> writes:
[...]
> The book "PCI System Archtecture" is really good at explaining how PCI
> devices work. You might want to pick up a copy of it if you wish to get
> deeper into PCI.
I just picked up a copy. Thanks for the info and the recommendation!
-- Kaelin
------------------------------
From: [EMAIL PROTECTED] (Kevin Buhr)
Crossposted-To:
comp.os.linux.security,comp.os.linux.misc,comp.os.linux.development.apps
Subject: Re: Matt Blaze's CFS on Linux - readdir problem.
Date: 15 Jun 2001 12:20:21 -0500
[[ Followup-to: comp.os.linux.security,comp.os.linux.development.apps ]]
"Binesh Bannerjee" <[EMAIL PROTECTED]> writes:
>
> Have you done much with cattach -l ? Do you know how that works?
"-l" suppresses the creation of what Matt calls perturbation vectors.
A perturbation vector is randomly generated for each newly created
file, and it's XORed against each plaintext block before encryption.
The perturbation vector is then stored in a symlink:
.pvect_<<name of encrypted version of file>>
whose value is the hex representation of the vector. If a file "xxx"
has no associated ".pvect_xxx", the perturbation vector is taken to be
all zero.
The nature of the ECB+OFB encryption scheme used in CFS means that two
files in the same CFS filesystem with the same perturbation vector
value (which will always be zero if you use "-l") will encrypt
plaintext blocks having the same value and located at the same offset
within a file to the same ciphertext.
For example, try:
cattach -l /some/cfs/filesystem x
cd /crypt/x
echo 12345678abcdefghx2345678 >1
echo x2345678abcdefgh12345678 >2
Note that the first and third 64-bit blocks differ between the two
files, but the second 64-bit block of these two files is the same. If
you compare the encrypted versions of these files, you'll discover
that the second 64-bit blocks of the two encrypted files are the same.
The rest of the blocks will all be different.
An attacker could use this to discover which encrypted files had
common headers or, perhaps, to decrypt certain common blocks at some
positions. If the attacker can trick you into storing certain files
(like a large file of all NULLs or files of the repeated string
"Istanbul" at various offsets), he or she can locate chosen
8-character strings in your files.
Dropping "-l" and using pvects prevents this attack.
If you want more information about this, your best bet is to post a
question to "sci.crypt".
> Basically, with cattach -l after I add enough directory entries,
> the _entire_ directory becomes invisible... (There still there, just
> ls or find, whatever won't find them, but you can cd to the directories,
> vi files etc.)
It's probably a different problem, since the bug I described should
always return at least one page of files for a directory read.
I'm not familiar enough with the CFS code to answer your other
question, though.
Kevin <[EMAIL PROTECTED]>
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Subject: Re: PCI device register access
Date: 15 Jun 2001 10:24:01 -0700
[EMAIL PROTECTED] (Grant Edwards) writes:
> In article <[EMAIL PROTECTED]>, Kaelin Colclasure wrote:
>
> >At the moment, my interpretation of the HW spec leads me to
> >believe this particular PCI device maps its registers both into
> >IO space and into PCI memory. Is that typical?
>
> It's not ununusual, but it's not universal either.
>
> >Assuming the registers *can* be accessed either way, would it
> >not make sense to prefer the memory mapped access, as that is
> >supported on all platforms?
>
> Memory mapped access is usually simpler from a programmatic
> point of view. One sometimes handy thing you can do is allow
> the memory block to be mmap()ed. You can also treat the block as
> a struct, and that simplifies source code.
Hmmm, but don't you still have to access it with readb, etc. rather than
e.g. just dereferencing a pointer to a struct? And wouldn't this break
mmap'ing (not that I need to try that -- just trying to get a grasp on
this stuff)?
Assuming that a given set of PCI registers ``goes both ways'', is there
any performance reason to prefer one method over the other? E.g. does
readb use more or fewer cycles than inb?
> >And if the answer to this rhetorical-looking question is indeed
> >``yes'' then why do none of the existing drivers I've looked at
> >do it this way? Every single driver seems instead to define its
> >own private set of inb/inw/inl and outb/outw/outl macros, to
> >handle making memory references on platforms with no IO space
> >and byte-swapping on big-endian platforms. Is this just an
> >artifact of their age/heritage?
>
> Yes.
>
> >And finally, if the practice above is so common, why doesn't Linux have
> >a standard set of macros for this somewhere? [Or why don't people use
> >them?]
>
> Good question.
:-) The folklore is that Linux is a great platform for learning this
stuff because the source to so many drivers is collected for easy
perusal. But it seems this is mitigated by the fact that many of these
drivers have accumulated a great deal of redundant cruft as a result
of a) being originally ported from a different Unix variant or b)
evolving through several Linux kernel epochs (and many suffer from
both).
And then there is legacy ISA/EISA support, etc. Sigh.
Can anyone point me to a low-level SCSI driver that:
a) Supports only PCI
b) Actually uses the PCI support in the 2.4 kernel as it was intended
c) Actually uses the SCSI mid-layer and new-style error handling
???
-- Kaelin
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: pwdb
Date: Fri, 15 Jun 2001 18:12:26 -0000
In article <9gdfjb$19ks$[EMAIL PROTECTED]>, Alexis D. <[EMAIL PROTECTED]> wrote:
>Hello.
>My question would seem stupid and/or off-topic, but could anyone please tell
>me where is the home site of the pwdb library?
>I just can't find the 'original' one, and I have to get it from various
>distributions.
>Where is its main distribution point.
>Any help will be appreciated.
>(Yes, I know I'm lame :)
Try writing the authors:
7. Comments/bug reports and fixes are welcome.
Please send email to [EMAIL PROTECTED] & [EMAIL PROTECTED] .
--
http://www.spinics.net/linux/
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: PCI device register access
Date: Fri, 15 Jun 2001 18:16:27 GMT
In article <[EMAIL PROTECTED]>, Kaelin Colclasure wrote:
>> In article <[EMAIL PROTECTED]>, Kaelin Colclasure wrote:
>>
>> >At the moment, my interpretation of the HW spec leads me to
>> >believe this particular PCI device maps its registers both into
>> >IO space and into PCI memory. Is that typical?
>>
>> It's not ununusual, but it's not universal either.
>>
>> >Assuming the registers *can* be accessed either way, would it
>> >not make sense to prefer the memory mapped access, as that is
>> >supported on all platforms?
>>
>> Memory mapped access is usually simpler from a programmatic
>> point of view. One sometimes handy thing you can do is allow
>> the memory block to be mmap()ed. You can also treat the block as
>> a struct, and that simplifies source code.
>
>Hmmm, but don't you still have to access it with readb, etc.
>rather than e.g. just dereferencing a pointer to a struct?
There may be some systems (Alpha?) where you have to use
readb() et al to access the PCI bus. On Wintel machines, you
can just dereference a pointer if you want to sacrifice
portability for simplicity.
>And wouldn't this break mmap'ing (not that I need to try that
>-- just trying to get a grasp on this stuff)?
Yes, it would break the "simple" method of mmap()ing if you had
to use readb(). There's a more complicated way (which I've
never seen actually implimented) that could be used to mmap()
I/O or other non-main-memory space.
>Assuming that a given set of PCI registers ``goes both ways'', is there
>any performance reason to prefer one method over the other? E.g. does
>readb use more or fewer cycles than inb?
Don't know.
>> >And finally, if the practice above is so common, why doesn't Linux have
>> >a standard set of macros for this somewhere? [Or why don't people use
>> >them?]
>>
>> Good question.
>
>:-) The folklore is that Linux is a great platform for learning this
>stuff because the source to so many drivers is collected for easy
>perusal. But it seems this is mitigated by the fact that many of these
>drivers have accumulated a great deal of redundant cruft as a result
>of a) being originally ported from a different Unix variant or b)
>evolving through several Linux kernel epochs (and many suffer from
>both).
>
>And then there is legacy ISA/EISA support, etc. Sigh.
Yup.
--
Grant Edwards grante Yow! I am having a
at CONCEPTION--
visi.com
------------------------------
From: Clifford Kite <[EMAIL PROTECTED]>
Subject: Module zombies
Date: Fri, 15 Jun 2001 13:12:07 -0500
Linux kernel 2.4.5-ac9
I have an HP 315 camera with a USB connector and can copy the pictures
on it's CompactFlash card from a directory using cp, after mounting
/dev/sda1 as a msdos filesystem. The connection to /dev/sda1 is created
by inserting the modules usb-uhci.o, usb-storage.o, and sd_mod.o with a
modprobe -a, turning on the camera, and, of course, mounting /dev/sda1.
After copying the pictures and umounting /dev/sda1, a lsmod shows no
module being used, but then after removing the modules with modprobe -r
a ps auxw shows this:
root 2985 0.0 0.0 0 0 ? Z 12:07 0:00 [usb-storage-0 <defunct>]
root 2986 0.0 0.0 0 0 ? Z 12:07 0:00 [scsi_eh_0 <defunct>]
Is this normal?
If it is not normal then I'd appreciate a pointer to documentation
that explains how to avoid creating these zombies, and/or some simple
explanation as to why it is happening.
N.B. The zombies that are created as described above may not be
specific to this particular kernel. I've copied pictures from the
camera before using the 2.4.1 and 2.4.3 kernels but haven't used it
very much until recently.
Thanks!
--
Clifford Kite <Email: [EMAIL PROTECTED] with X=kite, Y=inetport, Z=com>
/* Microsoft is a great marketing organization.
* It _has_ to be */
------------------------------
Date: Fri, 15 Jun 2001 12:51:58 -0600
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: lilo.conf append syntax
Kasper Dupont wrote:
>
> D. Stimits wrote:
> >
> > I'm trying to figure out the correct means to append two things to the
> > kernel boot parameters. For a while I have been using:
> > append="noapic"
> >
> > (due to i840 chipset design flaws of APIC)
> >
> > Now I'm converting some items (XFS filesystem) over to use as module, in
> > order to make a bootable floppy (it is too large without making it a
> > module), and I need to bring up the default ramdisk size, so I am using
> > this:
> > append="ramdisk_size=25000 noapic"
> >
> > Is the space between "ramdisk_size=25000" and "noapic" the correct
> > syntax (this works without error running lilo, but fails when it comes
> > time to use the module)? I have seen commas, but these were always used
> > for multiple arguments to a single parameter, not multiple parameters. I
> > need to verify that I can enter two kernel boot options in the way I
> > have, or else find the correct syntax.
> >
> > D. Stimits, [EMAIL PROTECTED]
>
> I have experienced problems when trying to use an
> initial ramdisk larger than 4MB. I don't know if
> this problem is related to the loader or the kernel.
>
> --
> Kasper Dupont
Thanks to people who answered. The space worked well.
As to the 4 MB limit, that is what the "ramdisk_size=25000" is for...it
ups the size to around 24 MB (25000 KB). Floppies (at least a single
floppy) can't handle the compressed version, it exceeds 1.44 MB. There
are some patched utilities to attempt writing 1.6 to 1.7 MB to a floppy,
but I don't trust the floppy quality to use this as a regular means of
emergency rescue. Anyway, initial ramdisk larger than 4 MB does seem to
work for me, but this would fail on floppy (I'm using hard drive). I
found that if I first increased initial ramdisk to about 8 meg, it would
want about 30 bytes more; I kept increasing it about 1k at a time. At
around 16 meg, it still always wanted about 30 bytes more than I gave
it. I finally just bumped it up to 24 MB, and it worked (this was the
recommended size of an SGI HOWTO for XFS filesystem...which by the way
is awesome). I found some instructions and utilities for creating boot
and rescue systems based on 2 or more floppies, which I have not yet
tried out, but will be using that to create floppies in pairs ("yard" if
anyone cares).
D. Stimits, [EMAIL PROTECTED]
------------------------------
** 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: [EMAIL PROTECTED]
You can send mail to the entire list by posting to the
comp.os.linux.development.system newsgroup.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
