Linux-Development-Sys Digest #268, Volume #8 Thu, 9 Nov 00 13:13:14 EST
Contents:
Re: syslog() in kernel module (Nick Maclaren)
Re: nanosleep in kernel code (Kasper Dupont)
Re: syslog() in kernel module (Alexander Viro)
Re: harddisk and partitions (Kasper Dupont)
Re: syslog() in kernel module (Nick Maclaren)
Re: non-portable port (Kasper Dupont)
Re: non-portable port (Alexander Viro)
Documentation needed ("niko")
Was: Software RAID ("U. Siegel")
Re: Software RAID (Lee Allen)
Adding /proc entry - how hard? (Ian Pilcher)
Re: Kernel module to send ethernet frame ?? ([EMAIL PROTECTED])
Re: non-portable port (Erik Hensema)
SoundMax on motherboard support problem (aslin)
Re: Adding /proc entry - how hard? (Grant Edwards)
Re: nanosleep in kernel code - SOLVED! (Tux)
Re: mmap() vs. lseek() on /dev/mem (Gary Parnes)
Re: DVD-RAM support in Linux for reading/writing data (Moritz Franosch)
Re: syslog() in kernel module (Pete Zaitcev)
Re: Was: Software RAID (Lee Allen)
Re: Software RAID ("Block Iron & Supply Co - CIS")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Nick Maclaren)
Subject: Re: syslog() in kernel module
Date: 9 Nov 2000 10:31:36 GMT
In article <8ucmdh$s3j$[EMAIL PROTECTED]>,
Jeff Andre <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>: How can I use syslog in the kernel module?
>
>: The followinng piece of code: syslog(3,message,strlen(message));
>: seems to has no effect... What's wrong?
>
>System calls in kernel space isn't usually (ever?) what you
>really want to do. Why not use printk().
No, absolutely not. They are precisely what you WANT to do, if you
are thinking in a nice, clean, recursive virtual system fashion.
But Unix has never supported that model, and you don't go there
starting from here.
So the fundamental fault of the programmer is in thinking in terms
of a system model that corresponds to another class of systems.
But that shouldn't stop him WANTING the more general model :-)
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: [EMAIL PROTECTED]
Tel.: +44 1223 334761 Fax: +44 1223 334679
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: nanosleep in kernel code
Date: Thu, 09 Nov 2000 11:36:59 +0100
[EMAIL PROTECTED] wrote:
>
> You can also use select(2) for millisecond timeouts:
>
> struct timeval timeout = { SECONDS, MILLISECONDS };
> select (0, NULL, NULL, NULL, &timeout);
>
> This isn't necessarily less complex, but it is at least reasonably
> portable.
>
[...]
Is it posible to call select in kernel mode?
Even if it is it is probably not a good idea.
I think mdelay exist in all Linux ports. And
kernel code does not have to be portable
between different OS.
--
Kasper Dupont
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: syslog() in kernel module
Date: 9 Nov 2000 05:46:39 -0500
In article <8udue8$mvk$[EMAIL PROTECTED]>,
Nick Maclaren <[EMAIL PROTECTED]> wrote:
>>: The followinng piece of code: syslog(3,message,strlen(message));
>>: seems to has no effect... What's wrong?
>>
>>System calls in kernel space isn't usually (ever?) what you
>>really want to do. Why not use printk().
>
>No, absolutely not. They are precisely what you WANT to do, if you
>are thinking in a nice, clean, recursive virtual system fashion.
>But Unix has never supported that model, and you don't go there
>starting from here.
It would be really impressive if not for the inconvenient detail:
syslog(3, buffer, size) _reads_ from the log into buffer. So I'm somewhat
at loss - just what kind of effect was expected? Besides, buffer should
_not_ be in the kernel space - do_syslog() verifies that. Reason: otherwise
any user could overwrite arbitrary parts of the kernel.
syslog(2) is _not_ a function for writing into the log. syslog(3)
is, but it has no business being anywhere near the kernel.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: harddisk and partitions
Date: Thu, 09 Nov 2000 11:56:52 +0100
MESMEUR Philippe wrote:
>
> Josef Moellers wrote:
[...]
>
> I want to write a C-Program that needs to know all hard-disk on the
> current system and all partitions in each hard-disk;
> I can write a function that reads /proc/partitions or maybe, if it
> exists, I can use a function that does the same.
>
> Sorry if it was not clear.
> thanks to answer me
>
Reading /proc/partitions probably is the easiest way to get
the information. There probably exist code to parse this file,
but finding it might not be easy.
Using fdisk -l does not work unless you are root, and might be
less portable than using /proc/partitions.
--
Kasper Dupont
------------------------------
From: [EMAIL PROTECTED] (Nick Maclaren)
Subject: Re: syslog() in kernel module
Date: 9 Nov 2000 11:09:46 GMT
In article <8udvaf$[EMAIL PROTECTED]>,
Alexander Viro <[EMAIL PROTECTED]> wrote:
>In article <8udue8$mvk$[EMAIL PROTECTED]>,
>Nick Maclaren <[EMAIL PROTECTED]> wrote:
>>>: The followinng piece of code: syslog(3,message,strlen(message));
>>>: seems to has no effect... What's wrong?
>>>
>>>System calls in kernel space isn't usually (ever?) what you
>>>really want to do. Why not use printk().
>>
>>No, absolutely not. They are precisely what you WANT to do, if you
>>are thinking in a nice, clean, recursive virtual system fashion.
>>But Unix has never supported that model, and you don't go there
>>starting from here.
>
> It would be really impressive if not for the inconvenient detail:
>syslog(3, buffer, size) _reads_ from the log into buffer. So I'm somewhat
>at loss - just what kind of effect was expected? Besides, buffer should
>_not_ be in the kernel space - do_syslog() verifies that. Reason: otherwise
>any user could overwrite arbitrary parts of the kernel.
>
> syslog(2) is _not_ a function for writing into the log. syslog(3)
>is, but it has no business being anywhere near the kernel.
Not in the model that I am referring to. In that model, there is
no distinction between an application and an operating system.
All a system call does is make a call to its parent - at ALL levels
except the root kernel.
This model has been experimented with, and has some FANTASTIC
advantages. Consider: provably bulletproof debuggers, chroot
environments, and even language run-time systems. And it makes
kernel development into a routine exercise, no different from
developing any other application ....
But, as I said, however much you may WANT that, you haven't got
it, and you don't start from here if going there.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: [EMAIL PROTECTED]
Tel.: +44 1223 334761 Fax: +44 1223 334679
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: non-portable port
Date: Thu, 09 Nov 2000 12:12:51 +0100
Alexander Viro wrote:
>
[...]
> something... Bugger if I remember. Dunno. One might expect that write(2)
> would do the right thing, BIOS or not. After all, that's what the kernel
> is about - applications have no bloody business running around and calling
> the internal kernel functions, no matter where these functions are stored.
In the design of Linux it has been chosen that
the right thing is to completely ignore the
existing of the BIOS. The BIOS is needed while
loading the kernel, but after that it should
not be used at all. Even the kernel will not
use BIOS calls.
--
Kasper Dupont
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: non-portable port
Date: 9 Nov 2000 06:40:49 -0500
In article <[EMAIL PROTECTED]>,
Kasper Dupont <[EMAIL PROTECTED]> wrote:
>Alexander Viro wrote:
>>
>[...]
>> something... Bugger if I remember. Dunno. One might expect that write(2)
>> would do the right thing, BIOS or not. After all, that's what the kernel
>> is about - applications have no bloody business running around and calling
>> the internal kernel functions, no matter where these functions are stored.
>
>In the design of Linux it has been chosen that
>the right thing is to completely ignore the
>existing of the BIOS. The BIOS is needed while
>loading the kernel, but after that it should
>not be used at all. Even the kernel will not
>use BIOS calls.
Actually, sometimes it will (for extra points list the places where it
happens). Yes, I'm quite aware of the facts mentioned above. I don't know
how it's relevant to the (mis)behaviour of write(2) in DOS, though...
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
Reply-To: "niko" <[EMAIL PROTECTED]>
From: "niko" <[EMAIL PROTECTED]>
Subject: Documentation needed
Date: Thu, 09 Nov 2000 12:36:56 GMT
Hello All!
Could You tell me place where I would find description
about macroses.
For example what this means ?
454 __asm__ __volatile__(APM_DO_ZERO_SEGS
455 "pushl %%edi\n\t"
456 "pushl %%ebp\n\t"
457 "lcall %%cs:" SYMBOL_NAME_STR(apm_bios_entry) "\n\t"
458 "setc %%al\n\t"
459 "popl %%ebp\n\t"
460 "popl %%edi\n\t"
461 APM_DO_POP_SEGS
462 : "=a" (*eax), "=b" (*ebx), "=c" (*ecx), "=d" (*edx),
463 "=S" (*esi)
464 : "a" (func), "b" (ebx_in), "c" (ecx_in)
465 : "memory", "cc");
BR,
niko
------------------------------
From: "U. Siegel" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,alt.linux,comp.os.linux.misc
Subject: Was: Software RAID
Date: Thu, 09 Nov 2000 14:40:40 +0100
Seems to be that there are several people having experience with
software RAID.
So, let's be a bit more detailed.
Since one week i'm trying hard to get RAID5 to work.
The System is a netfinity server with 2 Pentium III/933MHz, 2GB RAM and
5 SCSI hd's. On 4 disk i created identicall partitions, each about 8GB.
The first three shall be for working and the fourth as spare.
Creating the array wasn't a problem, also the mke2fs completed w/o
errors. But when i try to copy some data to the array the system
crashes. All i get are EXT2fs errors in block allocation. This happens
under kernel 2.2.17, 2.2.17, 2.3.40, 2.4.0-test9 and 2.4.0-test10.
Always the same errors.
Is there a trick about ext2fs?? I upgraded to the newest ext2fs-tools,
but no change :..-((
Can anybody help me?
------------------------------
From: [EMAIL PROTECTED] (Lee Allen)
Crossposted-To: comp.os.linux.hardware,alt.linux,comp.os.linux.misc
Subject: Re: Software RAID
Reply-To: [EMAIL PROTECTED]
Date: Thu, 09 Nov 2000 13:45:51 GMT
On Thu, 09 Nov 2000 08:39:44 GMT, "Giampaolo Tomassoni"
<[EMAIL PROTECTED]> wrote:
(SNIP)
>I tried it, but it seems you can create and install only raid0 devices, not
>raid1.
>6.1 has a button with (well, let me remember) I guess 'Raid partition' on
>it. It creates 0xFD partitions, but I recall it wasn't completely working.
(SNIP)
I find that RedHat 6.2 installs, configures and syncs RAID-1 devices
quite nicely. On /boot and / . I have used both the graphical
install and kickstart.
-Lee Allen
------------------------------
From: Ian Pilcher <[EMAIL PROTECTED]>
Subject: Adding /proc entry - how hard?
Date: 09 Nov 2000 15:10:21 GMT
I haven't done any kernel/device driver development before, but I need
to modify an existing device driver module to feed some information back
to a user-level program. To my inexperienced eye, adding a simple /proc
entry that the program can read seems like the best way to do this.
So how hard is this, and is there a tutorial/HOWTO somewhere that can
get me started?
Thanks!
--
========================================================================
Ian Pilcher [EMAIL PROTECTED]
========================================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Kernel module to send ethernet frame ??
Date: Thu, 09 Nov 2000 15:07:33 GMT
In article <8ud6b8$bjs$[EMAIL PROTECTED]>,
William Huang <[EMAIL PROTECTED]> wrote:
>
> I am a newbie to kernel module programming, I want to write a
kernel module to send ethernet frames. My question is that how do I
create a raw socket and open a file in the kernel module ? Where can I
find any example source code ??
> thanks :)
One way to send ethernet frames is to put the frame in a sk_buff socket
buffer (skb) ; set the skb->dev field to the ethernet driver (e.g skb-
>dev = dev_get("eth0") ) and then call the kernel function
dev_queue_xmit which will pass it to the ethernet driver.
Sylvie
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Erik Hensema)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: non-portable port
Date: Thu, 9 Nov 2000 13:55:13 +0100
Reply-To: [EMAIL PROTECTED]
Alexander Viro ([EMAIL PROTECTED]) wrote:
>In article <[EMAIL PROTECTED]>, Kasper Dupont
><[EMAIL PROTECTED]> wrote:
>>Alexander Viro wrote:
>>[...]
>>> something... Bugger if I remember. Dunno. One might expect that
>>> write(2) would do the right thing, BIOS or not. After all, that's
>>> what the kernel is about - applications have no bloody business
>>> running around and calling the internal kernel functions, no matter
>>> where these functions are stored.
>>In the design of Linux it has been chosen that the right thing is to
>>completely ignore the existing of the BIOS. The BIOS is needed while
>>loading the kernel, but after that it should not be used at all. Even
>>the kernel will not use BIOS calls.
>Actually, sometimes it will (for extra points list the places where
>it happens). Yes, I'm quite aware of the facts mentioned above. I
>don't know how it's relevant to the (mis)behaviour of write(2) in DOS,
>though...
The usual BIOS calls you make under DOS are impossible in a 32-bit
operating system like Linux. Simply because the bios is 16 bit. So the bios
isn't ignored, it just cannot be used. It's quite useless anyway ;-)
Linux does make calls to the PCI bios and APM bios. These bioses can be
called from 32-bit code.
--
Erik Hensema ([EMAIL PROTECTED])
Please note that my From: field is spamtrapped.
------------------------------
From: aslin <[EMAIL PROTECTED]>
Subject: SoundMax on motherboard support problem
Date: 9 Nov 2000 15:41:06 GMT
Hello,
Can anybody help me with sound card (on motherboard :(
model SoundMax; under
+Windows on other machine it uses irq 11 at 0x8800 and MPU-401 irq 10 at
+0x330; sndconfig doesn't recognize it as PnP
(Pay aNd Pray) or PCI device
+under Red Hat 6.0, kernel 2.2.14 ..
I reconfigured my kernel with sound support but I have no idea which
cards (modules) choose... or shall I use isapnp tools insted ?
Thanks :)
--
---------------------------
Szczepan Konieczny
IBM AS/400 & Linux
DB2/400 & C/C++ & JAVA & ILE RPG/400
Neural Networks & Genetic Algorithms
OpenGL Primer
e-mail: [EMAIL PROTECTED]
---------------------
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: Adding /proc entry - how hard?
Date: Thu, 09 Nov 2000 15:43:13 GMT
In article <[EMAIL PROTECTED]>, Ian Pilcher wrote:
>I haven't done any kernel/device driver development before, but I need
>to modify an existing device driver module to feed some information back
>to a user-level program. To my inexperienced eye, adding a simple /proc
>entry that the program can read seems like the best way to do this.
>
>So how hard is this, and is there a tutorial/HOWTO somewhere that can
>get me started?
If you limit yourself to 1 page (4K on x86) of data, it's quite
simple. See _Linux_Device_Drivers_ by Rubini, or just look at
another driver for an example.
--
Grant Edwards grante Yow! WHY are we missing
at KOJAK?
visi.com
------------------------------
From: Tux <[EMAIL PROTECTED]>
Subject: Re: nanosleep in kernel code - SOLVED!
Date: Thu, 09 Nov 2000 16:49:08 +0100
Hey together!
Thanks for helping me with my problem. I found a solution using mdelay
and udelay. :-)
Tux
------------------------------
From: Gary Parnes <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: mmap() vs. lseek() on /dev/mem
Date: Thu, 09 Nov 2000 10:37:00 -0600
Spam Me Not wrote:
> It doesn't work because /dev/mem explicitly disallows it:
> from /usr/src/linux/drivers/char/mem.c:
>
> static ssize_t read_mem(struct file * file, char * buf,
> 99 size_t count, loff_t *ppos)
> 100 {
> 101 unsigned long p = *ppos;
> 102 unsigned long end_mem;
> 103 ssize_t read;
> 104
> 105 end_mem = __pa(high_memory);
> 106 if (p >= end_mem)
> 107 return 0;
> [snip]
> This means that you can't read any values with physical addresses higher
> than the largest physical
> regular RAM address in the system. Most if not all bus addresses usually
> are mapped above
> the end of physical RAM in the system in most bus architectures, including
> PCI.
>
> You could write your own "/dev/mem"-like device that doesn't have this line
> in it and it should probably
> work fine. You may have to be careful about issuing memory barriers for
> your device driver to work
> correctly, depending on your particular CPU, chipset, and, device
> characteristics.
Mmmmmm, when I remove the range check, copy_to_user() chokes, and I get an
EFAULT.
I guess there are subtleties of the Linux MMU that are going over my head. In
any case, thanks for the pointer. It was worth a shot...
--Gary Parnes
[EMAIL PROTECTED]
------------------------------
From: Moritz Franosch <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: DVD-RAM support in Linux for reading/writing data
Date: 09 Nov 2000 18:10:37 +0100
[EMAIL PROTECTED] (Blaise Canzian) writes:
> Is there support in Linux for reading and writing data (not movies,
> music, etc.) to DVD-RAM?
Yes, for SCSI.
> Is this kernel support?
Yes.
> Is the support harware specific (Sony, Hitachi, Panasonic, etc)?
As far as I know no. DVD-RAMs are simply changeable SCSI disks. They
should be recognized correctly as CD-ROMs _and_ changeable SCSI disks
at the same time, however.
But there have been some issues depending on the hardware.
We have a TOSHIBA DVD-RAM SD-W1111 that works without any problems
with kernel 2.2.14. (I haven't tried write protection.)
Moritz
------------------------------
From: [EMAIL PROTECTED] (Pete Zaitcev)
Subject: Re: syslog() in kernel module
Date: Thu, 09 Nov 2000 17:49:13 GMT
>[...]
> >>No, absolutely not. They are precisely what you WANT to do, if you
> >>are thinking in a nice, clean, recursive virtual system fashion.
> >>But Unix has never supported that model, and you don't go there
> >>starting from here.
> >
> > It would be really impressive if not for the inconvenient detail:
> >syslog(3, buffer, size) _reads_ from the log into buffer. So I'm somewhat
> >at loss - just what kind of effect was expected? Besides, buffer should
> >_not_ be in the kernel space - do_syslog() verifies that. Reason: otherwise
> >any user could overwrite arbitrary parts of the kernel.
> >
> > syslog(2) is _not_ a function for writing into the log. syslog(3)
> >is, but it has no business being anywhere near the kernel.
>
> Not in the model that I am referring to. In that model, there is
> no distinction between an application and an operating system.
> All a system call does is make a call to its parent - at ALL levels
> except the root kernel.
>
> This model has been experimented with, and has some FANTASTIC
> advantages. Consider: provably bulletproof debuggers, chroot
> environments, and even language run-time systems. And it makes
> kernel development into a routine exercise, no different from
> developing any other application ....
When Nick posts stuff like the above, he asks for a discussion
akin to one that happened between Linus Torvalds and Andy
Tannenbaum about the merits of microkernel.
Both Al and I understand one's longing for homogenous application
anvironment which allows syslog(3) in kernel. Is it not a pretty, eh?
Unfortunately, it belongs to an ivory tower. Think about following
small detail: every API pyramid must be supported by some foundation.
Call calls as much as you want, but eventually something needs to do
the action you are asking. Such as writing into a log file. Since
the log file is a shared resource, one cannot let applications
manipulate it directly. This calls for a crossing of a protection
boundary with a hardware support.
The thinking along these lines caused "ringed" protection systems
to be invented, such as Multics (and 80286). As a veteran of
comp.arch Nick must remember why they were not practical:
they were inflexible. Software structure resembles a Russian doll
only in small minds [for horror example, think of OSI 7 layer model].
The next step was to realize that we would rather need a web of
trust or some call or class graph and to provide for that.
Intel 432 and microkernels were the most obvious failure on that front.
So, by the reason of the intrinsic difference between "unprotected"
and "protected" programming models we have the arrangement of the
kernel and userland. All we can do is to strive for the right balance.
If we let kernel grow too much, it loses stability. If it shrinks
too much it loses speed. Of course, it is good to have a critical
mind to think of alternatives. But not a single practical one was
found so far.
--Pete
------------------------------
From: [EMAIL PROTECTED] (Lee Allen)
Crossposted-To: comp.os.linux.hardware,alt.linux,comp.os.linux.misc
Subject: Re: Was: Software RAID
Reply-To: [EMAIL PROTECTED]
Date: Thu, 09 Nov 2000 17:50:12 GMT
On Thu, 09 Nov 2000 14:40:40 +0100, "U. Siegel"
<[EMAIL PROTECTED]> wrote:
>Seems to be that there are several people having experience with
>software RAID.
>So, let's be a bit more detailed.
>Since one week i'm trying hard to get RAID5 to work.
>The System is a netfinity server with 2 Pentium III/933MHz, 2GB RAM and
>5 SCSI hd's. On 4 disk i created identicall partitions, each about 8GB.
>The first three shall be for working and the fourth as spare.
>Creating the array wasn't a problem, also the mke2fs completed w/o
>errors. But when i try to copy some data to the array the system
>crashes. All i get are EXT2fs errors in block allocation. This happens
>under kernel 2.2.17, 2.2.17, 2.3.40, 2.4.0-test9 and 2.4.0-test10.
>Always the same errors.
>Is there a trick about ext2fs?? I upgraded to the newest ext2fs-tools,
>but no change :..-((
>Can anybody help me?
>
How about posting your /etc/raidtab and /proc/mdstat files,
ideally after mkraid.
-Lee Allen
------------------------------
From: "Block Iron & Supply Co - CIS" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,alt.linux,comp.os.linux.misc
Subject: Re: Software RAID
Date: Thu, 9 Nov 2000 12:08:20 -0600
I had that problem once. I believe the problem had to do with the
controller BIOS being setup for Microsoft OShit.
"U. Siegel" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Seems to be that there are several people having experience with
> software RAID.
> So, let's be a bit more detailed.
> Since one week i'm trying hard to get RAID5 to work.
> The System is a netfinity server with 2 Pentium III/933MHz, 2GB RAM and
> 5 SCSI hd's. On 4 disk i created identicall partitions, each about 8GB.
> The first three shall be for working and the fourth as spare.
> Creating the array wasn't a problem, also the mke2fs completed w/o
> errors. But when i try to copy some data to the array the system
> crashes. All i get are EXT2fs errors in block allocation. This happens
> under kernel 2.2.17, 2.2.17, 2.3.40, 2.4.0-test9 and 2.4.0-test10.
> Always the same errors.
> Is there a trick about ext2fs?? I upgraded to the newest ext2fs-tools,
> but no change :..-((
> Can anybody help me?
>
------------------------------
** 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 (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
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
******************************
