lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
eec934fe6cdf00ff46c70c324c1949d18222ecc3
oldlinux-files/docs/mail-archive/linux-devel/Volume1/digest5XX/digest571
gohigh 9912ec445d add directory docs
2024-02-19 00:23:35 -05:00

695 lines
27 KiB
Plaintext
Raw Blame History

Subject: Linux-Development Digest #571
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: Tue, 22 Mar 94 07:13:05 EST
Linux-Development Digest #571, Volume #1 Tue, 22 Mar 94 07:13:05 EST
Contents:
Pipe failure, open files (Jon Freivald)
Re: VM performance tuning via program restructuring (Peter Desnoyers)
Re: Specialix Driver Round 2 (From specialix) (Craig Milo Rogers)
xterm for Xaw3d patch [XFree86 2.1] (Satoshi ASAMI)
Re: Adpatec 2842 SCSI Driver .. (Tseng Yaw-yih)
IPX (NetWare) routing. (Chris D. Johnston)
Can two programs read or write from /dev/dsp at the same time (Brandon C Long)
LINUX port to a transputer system (Baranski, A.S.)
Re: 486DLC support anyone? (engelbert.jgm.torremans)
Re: Can two programs read or write from /dev/dsp at the same time (Hannu Savolainen)
----------------------------------------------------------------------------
From: jaf@jaflrn.Morse.Net (Jon Freivald)
Subject: Pipe failure, open files
Date: Tue, 22 Mar 1994 05:10:41 GMT
I got a message from my Cron Daemon today -- it said I had a pipe
failure due to too many open files. This brings me to asking 2
questions:
1. How many files can be open at one time? (And related, is this per
process, or for the entire system?)
2. Is there anything I can do to increase this number? (Memory is
not tight... 20M real, 64M virtual)
Jon
--
Jon Freivald ( jaf@jaflrn.Morse.Net )
PGP V2 - 22A829/40 DA 9E 8E C0 A1 59 B2 46 3B 73 81 2B 7B 83 1F
Nothing is impossible for the man who doesn't have to do it.
------------------------------
From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
Subject: Re: VM performance tuning via program restructuring
Date: Mon, 21 Mar 1994 18:10:00 GMT
A simple method that might give more accurate information for program
restructuring would be to measure the call graph transitions - i.e.
how many times A calls B - by source code instrumentation. It's not as
simple as turning on profiling, but it's still pretty easy to
implement (write a perl script to insert counting code, then
recompile) and shouldn't impact performance too badly.
The advantage is that this gives you exactly the information you need
to re-order your code, instead of having to infer calling frequencies
from static frequency in the source code.
Now, given the call frequency graph, do any of you have any good
algorithms for re-ordering functions?
Peter Desnoyers
--
------------------------------
From: rogers@drax.isi.edu (Craig Milo Rogers)
Subject: Re: Specialix Driver Round 2 (From specialix)
Date: 21 Mar 1994 10:10:28 -0800
In the following reply, I may appear a little condescending,
even sarcastic. I apologize in advance. I don't really wish to
offend, I simply wish to make my point obvious. Also, this is a
long post, and I apologize for that, too.
In article <DMW.94Mar17102220@prism1.prism1.com> dmw@prism1.prism1.com (David Wright) writes:
> I don't see that the "host side" portion of the code would be
>vendor-specific in & of itself.
1) The intelligent board connects to the host system by the
system I/O bus, right?
2) The system I/O bus is accessed from the host CPU via I/O
instructions and/or memory-mapped I/O regions.
1) The system DMA controller might be used for some
activities.
2) In some cases, an I/O board might control onoing transactions
as an independent bus master.
3) These details are irrelevant.
3) Setting various bits in the I/O registers from the host (via I/O
instructions or memory access instructions) causes various and
wonderful things to happen in the intelligent I/O boards.
4) Since the intelligent board contain a running software program
of its own, the format of the registers, and their meanings, may
be time-varying in very complex, arbitrary, obscure, arcane,
and wonderful ways.
Here we reach the nut of the problem. Each :intelligent
serial board" vendor may use a completely and arbitrarily *different*
allocation (spatial and temporal) of bits on the host side of the
interface, to do that vendor's various and wonderful things. There is
no common convention or standard (of which I'm aware) for the hardware
design, meaning of bits, temporal dependencies, etc. in these boards.
Nada. Zip.
Conclusion: the host-side interface is vendor-specific,
in-and-of itself.
For competitive reasons, at least one "intelligent serial
board" vendor wishes to keep various aspects of their host-side
interface a trade secret.
Now, what about the host side driver software? Part of it has
to load those host-side divice registers, and twiddle those host-side
bits, and follow those temporal protocols, in order to accomplish the
various and wonderful things of which the intelligent board is
capable.
Conclusion: part of the host-side driver software (code) is
vendor-specific, in-and-of itself.
Revealing that part of the host-side driver, as by publishing
its source code, would reveal details of the host-side interface which
(at least one) vendor wishes to keep a trade secret.
>Granted, as there is no "generic" intelligent
>host adapter "glue" code right now (that I am aware of), someone would have to
>write this (which would be covered by the GPL), possibly using the standard
>serial device interface code as an example (which is how you want the
>intelligent card to look for IOCTL purposes anyway).
There is no "generic" intelligent host adaptor "glue" code,
because there is no "generic intelligent host adaptor" (of which I am
aware). No standard has been established, not even a partial
standard, as is found in video adaptors, sound adaptors, SCSI disk
adaptors/drives, etc. Lacking adherence to a common standard, nothing
is generic. Lacking adherence to a common standard, functioning
(complete in itself) "generic" driver code for intelligent serial
boards is not possible.
We might discuss *why* there is no standard. Essentially,
there is no dominent vendor (or other organization) wishing to and in
an economic position to establish a standard, and the market is
apparently too small for the reverse-engineering practices, that have
established some de-facto industry standards, to be practical.
>But that does not have
>anything to do with the code that is running ON THE HOST ADAPTER. IE: If the
>host adapter is using a RISC procoessor, all the Linux code is doing is acting
>as a loader for the RISC code, and the RISC code would NOT be under the GPL at
>all.
The details for loading the on-board processor code is, quite
probably, one of the major functions that the vendor(s) wish to remain
a trade secret.
However, you've overlooked most of the actual function of the
Linux driver. It doesn't just *load* the on-board processor. It
*talks* with it afterward! *How* the "Linux code" talks with tbe
board is device-specific, and may be, as I have said, something a
vendor wishes to remain a trade secret, too.
> What would be good to have (and what we will get "de facto" when the
>Specialix driver is released) is an API for talking to intelligent cards
>under Linux. This would be the part that got linked into the kernel, that knew
>about Linux internals, and how to write to the intelligent card on the other
>side. What the intelligent card DOES with the data would still be vendor
>specific, and would be running vendor-supplied binary code (either loaded
>by the drive at boot time (the loader would likely have to be GPLed), or on
>firmware on the card) that would NOT have to be GPLed, since it knows nothing
>about Linux/Unix/DOS at all...
>
> CMR> If you are a latecomer to this thread, I might be able to
> CMR> email you a copy of the messages that I've saved from it.
>
> Nope, I have the whole thing here, and saw all the various "rounds"...
Ok, then please reread my post (Message-ID:
<2klq36$c8p@drax.isi.edu>) on how to split an operating system device
driver into two parts: an OS-specific part, which, in the case of
Linux, would be GPLed and distributed with source, and a
hardware-device-specific (running on the host processor, I emphasize)
part, which would not be subject to the GPL, and which could be
distributed in object-only format.
The OS-specific part of the driver could be considered the API
you described above, except that the API *wouldn't* know "how to
write to the intelligent card on the other side", as doing so is
specific to each vendor's device, in-and-of itself. Writing to the
intelligent card would be the responsibility of the non-GPLed,
object-only portion of the device driver.
On the OS-dependent side, you could establish a API, such as a
set of IOCTLs, to be used by user-level programs to reset the intelligent
serial board's on-board processor, load a new program into the board,
and other functions that are not present in a standard "dumb" serial
board, but which may be reasonably expected to be common to intelligent
serial boards. However, the implementation of resetting, loading, etc.,
the on-board processor would be part of the hardware-device-specific,
non-GPLed code in the two-part driver I refer to above.
Alternatively, and with all due respect to Specialix, Inc.,
you could simply choose to buy your intelligent board from a vendor
that does *not* regard keeping trade secrets to be necessary for their
competitive advantage.
Craig Milo Rogers
------------------------------
From: asami@cs.berkeley.edu (Satoshi ASAMI)
Crossposted-To: comp.windows.x.i386unix,comp.os.386bsd.apps
Subject: xterm for Xaw3d patch [XFree86 2.1]
Date: 22 Mar 94 00:17:22
(I'm not sure if this is the correct Linux group to post this, sorry
if it's not.)
I grabbed the xterm patch from ftp.x.org:/contrib/Xaw3d so that I can
use arrow scrollbars of xterm on my just-compiled XFree86 2.1
(FreeBSD-(almost-)current, Orchid F1280+ VLB). Unfortunately, quite a
bit of the source has changed and many hunks failed. The following is
the result of my hand-applying of the patches.
Disclaimer: I didn't bother with the version headers. I haven't
tested the Tek part. The VT window looks ok.
If anybody made a similar patch for kterm, please let me know. Kalib
(kaleb@x.org, the author of Xaw3d) will probably like to hear that
too.
Satoshi
P.S. Xaw3d is great! If you have Sun-style shared libraries (aka
*BSD-current), all you need to do is to compile Xaw3d and make a
symbolic link libXaw.so.2.0 --> libXaw3d.so.2.0 and boom!
everything is 3D!
---
diff -rub xterm.org/Tekproc.c xterm/Tekproc.c
--- xterm.org/Tekproc.c Sun Mar 20 02:25:24 1994
+++ xterm/Tekproc.c Sun Mar 20 13:46:55 1994
@@ -151,6 +151,8 @@
extern int Tpttable[];
extern int Tspttable[];
+extern XtAppContext app_con;
+
static int *curstate = Talptable;
static int *Tparsestate = Talptable;
@@ -606,7 +608,7 @@
TekGINoff();
TCursorDown();
if (!TekRefresh &&
- (QLength(screen->display) > 0 ||
+ (XtAppPending(app_con) ||
GetBytesAvailable (ConnectionNumber(screen->display)) > 0))
xevents();
break;
@@ -726,7 +728,7 @@
Ttoggled = FALSE;
}
#ifndef AMOEBA
- if(QLength(screen->display))
+ if(XtAppPending(app_con) & XtIMXEvent)
Tselect_mask = X_mask;
else {
XFlush(screen->display);
diff -rub xterm.org/charproc.c xterm/charproc.c
--- xterm.org/charproc.c Sun Mar 20 02:25:25 1994
+++ xterm/charproc.c Sun Mar 20 14:06:04 1994
@@ -68,6 +68,7 @@
extern jmp_buf VTend;
+extern XtAppContext app_con;
extern Widget toplevel;
extern void exit();
extern char *malloc();
@@ -620,7 +621,7 @@
Index(screen, 1);
if (term->flags & LINEFEED)
CarriageReturn(screen);
- if (QLength(screen->display) > 0 ||
+ if (XtAppPending(app_con) ||
GetBytesAvailable (ConnectionNumber(screen->display)) > 0)
xevents();
parsestate = groundtable;
@@ -996,7 +997,7 @@
case CASE_IND:
/* IND */
Index(screen, 1);
- if (QLength(screen->display) > 0 ||
+ if (XtAppPending(app_con) ||
GetBytesAvailable (ConnectionNumber(screen->display)) > 0)
xevents();
parsestate = groundtable;
@@ -1007,7 +1008,7 @@
Index(screen, 1);
CarriageReturn(screen);
- if (QLength(screen->display) > 0 ||
+ if (XtAppPending(app_con) ||
GetBytesAvailable (ConnectionNumber(screen->display)) > 0)
xevents();
parsestate = groundtable;
@@ -1431,15 +1432,26 @@
XFlush(screen->display); /* always flush writes before waiting */
#ifndef AMOEBA
- /* Update the masks and, unless X events are already in the queue,
- wait for I/O to be possible. */
+ /*
+ * Update the masks and, unless X events are already in the
+ * queue, wait for I/O to be possible.
+ */
select_mask = Select_mask;
write_mask = ptymask();
select_timeout.tv_sec = 0;
+ /*
+ * if there's either an XEvent or an XtTimeout pending, just take
+ * a quick peek, i.e. timeout from the select() immediately. If
+ * there's nothing pending, let select() block a little while, but
+ * for a shorter interval than the arrow-style scrollbar timeout.
+ */
+ if (XtAppPending(app_con))
select_timeout.tv_usec = 0;
- i = select(max_plus1, (fd_set *)&select_mask, (fd_set *)&write_mask,
- (fd_set *)NULL, QLength(screen->display) ? &select_timeout
- : (struct timeval *) NULL);
+ else
+ select_timeout.tv_usec = 50000;
+ i = select(max_plus1,
+ (fd_set *)&select_mask, (fd_set *)&write_mask,
+ (fd_set *)NULL, &select_timeout);
if (i < 0) {
if (errno != EINTR)
SysError(ERROR_SELECT);
@@ -1453,7 +1465,7 @@
/* if there are X events already in our queue, it
counts as being readable */
- if (QLength(screen->display) || (select_mask & X_mask)) {
+ if (XtAppPending(app_con) || (select_mask & X_mask)) {
xevents();
}
#else
@@ -2552,7 +2564,6 @@
/* make sure that the resize gravity acceptable */
if ( new->misc.resizeGravity != NorthWestGravity &&
new->misc.resizeGravity != SouthWestGravity) {
- extern XtAppContext app_con;
Cardinal nparams = 1;
XtAppWarningMsg(app_con, "rangeError", "resizeGravity", "XTermError",
@@ -2992,7 +3003,7 @@
* (screen->max_row + 1) + 2 * screen->border,
&junk, &junk);
XSync(screen->display, FALSE); /* synchronize */
- if(QLength(screen->display) > 0)
+ if(XtAppPending(app_con))
xevents();
}
CursorSet(screen, 0, 0, term->flags);
diff -rub xterm.org/main.c xterm/main.c
--- xterm.org/main.c Sun Mar 20 02:25:25 1994
+++ xterm/main.c Sun Mar 20 14:26:03 1994
@@ -223,6 +223,10 @@
#define ttyslot() 1
#endif /* apollo */
+#ifdef sun
+#include <sys/filio.h>
+#endif
+
#ifdef UTMP
#include <utmp.h>
#endif
@@ -3486,15 +3490,19 @@
{
#ifndef AMOEBA
#ifdef FIONREAD
- static long arg;
+ long arg;
ioctl (fd, FIONREAD, (char *) &arg);
return (int) arg;
#else
+#ifdef FIORDCK
+ return (ioctl (fd, FIORDCHK, NULL));
+#else
struct pollfd pollfds[1];
pollfds[0].fd = fd;
pollfds[0].events = POLLIN;
return poll (pollfds, 1, 0);
+#endif
#endif
#else
/*
diff -rub xterm.org/misc.c xterm/misc.c
--- xterm.org/misc.c Sun Mar 20 02:25:26 1994
+++ xterm/misc.c Sun Mar 20 13:44:05 1994
@@ -64,21 +64,33 @@
static void DoSpecialEnterNotify();
static void DoSpecialLeaveNotify();
+extern XtAppContext app_con;
+
xevents()
{
XEvent event;
+ XtInputMask input_mask;
register TScreen *screen = &term->screen;
- extern XtAppContext app_con;
if(screen->scroll_amt)
FlushScroll(screen);
- if (!XPending (screen->display))
- /* protect against events/errors being swallowed by us or Xlib */
+ /*
+ * process timeouts, relying on the fact that XtAppProcessEvent
+ * will process the timeout and return without blockng on the
+ * XEvent queue. Other sources i.e. the pty are handled elsewhere
+ * with select().
+ */
+ while ((input_mask = XtAppPending(app_con)) & XtIMTimer)
+ XtAppProcessEvent(app_con, XtIMTimer);
+ /*
+ * If there's no XEvents, don't wait around...
+ */
+ if ((input_mask & XtIMXEvent) != XtIMXEvent)
return;
do {
if (waitingForTrackInfo)
return;
- XNextEvent (screen->display, &event);
+ XtAppNextEvent (app_con, &event);
/*
* Hack to get around problems with the toolkit throwing away
* eventing during the exclusive grab of the menu popup. By
@@ -104,7 +116,7 @@
(event.xany.type != ButtonPress) &&
(event.xany.type != ButtonRelease)))
XtDispatchEvent(&event);
- } while (QLength(screen->display) > 0);
+ } while ((input_mask = XtAppPending(app_con)) & XtIMXEvent);
}
@@ -322,7 +334,7 @@
the bell again? */
if(screen->bellSuppressTime) {
if(screen->bellInProgress) {
- if (QLength(screen->display) > 0 ||
+ if (XtAppPending(app_con) ||
GetBytesAvailable (ConnectionNumber(screen->display)) > 0)
xevents();
if(screen->bellInProgress) { /* even after new events? */
------------------------------
From: u800307@Winkie.Oz.nthu.edu.tw (Tseng Yaw-yih)
Subject: Re: Adpatec 2842 SCSI Driver ..
Date: 22 Mar 1994 08:25:41 GMT
Wolfgang Jung (wong@cs.tu-berlin.de) wrote:
> Hi
> ==
> I would like to know when there will be a SCSI Driver for the
> 2842 (if at all )
> I read a message of an upcoming Driver for the 2842 about 3 1/2 Month
> ago.. So I would llike to know how far the development for that
> Adapter went ..
> Thanks
> Wolfgang
> PS: I would like email.
If you got the driver,please mail to me ,too.
Thank you very much. u800307@Winkie.Oz.nthu.edu.tw
------------------------------
From: chris@surfcty.surfcty.com (Chris D. Johnston)
Subject: IPX (NetWare) routing.
Date: Tue, 22 Mar 1994 08:42:10 GMT
I noticed in a recent compile session of Alan Cox's
patched Net-032 kit, there seemed to be some mention of
IPX/SPX packet handling. This would imply Novell NetWare
packet routing.
Someone responded to me earlier regarding this, but
I managed to misplace that mail file.
In any case, the goal is to use Linux as a router/bridge
to connect two offices. Both offices use TCP/IP and IPX (NetWare).
The new Net-032(cox) man pages make no mention of this.
Has anyone any ideas or plans ? ? ?
Chris
--
===============================================================
Chris D. Johnston Surf City Software, Orange, CA 714/289-8543
chris@surfcty.com fax: 714/289-1002
------------------------------
From: blong@dcl-nxt44 (Brandon C Long)
Subject: Can two programs read or write from /dev/dsp at the same time
Date: 22 Mar 1994 08:46:04 GMT
I'm writing a program that reads from /dev/dsp and attempts to display
the results graphically using svgalib. Currently, I can get it to
work using something like a playing a CD, or if I play a mod to /dev/dsp1
(I have a PAS 16) and set the PAS to record from pcm2, it will work.
But I would like it to be able to read /dev/dsp while a program like
str was using it. Is this possible, can it be done with some simple
modification of str, or do I have to have a tracker as part of my program
in order to do this.
Thanks for any help
Brandon
================================================================================
> Brandon Long ][ Yeah, I blong here too. [
> Computer Engineering ][ "A man who could make so vile a pun would not [
> University of Illinois ][ scruple to pick a pocket." -- John Dennis [
> Urbana-Champaign ][ blong@uiuc.edu blong@sumter.cso.uiuc.edu (NeXT) [
===========<A HREF=http://www.cen.uiuc.edu/~bl6456/>blong</a>===================
The aforementioned views may not be those of this fine University.
Let's just say that I would be really surprised if they were.
------------------------------
From: Antoni.Baranski@si.hhs.nl (Baranski, A.S.)
Subject: LINUX port to a transputer system
Reply-To: Antoni.Baranski@si.hhs.nl
Date: Tue, 22 Mar 1994 08:18:17 GMT
Hi World,
I am a student at the Haagse HogeSchool Sector Informatica in the Hague, Holland.
During my summer holliday I am planning on making a port of LINUX onto a T800
transputer subsystem which plugs into my PC.
The general idea is that the PC will function as a server for the transputer system.
Taking care of all the I/O routines (Harddisk, Video) and at the same time will be
used as the frontend user interface for the transputer system.
Running with X11 on the PC under LINUX it will be possible to open a window with
linux and have a linux sub-system running on the transputer system. And using the
transputer system for number crunching.
I must say that I am new to LINUX and have never ported any software that realy
worked after the porting.
I under stand that big portions of the LINUX kernel are written in assembly, and
that is a point I fear I migth get into a lot of trouble because my knowlegde of
assembly isn't that great. And programming the transputer is assembly well, no
thank you. So I would have to translate all the assembly into C/C++.
SO, if my idea is crazy please let me know. I f you any suggestions on books that
migth help in the proces of porting the linux kernel please let me know. Well
actualy if you have any comment on this 'CRAZY' idea please let me know.
Thanx
================================================|
Baranski, A. S. | Haagse HogeSchool |
E-Mail: | Sector Informatica |
Antoni.Baranski@si.hhs.nl | Student Software Engineering |
================================================|
DOS => Just another boot sector virus.
Windows => Bigest virus code ever written.
OS/2 => Works great!!
------------------------------
From: etorrem@cbnewsj.cb.att.com (engelbert.jgm.torremans)
Subject: Re: 486DLC support anyone?
Date: Tue, 22 Mar 1994 08:58:23 GMT
From article <1994Mar19.020240.14960@mcshub.dcss.mcmaster.ca>, by abrams@maccs.mcmaster.ca (Jonathan H. Abrams):
> In article <Mar18.025419.15746@acs.ucalgary.ca>,
> Superuser <root@fusion.cuc.ab.ca> wrote:
>>cjthomas@metronet.com (Chris Thomas) writes:
>>> I just popped a TI486DLC cpu into my system only to discover that there is a
>>> DOS program that enables the internal cache on the chip. It works great
>>> for DOS, but linux is still kind of slow.
>>> Has anyone tried to add DLC support to the kernel? For that matter, does
>>> anyone know how to enable the internal cache of the CPU?
>>
>>Grab CxPatch.tar.gz from sunsite.unc.edu in /pub/Linux/kernel/misc-patches
>>(or thereabouts).
>>
>
> Is this neccessary if I have set the internal cache enabled in the AMi
> bios setting?
>
> Jonathan H. Abrams McMaster University
> abrams@acm.org Hamilton, Ontario, Canada
No, the patches are only required for motherboards and BIOS'es that are
not 486DLC aware.
In your case the internal cache is already enabled by the BIOS.
Good luck,
--
==========================================================================
| Engelbert Torremans | AT&T Network Systems Nederland |
| Huizen | Email: e.torremans@att.com |
| The Netherlands | My opinions are my own |
------------------------------
From: hsavolai@cs.Helsinki.FI (Hannu Savolainen)
Subject: Re: Can two programs read or write from /dev/dsp at the same time
Date: 22 Mar 1994 09:31:26 GMT
In <2mmb8c$r1l@vixen.cso.uiuc.edu> blong@dcl-nxt44 (Brandon C Long) writes:
>I'm writing a program that reads from /dev/dsp and attempts to display
>the results graphically using svgalib. Currently, I can get it to
>work using something like a playing a CD, or if I play a mod to /dev/dsp1
>(I have a PAS 16) and set the PAS to record from pcm2, it will work.
>But I would like it to be able to read /dev/dsp while a program like
>str was using it. Is this possible, can it be done with some simple
>modification of str, or do I have to have a tracker as part of my program
>in order to do this.
Most of the current soundcards are not able to do simultaneous input and
output of digitized voice. The only exeption is the PAS16 which has two
audio devices in the same package. The GUS is also able to record and
play back at the same time but the current driver doesn't support it
(could be possible within this year). The SB family doesn't have this
capability.
It could be technically possible to build some kind of monitor device to
the sound driver (a process reading from this device receives a copy of
everything written to /dev/dsp). However it's likely that this kind of
solution has disastrous performance effects so I'm not willing to
implement it.
Hannu
--
============================================================================
Hannu Savolainen (hsavolai@cs.helsinki.fi)
Hexdump a day keeps the doctor away.
------------------------------
** 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
******************************
Reference in New Issue View Git Blame Copy Permalink