lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
eec934fe6cdf00ff46c70c324c1949d18222ecc3
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest174
gohigh 32616db5a4 add directory ftp-archives
2024-02-19 00:24:15 -05:00

740 lines
23 KiB
Plaintext
Raw Blame History

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: Wed, 14 Sep 94 20:13:12 EDT
Subject: Linux-Development Digest #174
Linux-Development Digest #174, Volume #2 Wed, 14 Sep 94 20:13:12 EDT
Contents:
Linux DOOM (Joao Paulo Ribeiro Alves)
Re: Linux & Buslogic PCI (David Engel)
Re: Intel EtherExpress Drivers??? (John Luce)
Problems with mount flag conv=binary (Terry Tanski)
Re: Login USERID length bug? (Brian Watts)
Re: Login USERID length bug? (Brian Watts)
Re: Intel EtherExpress Drivers??? (John Luce)
Kerberos V4 and Linux. . . (Grungie The Wise)
Re: Survey: who wants f77,cc,c++,hpf for linux? (Mark Evans)
Porting applications to TERM (Preston William Gilchrist)
Power down idle SCSI disks [w/ kernel patches] (Christer Weinigel)
Shared Libs: working toward a permanent solution? (Dan Connolly)
----------------------------------------------------------------------------
From: opjoao@skull (Joao Paulo Ribeiro Alves)
Subject: Linux DOOM
Date: 13 Sep 1994 20:49:22 GMT
It seems to me that the binary version of linux is linked dynamically. Since
libraries have a tendency to change and become incompatible I would ask
the person that compiled DOOM to compile it with statically linked libraries.
I know the files will be bigger but you don't have the problem of upgrading
your dynamic libraries.
--
____ ____
/ / / / / / Faculdade de Ciencias de Universidade de Lisboa
/-- / / / /
/ /___/ /___/ /___ Joao Paulo Ribeiro Alves
/
| Internet: opjoao@cc.fc.ul.pt BitNet: opjoao@ptearn.bitnet | \
|__________________________________________________________________________| |
\ PGP 2.3a Public Key available thru "finger opjoao@skull.cc.fc.ul.pt" \ |
\___________________________________________________________________________\|
------------------------------
From: david@ods.com (David Engel)
Subject: Re: Linux & Buslogic PCI
Date: Wed, 14 Sep 1994 14:24:06 GMT
Brian Connelly (nairb@myhost.subdomain.domain) wrote:
: Has there been any work or planed work
: for support for the Buslogic 946C PCI card...
Yes, the 946C has been supported for quite some time using either the
Adaptec or the native Buslogic drivers.
David
--
David Engel Optical Data Systems, Inc.
david@ods.com 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
------------------------------
From: John Luce <jluce@server0>
Crossposted-To: comp.os.linux.help
Subject: Re: Intel EtherExpress Drivers???
Date: Wed, 14 Sep 1994 11:09:41 -0400 (EDT)
On Tue, 13 Sep 1994, David M. Barley wrote:
-3~> In article <354mfu$ej2@jabba.cybernetics.net> you wrote:
: In article <354lmv$egl@jabba.cybernetics.net> jluce@cybernetics.net (John
: Luce) writes: >
: >Is there a device driver available for this NIC (this is the one sold in
: >the Windows for Workgroups Starter kits) ???
: >
: >Thanks....
: >
: >John
: >
: >
: Dang parity got screwed up here, sorry. But, is there a device driver
: available for the Intel EtherExpress 16 that is sold in the starter kit
: for Windows for Workgroups??? Thanks.
: John...
- Well, first off, this is not a WFW newsgroup, this is a Linux group.
- You can get the drivers for the EtherExpress 16 off of the SoftTerm
- disk. You can get the latet from ftp.intel.com. Or, the disks that
- came with WFW have them on there. I used them for a while and
- everything worked...
- --
-
-
- David Barley
-
I guess I did not make myself clear. I am looking for the *LINUX* drivers
for the Intel EE16 which *co-incidentally* is the NIC included in the WFW
starter kits.
Thanks for any help...
John
------------------------------
From: terryt@cs.athabascau.ca (Terry Tanski)
Subject: Problems with mount flag conv=binary
Date: 14 Sep 94 19:44:25 GMT
Hi everyone,
I have found that if I mount my CD with conv=binary so mount spews the
following:
/dev/cdu31a on /mnt/cdrom type iso9660 (ro,conv=binary)
I still get text conversion. od -a of a file on that CD after the mount
shows CR's getting converted to SP's in a MS Tech setup.inf file:
0000000 [ S o u r c e sp M e d i a sp D e
0000020 s c r i p t i o n s ] sp <--- nl sp sp sp
0000040 sp " 1 " , sp " C o p y i n g sp F
0000060 i l e s . . . " , sp " " , sp " "
0000100 sp nl sp nl [ F i l e s ] sp nl sp sp sp
This should not be happening. Can someone explain? BTW, this is on a
linux kernel 1.1.0 with a CDU31A driver.
Thanks in advance,
Terry
********* Terry Tanski, B.Sc.
**********
. **** Computing Services Internet: terryt@cs.athabascau.ca
.. **** Athabasca University Phone: (403) 675-6339
.... **** Box 10,000 FAX: (403) 675-6333
..........**** Athabasca, Alberta CANADA
------------------------------
From: brian@xp.psych.nyu.edu (Brian Watts)
Subject: Re: Login USERID length bug?
Date: 13 Sep 1994 19:43:00 GMT
It seems that people are missing the point with respect to
this... i.e. That it works *inconsistently*. Anything that works
inconsistently is a bug imho. I have pinned down the
inconsistency exactly -- if you type : login longusername
it will WORK -- i.e. when the parameter is passed to login, it
does NOT truncate the name -- however, when you type:
login <Enter>
login: longusername
the longusername is truncated to longuser. This HAS to be a bug
because it is inconsistent.
With respect to the argument that 8 characters is enough for a
user id, this sounds very much like what people were saying 10
years ago: "why would you need a file name > 8 characters in
length". With respect to the argument that userids > 8
characters mess up your nicely tabbed 'ls's -- why don't we
then be consistent and restrict all file names to 8 characters
mmm? do I hear anyone say that that sounds like MSDOS??
BHW
------------------------------
From: brian@xp.psych.nyu.edu (Brian Watts)
Subject: Re: Login USERID length bug?
Date: 13 Sep 1994 19:52:36 GMT
BTW, a point I forgot to mention -- with regard ls -l... try it and you
will see that long userids are trunacted at 8 characters, so the
display is not screwed up.
Another point... what about the 'postmaster' ID -- should that
also be disallowed? and is it ridiculous to have such a long ID?
BHW
------------------------------
From: jluce@cybernetics.net (John Luce)
Crossposted-To: comp.os.linux.help
Subject: Re: Intel EtherExpress Drivers???
Date: 13 Sep 1994 17:11:26 GMT
In article <354lmv$egl@jabba.cybernetics.net> jluce@cybernetics.net (John
Luce) writes: >
>Is <20>h<EFBFBD><68><EFBFBD> a d<>v<EFBFBD><76><EFBFBD> d<><64>v<EFBFBD><76> ava<76><61>ab<61><62> <20><><EFBFBD> <20>h<EFBFBD>s <20>IC <20><>h<EFBFBD>s <20>s <20>h<EFBFBD> <20>n<EFBFBD> s<><73>d <20>n
><3E>h<EFBFBD> W<>nd<6E><64>s <20><><EFBFBD> W<><57>kg<6B><67>ups <20><>a<EFBFBD><61><EFBFBD><EFBFBD> k<><6B>s) <20><><EFBFBD>
>
>Thanks<6B><73><EFBFBD><EFBFBD>
>
>J<>hn
>
>
Dang parity got screwed up here, sorry. But, is there a device driver
available for the Intel EtherExpress 16 that is sold in the starter kit
for Windows for Workgroups??? Thanks.
John...
------------------------------
From: slash@cyclone.Stanford.EDU (Grungie The Wise)
Crossposted-To: comp.protocols.kerberos,comp.os.linux.help
Subject: Kerberos V4 and Linux. . .
Date: 13 Sep 1994 10:34:21 -0700
In the Kerberos FAQ I noticed that V5 had been tested on
Linux. Does anyone know if V4 will compile and run on Linux? We run V4
at Stanford, and I need to get a kerberos line from my linux box to
our net.
Any info/help you have is greatly appreciated!
Thanks,
Jeff
slash@cyclone.stanford.edu
--
__________------== Jeff Townsend ==------___________
____----DCC Consultant - Guitarist - CS Major - Simpsons Fan----____
-==slash@cyclone.stanford.edu jefft@xenon god@cs grungie@leland ==-
----_______"Yes sir. Very much so sir. Obviously insane."_______----
------------------------------
Crossposted-To: comp.lang.fortran
From: evansmp@mb5194.aston.ac.uk (Mark Evans)
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
Date: Wed, 14 Sep 1994 20:32:04 GMT
Alan Cox (iialan@iifeak.swan.ac.uk) wrote:
: GCC doesn't/didn't know about the ARM's weird (but neat) conditional
: skip on any instruction. I understand thats in gcc 2.6.x. Has anyone
: compared this with Acorns compiler.
: As to size - gcc is lumbering and a memory eater. Gcc could definitely
: do with a diet.
How much disk access is of swap, how much is filesystem when using GCC?
:-)
------------------------------
From: pwg7503@tamsun.tamu.edu (Preston William Gilchrist)
Subject: Porting applications to TERM
Date: 14 Sep 1994 16:54:52 -0500
Does anyone have some decent documentation on what is required to port
applications to TERM. Any help would be appreciated.
--
Preston Gilchrist Texas A&M University, Computer Science
E-Mail: mystic@tamu.edu http://tamsun.tamu.edu/~pwg7503/
------------------------------
From: y93chrwe@ida.liu.se (Christer Weinigel)
Subject: Power down idle SCSI disks [w/ kernel patches]
Date: Wed, 14 Sep 1994 23:04:41 GMT
I recently asked if anybody had written any code for turning off SCSI or
IDE drives under linux. Since it seems as if nobody had done it, I
gave it a shot myself. And here it is, the result of a few nights
hacking of the SCSI drivers.
Hopefully the kernel patches will turn off a drive after a certain amount
of time, and if I am really lucky, it might even turn it on when some
program needs it.
The patch should be applied from the /usr/src/linux/drivers directory,
and it patches sd.c, sd.h and sd_ioctl.c to power down idle disks.
Idling is disabled by default and has to be turned on by an ioctl call.
I'm quite new to kernel hacking, so if I've made any horrible misstakes
I would like to hear about them.
Attached is also a small utility which sets the idle timeout on a SCSI device.
It ain't beautiful but it seems to work. The BLKIDLE define is hardcoded
to 4747 both here and in the kernel (sd_ioctl.c). It really belongs in
one of the include files in /usr/include/linux, but I don't know which
one, so I haven't fixed it yet.
Please try it out and tell me how it works.
/Christer (y93chrwe@und.ida.liu.se)
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#define BLKIDLE 4747
void main(int argc, char *argv[])
{
int fd;
int timeout;
if (argc != 3)
{
fprintf(stderr, "usage: setidle device timeout\n"
" where timeout is the time until motor off in seconds\n"
" a value of zero disables this function\n");
exit(1);
}
if ((fd = open(argv[1], O_RDWR)) < 0)
{
perror(argv[1]);
exit(1);
}
timeout = atoi(argv[2]);
printf("Setting idle timeout of %s to %d seconds\n", argv[1], timeout);
ioctl(fd, BLKIDLE, &timeout);
close(fd);
exit(0);
}
diff -u5 -r scsi.orig/sd.c scsi/sd.c
--- scsi.orig/sd.c Tue Sep 13 21:20:15 1994
+++ scsi/sd.c Wed Sep 14 20:46:02 1994
@@ -14,10 +14,11 @@
#include <linux/fs.h>
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/string.h>
#include <linux/errno.h>
+#include <linux/timer.h>
#include <asm/system.h>
#define MAJOR_NR SCSI_DISK_MAJOR
#include "../block/blk.h"
#include "scsi.h"
@@ -45,10 +46,13 @@
SC->device->type != TYPE_MOD)
struct hd_struct * sd;
Scsi_Disk * rscsi_disks;
+
+struct timer_list *sd_idle_timer; /* timer for idling disks */
+
static int * sd_sizes;
static int * sd_blocksizes;
extern int sd_ioctl(struct inode *, struct file *, unsigned int, unsigned long);
@@ -137,10 +141,111 @@
0, /* number */
NULL, /* internal */
NULL /* next */
};
+static void sd_start_done (Scsi_Cmnd * SCpnt)
+{
+ struct request * req;
+
+ req = &SCpnt->request;
+ req->dev = 0xfffe; /* Busy, but indicate request done */
+
+ if (req->sem != NULL) {
+ up(req->sem);
+ }
+}
+
+static int sd_start (Scsi_Cmnd * SCpnt, int dev)
+{
+ char cmd[12];
+ int old_dev = SCpnt->request.dev;
+
+#ifdef DEBUG
+ printk("sd%c : sd_start entered\n", 'a' + dev);
+#endif
+
+ cmd[0] = START_STOP;
+ cmd[1] = (rscsi_disks[dev].device->lun << 5);
+ cmd[2] = cmd[3] = cmd[5] = 0;
+ cmd[4] = 1;
+
+ SCpnt->request.dev = 0xffff; /* Mark as really busy again */
+
+ scsi_do_cmd(SCpnt, cmd, NULL, 0,
+ sd_start_done, 10 * 100, /* give it some time to start */
+ MAX_RETRIES);
+
+ while(SCpnt->request.dev != 0xfffe)
+ schedule();
+
+ SCpnt->request.dev = old_dev;
+
+ return SCpnt->result;
+}
+
+static void sd_stop_done (Scsi_Cmnd * SCpnt)
+{
+ struct request * req;
+
+ req = &SCpnt->request;
+ req->dev = 0xfffe; /* Busy, but indicate request done */
+
+ if (req->sem != NULL) {
+ up(req->sem);
+ }
+
+ SCpnt->request.dev = -1; /* Deallocate */
+ wake_up(&SCpnt->device->device_wait);
+}
+
+static void sd_stop (unsigned long nr)
+{
+ int dev = nr;
+ Scsi_Cmnd * SCpnt = NULL;
+ char cmd[12];
+
+#ifdef DEBUG
+ printk("sd%c: sd_stop entered\n", 'a' + dev);
+#endif
+
+ cli();
+
+ del_timer(&sd_idle_timer[dev]); /* remove timer from list */
+
+ SCpnt = allocate_device(NULL, rscsi_disks[dev].device, 1);
+ if (SCpnt == NULL)
+ {
+ /* Could not allocate device so try again in a little while */
+ sd_idle_timer[dev].expires = HZ * 5;
+ add_timer(&sd_idle_timer[dev]);
+ sti();
+#ifdef DEBUG
+ printk("sd%c : sd_stop could not allocate device\n", 'a' + dev);
+#endif
+ return;
+ }
+
+ sti();
+
+ cmd[0] = START_STOP;
+ cmd[1] = (rscsi_disks[dev].device->lun << 5) | 1;
+ cmd[2] = cmd[3] = cmd[5] = 0;
+ cmd[4] = 0;
+
+ SCpnt->request.dev = 0xffff; /* Mark as really busy again */
+
+ scsi_do_cmd(SCpnt, cmd, NULL, 0,
+ sd_stop_done, SD_TIMEOUT,
+ MAX_RETRIES);
+
+#ifdef DEBUG
+ printk("sd%c : drive has been stopped\n", 'a' + dev);
+#endif
+ rscsi_disks[dev].stopped = 1;
+}
+
static void sd_geninit (void)
{
int i;
for (i = 0; i < sd_template.dev_max; ++i)
@@ -438,10 +543,41 @@
/* printk("SCSI disk has been changed. Prohibiting further I/O.\n"); */
end_scsi_request(SCpnt, 0, SCpnt->request.nr_sectors);
goto repeat;
}
+ /*
+ * Attempt to restart drive
+ */
+ if (rscsi_disks[dev].stopped)
+ {
+ int status;
+
+#ifdef DEBUG
+ printk("sd%c : starting drive\n", 'a' + dev);
+#endif
+ if ((status = sd_start(SCpnt, dev)) != 0)
+ {
+ printk("sd%c : restart failed, status = %x.\n", 'a' + dev, status);
+
+ end_scsi_request(SCpnt, 0, SCpnt->request.nr_sectors);
+ goto repeat;
+ }
+
+ rscsi_disks[dev].stopped = 0;
+ }
+
+ /* restart the idle timer */
+ cli();
+ del_timer(&sd_idle_timer[dev]);
+ if (rscsi_disks[dev].idle_timeout != 0)
+ {
+ sd_idle_timer[dev].expires = rscsi_disks[dev].idle_timeout;
+ add_timer(&sd_idle_timer[dev]);
+ }
+ sti();
+
#ifdef DEBUG
printk("sd%c : real dev = /dev/sd%c, block = %d\n", 'a' + MINOR(SCpnt->request.dev), dev, block);
#endif
switch (SCpnt->request.cmd)
@@ -980,10 +1116,15 @@
}
rscsi_disks[i].ten = 1;
rscsi_disks[i].remap = 1;
scsi_free(buffer, 512);
+
+ /* Set up flags and timeout for turning off idle drives - Wingel */
+ rscsi_disks[i].stopped = 0;
+ rscsi_disks[i].idle_timeout = 0; /* disabled */
+
return i;
}
/*
The sd_init() function looks at all SCSI drives present, determines
@@ -1012,10 +1153,21 @@
sd_template.dev_max = sd_template.dev_noticed;
rscsi_disks = (Scsi_Disk *)
scsi_init_malloc(sd_template.dev_max * sizeof(Scsi_Disk));
memset(rscsi_disks, 0, sd_template.dev_max * sizeof(Scsi_Disk));
+
+ /* Allocate and initialize idle timers, do not activate them - Wingel */
+ sd_idle_timer = (struct timer_list *)
+ scsi_init_malloc(sd_template.dev_max * sizeof(struct timer_list));
+ for (i = 0; i < sd_template.dev_max; i++)
+ {
+ init_timer(&sd_idle_timer[i]);
+ sd_idle_timer[i].expires = 0;
+ sd_idle_timer[i].data = i;
+ sd_idle_timer[i].function = sd_stop;
+ }
sd_sizes = (int *) scsi_init_malloc((sd_template.dev_max << 4) *
sizeof(int));
memset(sd_sizes, 0, (sd_template.dev_max << 4) * sizeof(int));
diff -u5 -r scsi.orig/sd.h scsi/sd.h
--- scsi.orig/sd.h Tue Sep 13 21:26:10 1994
+++ scsi/sd.h Wed Sep 14 16:38:26 1994
@@ -37,10 +37,14 @@
Scsi_Device *device;
unsigned char sector_bit_size; /* sector_size = 2 to the bit size power */
unsigned char sector_bit_shift; /* power of 2 sectors per FS block */
unsigned ten:1; /* support ten byte read / write */
unsigned remap:1; /* support remapping */
+ unsigned stopped:1;
+ unsigned long idle_timeout; /* idle time before turning off drive */
} Scsi_Disk;
extern Scsi_Disk * rscsi_disks;
+
+extern struct timer_list *sd_idle_timer; /* timer for idling disks */
#endif
diff -u5 -r scsi.orig/sd_ioctl.c scsi/sd_ioctl.c
--- scsi.orig/sd_ioctl.c Tue Sep 13 21:20:15 1994
+++ scsi/sd_ioctl.c Wed Sep 14 19:47:15 1994
@@ -1,10 +1,11 @@
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/fs.h>
#include <linux/hdreg.h>
#include <linux/errno.h>
+#include <linux/timer.h>
#include <asm/segment.h>
#include "../block/blk.h"
#include "scsi.h"
@@ -19,10 +20,11 @@
int dev = inode->i_rdev;
int error;
struct Scsi_Host * host;
int diskinfo[4];
struct hd_geometry *loc = (struct hd_geometry *) arg;
+ unsigned long timeout;
switch (cmd) {
case HDIO_REQ: /* Return BIOS disk parameters */
if (!loc) return -EINVAL;
error = verify_area(VERIFY_WRITE, loc, sizeof(*loc));
@@ -66,9 +68,52 @@
invalidate_buffers(inode->i_rdev);
return 0;
case BLKRRPART: /* Re-read partition tables */
return revalidate_scsidisk(dev, 1);
+
+#define BLKIDLE 4747
+ case BLKIDLE: /* Idle disks after timeout */
+ if (!arg) return -EINVAL;
+ error = verify_area(VERIFY_READ, (long *) arg, sizeof(long));
+ if (error)
+ return error;
+
+ cli(); /* is this really neccesary? */
+ del_timer(&sd_idle_timer[MINOR(dev) >> 4]);
+ sti();
+
+ timeout = get_fs_long((long *) arg);
+
+ if (timeout != 0 && timeout < 15)
+ {
+ /* Be a bit over-protective */
+ printk("sd%c : warning, idle timeout of %ld seconds is WAY to small\n",
+ 'a' + (MINOR(dev) >> 4),
+ timeout);
+ timeout = 15;
+ }
+
+ rscsi_disks[MINOR(dev) >> 4].idle_timeout = timeout * HZ;
+ if (rscsi_disks[MINOR(dev) >> 4].idle_timeout != 0)
+ {
+#ifdef DEBUG
+ printk("sd%c : idle timeout set to %ld jiffies\n",
+ 'a' + (MINOR(dev) >> 4),
+ rscsi_disks[MINOR(dev) >> 4].idle_timeout);
+#endif
+ sd_idle_timer[MINOR(dev) >> 4].expires = rscsi_disks[MINOR(dev) >> 4].idle_timeout;
+ cli();
+ add_timer(&sd_idle_timer[MINOR(dev) >> 4]);
+ sti();
+ }
+#ifdef DEBUG
+ else
+ printk("sd%c : idle timeout disabled\n",
+ 'a' + (MINOR(dev) >> 4));
+#endif
+ return 0;
+
default:
return scsi_ioctl(rscsi_disks[MINOR(dev) >> 4].device , cmd, (void *) arg);
}
}
------------------------------
From: connolly@ulua.hal.com (Dan Connolly)
Subject: Shared Libs: working toward a permanent solution?
Date: 14 Sep 1994 15:39:40 GMT
Forgive me if this has been hashed over in this forum before... I've
been following c.o.l.d for about a month, and I haven't seen it (nor
is it in the FAQs, HOWTOs, or any other documentation that I can
find...)
The current architecture for shared libraries seems to work pretty
well, but it seems tedious to build shared libraries, and the fact
that you have to somehow magically choose a part of the address space
that noone else will ever use strikes me as somewhat fragile. The
technique of reducing loader symbols to integer indexes seems fragile
also.
[Quick question: shared libraries _are_ in fact shared between
processes in the sense that program if program A and program B are
both using shared library X, there is only one copy of X in physical
memory, right? There isn't any runtime "patching" that makes shared
libraries unique to a process, is there?]
So is there a project underway to replace the current shared library
tools with conventional name-based shared libraries? This seems like a
big compatibility nightmare, but it's worth it, I think. And the
sooner we do it, the better.
How are SVR4 shared libraries done? (perhaps I should do some reading
here...) It seems that the "commercial" x86 unix platforms are SVR4
based. What are the major gaps between LINUX as it is today and SVID
compliance? Hmmm... I should do some reading on ELF and the iBCS
project. Is there any hope that solaris binaries will run on LINUX?
Solaris/intel seems like it's shaping up to become a viable platform.
It might be nice to be able to ride that wave...
Pointers toward the relavent discussion forums, source distributions,
newsgroups, etc. are appreciated.
Dan
--
Daniel W. Connolly "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010
<connolly@hal.com> http://www.hal.com/%7Econnolly/index.html
------------------------------
** 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