Linux-Development-Sys Digest #658, Volume #8 Fri, 20 Apr 01 17:13:12 EDT
Contents:
what is stack now? ("hushui")
Re: A Linux emulator for Linux, does this exist? (Mario Klebsch)
Re: Capturing raw ethernet frames (Mario Klebsch)
Re: Can Linux kernel ported on supercomputer (using 16 processor) (Ed Clarke)
Re: Can Linux kernel ported on supercomputer (using 16 processor) (Joe Pfeiffer)
Re: type of hard disk ("Norm Dresner")
representative SCSI drivers? (Michael W. Godfrey)
Re: IO system throughput ([EMAIL PROTECTED])
Re: Is linux kernel preemptive?? (Greg Copeland)
Re: A Linux emulator for Linux, does this exist? (Jonathan Buzzard)
Re: Is linux kernel preemptive?? (Greg Copeland)
Re: New directions for kernel development ("Igor Shmukler")
Re: Can Linux kernel ported on supercomputer (using 16 processor) (Greg Copeland)
Re: IO system throughput (Greg Copeland)
----------------------------------------------------------------------------
From: "hushui" <[EMAIL PROTECTED]>
Subject: what is stack now?
Date: Fri, 20 Apr 2001 23:42:12 +0800
In head.s ,when enable PG of cr3
/* Set up the stack pointer */
lss stack_start,%esp
...
what is stack now?
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc
Subject: Re: A Linux emulator for Linux, does this exist?
Date: Fri, 20 Apr 2001 19:18:32 +0200
"Peet Grobler" <[EMAIL PROTECTED]> writes:
><SNIP>
>>happen. According to folklore, you can pretty much replace an
>>entire 390 one piece at a time without ever rebooting -- I
>>imagine that's a bit exagerated.
>Yes, I believe you can. If everything in the system is hot-swappable, why
>not?
What about hot-swappable programs?
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: Capturing raw ethernet frames
Date: Fri, 20 Apr 2001 19:28:30 +0200
[EMAIL PROTECTED] writes:
>On Mon, 16 Apr 2001 20:26:06 GMT Grant Edwards <[EMAIL PROTECTED]> wrote:
>|>What if someone wanted to write their own protocol based
>|>on ethernet? How would it be done?
>|
>| You write a driver module that installs a handler for the
>| Ethernet protocol number in question.
>What if they want to do it in a process instead of the kernel,
>in much the same way a serial port protocol implemented in a
>process would start by opening the serial port device.
It all boild down to having user space STREAMS modules :-)
>Again, I still think it would have been more consistent of UNIX
>to have made even network interfaces be devices in the /dev
>directory, with major/minor node numbers and all that. Then
>doing ifconfig would refer to devices by their /dev name, and
>one could simply open() the /dev name for direct access if so
>permitted by the ownership/permission mode bits on the device
>node file.
The semantics of the network devices are so different from the simple
stream of bytes, that this was not done (in UNIX).
>This would make it easier to experiment with new protocols just above
>the interface layer, by using processes.
You are missing one important point: A protocol module does have two
loose ends, one to the network and one on the opposite side, the
client program. So you would need some interface to redirect
socket()-calls to some external user space code.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
------------------------------
From: [EMAIL PROTECTED] (Ed Clarke)
Subject: Re: Can Linux kernel ported on supercomputer (using 16 processor)
Date: Fri, 20 Apr 2001 18:13:07 +0000 (UTC)
On Fri, 20 Apr 2001 14:52:36 GMT, Grant Edwards <[EMAIL PROTECTED]> wrote:
>> My concern is that originally kernel was written for the single processor
>>only so will it work nicely with SMP (16 processor) ??
>> Or we need to change the design of kernel ??
Have you looked at the Beowulf project? That's multiple machines clustered
together that act as a single big machine. The largest cost is probably
for a parallelizing compiler that you'll need to take advantage of this array.
Not a kernel problem at all; all the effort is in user space. Look at
www.scyld.com for more info.
------------------------------
From: Joe Pfeiffer <[EMAIL PROTECTED]>
Subject: Re: Can Linux kernel ported on supercomputer (using 16 processor)
Date: 20 Apr 2001 12:43:49 -0600
[EMAIL PROTECTED] (Ed Clarke) writes:
> On Fri, 20 Apr 2001 14:52:36 GMT, Grant Edwards <[EMAIL PROTECTED]> wrote:
> >> My concern is that originally kernel was written for the single processor
> >>only so will it work nicely with SMP (16 processor) ??
> >> Or we need to change the design of kernel ??
>
> Have you looked at the Beowulf project? That's multiple machines clustered
> together that act as a single big machine. The largest cost is probably
> for a parallelizing compiler that you'll need to take advantage of this array.
> Not a kernel problem at all; all the effort is in user space. Look at
> www.scyld.com for more info.
But his question dealt with SMP (current code word for ``global
memory'') machines. Beowulfs are distributed memory.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
SWNMRSEF: http://www.nmsu.edu/~scifair
------------------------------
From: "Norm Dresner" <[EMAIL PROTECTED]>
Subject: Re: type of hard disk
Date: Fri, 20 Apr 2001 19:40:34 GMT
Alpesh K" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Hi:
>
> Is it possible to find out what type of disk(s) (whether it is IDE/SCSI)
are present on linux system using system call?
> Do I have to write a kernel module for this ? If yes
> what book/document I should read first as I am newbie in kernel
programming.
>
There's a wealth of information in the "files" under /proc. In particular,
/proc/ide and /proc/scsi have separate "directories" for each physical
device and partition. You can read all of this as a user (or a
user-program).
If you do want to write kernel modules, there are many treatises available
on the www. Use any good search engine. The classic book is "Linux Device
Drivers" by Rubini (pub. O'Reilley), but it was written for the 2.0.x
kernels. There are several mediocre web-pages on the differences between
2.0.x and 2.2.x and 2.4.x.
Norm
------------------------------
From: [EMAIL PROTECTED] (Michael W. Godfrey)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc
Subject: representative SCSI drivers?
Date: 20 Apr 2001 19:28:28 GMT
Greetings,
I'm an academic researcher and a Linux user since kernel 0.99pl15.
The Linux source codebase (including drivers) makes an excellent guinea pig
for exploring ideas of how software evolves (Linux is big, in wide use, and
open source so I can look at its internals and publish the results). We've
decided to perform a case study on the evolution of the Linux SCSI drivers
(lotsa drivers largely performing the same tasks).
What I would very much appreciate is any feedback that a knowledgable Linux
"historian" might have on the past, present, and future of SCSI drivers for
Linux (beyond what I can read in the HOWTOs). For example, I'd like to
find out:
-- precisely which of the gazillion drivers (and cards) are in widest
use now and over time (the top ten or so, say),
-- which drivers are basically legacyware,
-- how much code cloning (and hacking) of drivers has occurred (we know
some of this already from having browsed the source, eg several
drivers were cloned from cyberstorm.[ch], which in turn was cloned
from esp.[ch]),
-- which drivers are known to be particularly (un)reliable,
etc.
If anyone out there in Linuxland has decent knowledge of these kinds of
matters and wouldn't mind dropping me an informative missive (on this or
any other topic that seems appropriate), I'd very much appreciate hearing
from you. (And I'll be happy to acknowledge your help in any resulting
publication.)
Thanks.
--
Michael Godfrey PhD, Assistant Professor
Univ of Waterloo, Dept of Computer Science
email: [EMAIL PROTECTED]
URL: http://plg.uwaterloo.ca/~migod
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: IO system throughput
Date: Fri, 20 Apr 2001 20:22:51 +0200
Greg Copeland <[EMAIL PROTECTED]> wrote:
> You are correct. Asynchronous I/O requires both kernel and user app
> support. Right now, all I/O in Linux is synchronous. Meaning, when
> you issue a write, the write does not return until it has been written.
> In this case, written means copied to a buffer (write back) to be
> physically written latter, or physically written now (write through).
> In either case, the application had to wait for the write to complete
> (virtual or physical). In an asynchronous model, the write would
> immediately return with a tagged id. The application doesn't need
> to wait for the write to complete. Behind the scenes, the kernel
> completes the write and notifies the application. The tagged id is
> returned to the application via a callback and/or a signal and a
> function call. This way the application can track which asynchronous
> I/O's have completed and which have not.
> This is great for I/O intensive applications (e.g., databases) because
> they can get onto writing without care and let the asynchronous handler
> take care to error processing. Furthermore, it supposedly allows for
> better gather time in the kernel's I/O because it can collect and order
> I/O without an application having to wait on it to do so. And or course,
> on a very loaded system, the application is waiting for I/O to complete
> (this is the biggest boost), rather, it just keeps on queueing data
> and lets it be notified when they have completed.
> Very cool stuff. NT supports asynchronous file and network I/O. Linux
> does not.
I was suspecting buzzwords in this terminology, and you are explaining us
that it is no more than buzzwords. Suppose that instead of a write, it is a
read. Do you think the application can continue his job without having
effectively completed the read? It will process absent data? As for writes
you know very well that physical writes are deferred in all modern systems
so the IO is in fact done asynchronously. This is the role of interrupts
and dma to cope with that. So you care to say that the write can be virtual.
You think the kernel will spend a lot of time copying buffers? Even that
can be avoided. Buffers can be shared, as exemplified by the UVM system
in NetBSD. So the delays involved here are not significant.
What is significant is the big giant lock that was once around the kernel
on multiproc machines. Then only one proc could run kernel code.
This has been fine grained on recent Linux, and is in the course of being
fine grained in FreeBSD. When all this will be perfectly debugged i doubt
very much that NT will be able to stand the comparison with these systems
even on multiproc boxes.
--
Michel Talon
------------------------------
Subject: Re: Is linux kernel preemptive??
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 20 Apr 2001 15:04:01 -0500
ChromeDome <[EMAIL PROTECTED]> writes:
> Greg Copeland wrote:
> >
> > I will admit that I'm getting into the merky grey area of my
> > Linux kernel understanding, but I believe what I said to be accurate
> > at least to it's broad meaning, if not to the letter.
> >
>
> It's obvious from following this thread that "preemptive" means
> different things to different people. I've been a programmer (mostly
> process control) for almost 50 years, so let me throw in my 2 cents
> worth.
>
> The definition I've always heard used for a "preemptive O/S" has nothing
> to do with processes. It says that kernel services (i.e. system calls)
> must be preemptible, which in practice also implies reentrancy.
>
Thanks for the follow up. I must say that I've never heard anyone assume
that the kernel (in this case, I mean system calls) must be preemptive
for the kernel to be considered to be a preemptive multitasker. Normally,
that is to say, as my experience goes, it simply means that "user" applications
will be preemptively multitasked without the need of the application to
explicately yield slices. This is a stark contrast to cooperative multitasking
(which is clearly not preemptive multitasking) that we all grew to love in
Windows and on Macs. IMOHO, anything beyond what I've described is OS
dependant and does not follow a rule of thumb as far as I know.
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
From: [EMAIL PROTECTED] (Jonathan Buzzard)
Subject: Re: A Linux emulator for Linux, does this exist?
Date: Fri, 20 Apr 2001 20:50:29 +0100
In article <9boqt2$15v$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Philip Armstrong) writes:
> In article <[EMAIL PROTECTED]>,
> Jonathan Buzzard <[EMAIL PROTECTED]> wrote:
>>In article <9bksqf$129$[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED] (Philip Armstrong) writes:
>>> I don't doubt the staff, but I believe the newer ibm mainframes have
>>> much lower power requirements than the old ones used to. They're much
>>> smaller as well...so the serious power and aircon doesn't need to be
>>> quite so serious any more.
>>>
>>> *surf* *surf* Apparently the spiffiest Z-series draws approx 13kW. So
>>> there you go.
>>You can't draw this from a 13amp socket though. I would suspect you
>>need a three phase supply for this beasty. At the very least you are
>>going to need specialist wiring as this is 56A at 230VAC.
>
> I have a single circuit in this house which is rated at 40A (for the
> electric shower says the circuit breaker). I don't think a 56A circuit
> is going to be a problem for any business, and I really doubt the need
> for 3-phase. You will need better than a 13A socket though as you say.
>
> Besides I said lower than the old ones (which certainly did need three
> phase power :) ), not low in absolute terms!
>
Aparantly they do use three phase power supplies though.
JAB.
--
Jonathan A. Buzzard Email: [EMAIL PROTECTED]
Northumberland, United Kingdom. Tel: +44(0)1661-832195
------------------------------
Subject: Re: Is linux kernel preemptive??
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 20 Apr 2001 15:26:04 -0500
Kasper Dupont <[EMAIL PROTECTED]> writes:
[snip]
>
> The problems you describe are related to locking
> granularity not whether the system is preemptive.
> When a process is preempted it is not preempted
> by another process, but by an interrupt. Making
> a system preemptive means you have to ensure two
> things, first that interrupts are not disabled
> for long periodes of time, and second that an
> interrupt can actually result in a process
> switch.
Hmmm....seems like we are saying the same thing. Only you
chose to be more detailed in the implementation details;
which for this conversation I don't feel has significance which
is why I left them out. When a kernel is preemptive (without
regard for the triggering mechanism), it means that a system
call can interrupt another system call; preempt the first
system call prior to it completing. I'm not sure in
what you think that differs from why I described. Now then,
I did proceed to talk about locks which have a direct
bearing on the kernel's ability to be both, reentrant as
well as preemptive. Not sure where I lost you there. Please
remember that system call preemption is not user mode preemption.
It's also important to remember that you can have a reentrant
kernel without having reentrant system calls; that is, multiple
asynchronous kernel entry points without allowing reentrancy in
a common function. Example, A can preempt call B but A can not
be preempted for another call A. This could be by design or
by the required enforcement of lock for resource protection or
even serialization. Long story short, it's hard to talk about
preemption with talking about locking and reentrance. That,
I *think*, is what I illustrated in my example that I snipped
out (as it was long).
>
> Disabling interrupts when running kernel code is
> not bad practice and is seldom a problem. When a
> process spends long time within a sysytem call,
> it is usually because the system call explecitly
> sleeps. Thus we will have interrupts reenabled
> in a short time anyway.
>
Again, not sure where I lost you. I'm pretty sure I
didn't imply that disabling interrupts is a bad thing
in general, however, it is for long periods of time.
Again, I only addressed the distinction between coarse
grain locks and fine grain locks and how it can effect
the ability of a kernel to be reentrant.
> So what we have to look for is not preemption,
> because we already have that, but rather fine
> grained locking. As I understand it 2.4.x is a
> good step in that direction.
Please describe how you have have system call preemption
with coarse grain locks? In short, you can't because
the kernel will be locking out anyone else from attempting
to use the resource. It's hard to have one without the
other which is not what I *think* you seem to be implying.
[snip - kernel locks explained removed]
I just re-read my message and I guess I'm confused, because
I'm not sure how you think you invalidated anything I said.
I do have the impression that you have trouble with the
concept of preemptive multitasking and preempting system
calls. One does not require the other. I'm not trying to
shoot back or anything, I'm just trying to understand the
disconnect here.
Thanks,
Greg
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
From: "Igor Shmukler" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development
Subject: Re: New directions for kernel development
Date: Fri, 20 Apr 2001 20:33:09 GMT
> Linus Torvalds wrote:
> Hi all <blah.blah.blah>
> ------------
>
> Besides the quote from Linus - I question that he wrote the diatribe - but
> much of which was written can be seen in as originating in the university
> subcultures of the uncouth claiming to be intellectual mystics. Many of
the
> divergent philosophies and morally deplorable trappings have made their
> appearances throughout our technocultures since the 60s.
>
> What both Linux and I decry is the promiscuous promulgation of prostituted
> morality and ethics, and to mention uncleanliness of manners and dress.
> We would hope that the open-source community would take pride in the
better
> things in life and bring this uplifted attitude toward our endeavors. We
do
> not like the fruits of our labours being dragged through the trenches of
> debauchery, profanity, and immorality, but would prefeer to see them
proffered
> by caring souls to enlighten the communies of intellectual thinkers and
> problem solvers.
That's many words, but idea is a little slim. You too want to tell people
how to dress. Well, tell it to your kids.
> Many of our corporate bretheren, not barried in the code trenches, but
> responsible for business, finance, and welfare of masses, see significant
> value in products that are presented with dignity. This means that we may
> need to scrub our demeanor and manners and adorn our attire with
cleanliness,
> and the accouterments of respect in order to enhance the dignity and
acclaim
> of our endeavors.
>
> Instead of - Me Too - and likewise thinking , prepare yourselves for a
> change in culture that is required for success in a new age as our labours
> go from obscurity and have to survive in a world of scrutiny and
> visibility. This world is new to many of you and offers little refuge
> for those unwilling to put on cleaner robes.
>
> I am an enthusiastic supporter of the Linux operating system, the GNU
> and open-source unrestricted development philosophies, but perceptions
> need to be improved if our labours are to be embrased by the larger
> world outside of our cloistered computer cathederals and virtual
> realities.
As far as support of open source, I am happy to know that we can count on
guys like you.
If some people have not pulled resources back in the day. RMS would have
finished Hurd by now. But instead it's stuck in Debian's burocracy.
Sometimes best thing to do is just leave it alone. Not that it has anything
to do with anyone.
At least BSD people have some ideas behind words. You lost me here, and
Linus most many in his OS.
> Sincerely,
> Steven J. Hathaway
PS sorry, it's been a few days, but I'm just getting tired of lamers telling
what to wear or like.
------------------------------
Subject: Re: Can Linux kernel ported on supercomputer (using 16 processor)
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 20 Apr 2001 15:33:16 -0500
[EMAIL PROTECTED] (Grant Edwards) writes:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> > Is it possible to port the linux kernel (2.4) to supercomputer consisting
> >of 16 processor or more ??
> > Also can existing kernel is suited for the High Performace Computing ??
>
> It runs on an IBM S/390. That's pretty damn "High Performance"
> compared to what I've got sitting on my desk.
>
> > My concern is that originally kernel was written for the single processor
> >only so will it work nicely with SMP (16 processor) ??
> > Or we need to change the design of kernel ??
I'm really not sure how related the S/390 is to his question. Keep in mind,
as far as I can remember, Linux running on the 390 looks like a uniprocessor
machine, rather, it can support say, 50,000+ uniprocessor machines. This,
I think, is a completely different book than a single machine with 16+
processors because of the overhead in scheduling, etc.
Long story short, last I read, it was thought that Linux would scale well
to 12 or so processors with a steady fall off out to about 16 processors.
After that, either no one really knows it is has, or is thought to, hit
a brick wall. It's important to keep in mind that I'm pretty sure not a
lot of testing has taken place with Linux on more than 4 processors. I
*think* I recall seeing a benchmark on an 8 processor machine (alpha?),
but that may of been the phase of the moon with some expired milk. Don't
hold me to that one.
As someone pointed out, clusters has become very popular with Linux and
indeed, it seem to do rather well as Linux clusters is placing well
within, what?, the top 10 fastest computers in the world!?
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
Subject: Re: IO system throughput
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 20 Apr 2001 16:01:16 -0500
[EMAIL PROTECTED] writes:
> Greg Copeland <[EMAIL PROTECTED]> wrote:
[snip]
>
> > Very cool stuff. NT supports asynchronous file and network I/O. Linux
> > does not.
>
> I was suspecting buzzwords in this terminology, and you are explaining us
> that it is no more than buzzwords. Suppose that instead of a write, it is a
Same concept applies. That is, no buzzwords are needed or used. I think it's
safe to say you don't understand. Saying something is a buzzword just because
you don't understand isn't fair. At any rate, a read would work like this.
You issue a read of blah offset with x amount of data. You again, get a tagged
ID back. Again, you have a signal handler or a callback which is called when
data is available. Likewise, when the tagged id you desire is available, you
now know what data it is and how to process it. Nothing odd. Nothing
vapor ware here. I would like to remind you that this same concept is one of
the main reasons that SCSI tends to be fast. It supports command tag queueing
which is the same concept. Again, no buzzwords needed, just simple facts.
Again, this type of implementation is excellent for heavily data driven
applications like databases because it's easy for them to defer the read and
write results until the operation has completed.
> read. Do you think the application can continue his job without having
> effectively completed the read? It will process absent data? As for writes
I think this does mean you don't understand. Read above. It clearly spells
it out.
> you know very well that physical writes are deferred in all modern systems
> so the IO is in fact done asynchronously. This is the role of interrupts
Aahhh...no! Keep in mind that for databases to truely have good journaling,
they often like to have writeback disabled and this means a physical I/O (write-
through) implementation. It becomes much less costly to have writethrough
operations when using an asynchronous I/O model. Sorry, but it's just the way
it is. It's also important to remember, that just like a modem needs extra
time to compress it's data (thus using a higher baud rate to get data to the
modem faster, in turn giving it more time to compress), the longer the disk
subsystem has the data, the more organized the read and writes can be. In
thoery, this often increases performance. Why do you think so much
attention is paid to scatter-gather logic in the low level disk functions?
> and dma to cope with that. So you care to say that the write can be virtual.
> You think the kernel will spend a lot of time copying buffers? Even that
> can be avoided. Buffers can be shared, as exemplified by the UVM system
> in NetBSD. So the delays involved here are not significant.
Moot point. Not really sure what bearing this has, at any rate, no write
will be fast enough to ensure the data quality of a partially writen trans-
action. This is the whole point of data journal (database log, journal,
whatever you want to call it). In turn, this is the reason why journals
are preferred to be write through on with a disk controller that has cache
and a battery onboard.
>
> What is significant is the big giant lock that was once around the kernel
> on multiproc machines. Then only one proc could run kernel code.
> This has been fine grained on recent Linux, and is in the course of being
> fine grained in FreeBSD. When all this will be perfectly debugged i doubt
> very much that NT will be able to stand the comparison with these systems
> even on multiproc boxes.
Again, this has nothing to do with original topic and is really nothing
more than supposition on your part.
It's important to understand that using an asynchronous model often buys
you little to nothing unless your I/O is of a significant level.
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
** 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
******************************
