Subject: Linux-Development Digest #79
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:     Thu, 9 Sep 93 15:13:30 EDT

Linux-Development Digest #79, Volume #1           Thu, 9 Sep 93 15:13:30 EDT

Contents:
  Re: SLIP, Compressed vs. uncompressed Headers (Jim McCoy)
  how to debug kernel: malloc pb? in ultrastor scsi driver?? (Basile STARYNKEVITCH)
  Re: Idea, donate a Pentium machine to Linus, anyone? (Dag Asheim)
  Re: ** IDE Multiple Mode Patch ** (Alan Cox)
  Help on building a MS_DOS cross-compiler (Carlos O'Ryan)
  Linux on Amiga (John Shardlow)
  A review of the Intel 82077/82078 - a floppy drive controller (Jesus Monroy Jr)
  Re: Idea, donate a Pentium machine to Linus, anyone? (Roger Binns)
  Re: Status of the NET-2 port (Kl.Schaefers)
  HELP: tar (Keith B. Kee)
  99p13Alpha: wierd swap'n'hang behavor (Michael Will)
  socket programming question (Andrew Hobson)

----------------------------------------------------------------------------

From: mccoy@ccwf.cc.utexas.edu (Jim McCoy)
Subject: Re: SLIP, Compressed vs. uncompressed Headers
Date: 9 Sep 1993 03:13:46 -0500
Reply-To: mccoy@ccwf.cc.utexas.edu


In article <CD2AA3.Kxz@sixhub.tmr.com>, davidsen@sixhub.tmr.com (Bill Davidsen) writes:
> In article <1993Sep4.182653.3792@sky.GUN.de> gt@sky.GUN.de (Guido Thater) writes:
> | Is it planned to toggle between compressed and uncompressed SLIP-Headers
> | without rebooting Linux with a differend Kernel? [...]
> 
> I'd love to see something a bit more robust than that. UUCP can change
> paramaters on a site basis, why not SLIP? [...]

From the "been there, done that" department... what you want has already
been created and is called PPP (Point to Point Protocol).  See RFC-1331 or
the comp.protocols.ppp newsgroup...


jim
-- 
Jim McCoy                       |  UT Unix Sysadmin Tiger Team
mccoy@ccwf.cc.utexas.edu        |  #include <disclaimer.h>
pgp key available via "finger -l", on pubkey servers, or upon request

------------------------------

From: basile@soleil.serma.cea.fr (Basile STARYNKEVITCH)
Subject: how to debug kernel: malloc pb? in ultrastor scsi driver??
Date: Thu, 09 Sep 1993 08:50:30 GMT
Reply-To: basile@soleil.serma.cea.fr

Hello,

I'm linuxing at home on my home 486DX66 PC (but emailing & posting from
work).  I have a 240Mb IDE drive, 16=4*4Mb*70ns RAM, ET4000 VLB
videocard, ultrastor34f scsi2 VLB controller with a 240Mb scsi2 disk
and a Qic150 scsi2 archive viper tape streamer.  My developpment kernel
and system (99pl12, slackware 1.01) runs only on IDE (and is compiled
without scsi support).

I need to debug the UltraStor scsi driver, because it does not work on
my machine (with an UltraStor34F VLB scsi2 controller).

Under Linux99pl12 the standard kernel/blk_drv/scsi/ultrastor.c driver
doesn't really work. Any big accesses (eg a 80MB mke2fs /dev/sda5)
panic the system. Small accesses (eg fdisk reading or writing
partition) are ok.  The scheduler in kernel/sched.c have trouble: in
the schedule routine, the task scanning loops  got their p (current
scanned task pointer temporary) nil, and makes the kernel panic
(without syncing).

Same problem occurred with Linux99pl11 and Linux99pl13alpha (of sept 5).

Am i right in supposing that the scheduler is ok (otherwise many other
could notice problems)?

The ultrastor-1.9.tar.gz file, which contains a bigger ultrastor.c,
also doesn't work well.

I suspect a malloc problem (or perhaps some interrupt occurring in an
unprotected critical place). Is there any kernel malloc debugging
package out there?

I would like to write kernel (printk) messages on console and disk.  I
know that i could use some syslog related stuff, but i want to have the
kernel flush (to my IDE disk) as much information as possible, even if
panicing in scheduler or other sensitive place. Any suggestions?


Also, where is the newest Ultrastor driver? 

Thanks




---

Basile STARYNKEVITCH   ----  Commissariat a l Energie Atomique
DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France
fax: (33) 1- 69.08.23.81;    phone: (33) 1- 69.08.40.66
email: basile@soleil.serma.cea.fr;  homephone: (33) 1- 46.65.45.53


Linuxing at home only.

N.B. Any opinions expressed here are solely mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.



------------------------------

From: Dag Asheim <dash@ifi.uio.no>
Subject: Re: Idea, donate a Pentium machine to Linus, anyone?
Reply-To: Dag Asheim <dash@ifi.uio.no>
Date: Thu, 9 Sep 1993 09:57:15 GMT

>Anyone also comes out with such an idea? It comes into my mind
>5 seconds ago so I just present it :-) 

No, we don't want that.  Then he'll just make the system to slow to
use on a 486.  But at least you didn't suggest to give him an Alpha.
With a Pentium we would be binary compatible, even if it is a little
on the slow side.  :-)

                                        Dag

PS:  Actually, if Linus would promise not to forget the days he had
a 386, it might be a good idea.  He deserves it!

------------------------------

From: iiitac@swan.pyr (Alan Cox)
Subject: Re: ** IDE Multiple Mode Patch **
Date: Thu, 9 Sep 1993 11:20:35 GMT

There were some patches posted to fix the interrupt problems with ide drives
so that interrupts were not held off for the entire time. Does anyone
know where these patches now live and has anyone combined them with
IDE multiple mode.

Alan


------------------------------

From: coryan@poincare.mat.puc.cl (Carlos O'Ryan)
Subject: Help on building a MS_DOS cross-compiler
Date: Wed, 8 Sep 1993 17:54:14 GMT

Hi,
        I'm building a linux -> go32 (the MS_DOS version of gcc, djgpp
if you prefer) cross-compiling enviroment, the idea is to use the same
compiler (since object file formats are the same) and use GNU binutils
to make a cross linker, someday, when dosemu and go32 recognize each
other you would be able to run the program without leaving linux,
up to now I've been able to compile and run some small programs, but 
quitting to :( DOS.

Anyway I have a small problem:

- GCC complains about memcmp and memcpy, it seems that DJGPP include's
are older than my GCC (2.4.3), does anybody knows of to find the
"version" (if any) of the include files I'm using?

- Some day I'd like to have beta-testers, any volunteers?

PS: Please do not ask for any distributions yet, first I don't have it
with me right now, and second I'd like to test it some more.
---
Carlos O'Ryan Lira
Departamento de Matematicas, Pontificia Universidad Catolica de Chile
E-mail: coryan@mat.puc.cl, coryan@numero1.puc.cl
--
Carlos O'Ryan Lira
Departamento de Matematicas, Pontificia Universidad Catolica de Chile
E-mail: coryan@mat.puc.cl, coryan@numero1.puc.cl

------------------------------

From: jshardlo@micrognosis.co.uk (John Shardlow)
Subject: Linux on Amiga
Date: Thu, 9 Sep 1993 11:53:50 GMT

Could someone tell me if Linux is available yet on the Amiga. If so
what is the minimum hardware requirements ?

Thanks,

John (no .sig)

------------------------------

Crossposted-To: comp.os.os2.programmer.misc,comp.os.mach,comp.os.minix,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.development,comp.sys.ibm.pc.hardware,comp.sys.ibm.ps2.hardware
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: A review of the Intel 82077/82078 - a floppy drive controller
Date: Thu, 9 Sep 1993 10:57:24 GMT

Released
 
                 A review of the Intel 82077/82078
             ------------------------------------------
             (CHMOS Single-chip Floppy Disk Controller)
             ------------------------------------------
 
        CAUTION  CAUTION  CAUTION
        -------------------------
                Don't write to tell me this doesn't belong in your
        newsgroup.  All the Newsgroups I post-to have a person that
        I am coordinating with for new QIC/FDC drivers.  These
        newsgroups were started by ARPA (formerly DARPA) for R&D
        (Research and Development), which is what I am doing.
 
                Also this information is of a highly technical nature
        and may not apply to your life (problems).  So feel free
        to hit the "n" button now or put my name in your "kill file".
 
                If you want to know how the kill file works, write to:
 
                jemenaker@nike.calpoly.edu
                or
                garrett@sba70.berkeley.edu
                or
                jcburt@gastibm.larc.nasa.gov
 
 
                Before you fire off another message to me entitled:
        "You moron, 'Please do not cross-post... la-de-da'".  This
        review applies to all designers/implementors of the QIC/FDC
        on the IBM PC AT with these variations:
 
        FDC COMPATIBLE WITH: Intel 8272, NEC 765A/B
 
        BUS:  ISA/EISA/Microchannel/VESA Local/Intel Local
 
        DATA TRANSFER SPEEDS: 250/300/500/1000/2000 Kbits/sec
 
        IBM MODEL: PC-XT, PC AT, PS/2, PS/2 model 30
 
        DEVICES INVOLVED: The Standard Floppy drives,
                          FDC based QIC tape drives,
                          the 2.88 MB and 4 MB floppy drives.
 
        BENIFITS TO:  LAPTOP and systems with large bus latency.
 
 
 
        NEW Incredible features - yeah right :)
        ---------------------------------------
        Reset - defaults the chip to a standard i8272.
        A 16 Byte FIFO with system lock (neato).
        A new Perpendicular Recording Mode (supposed to be better).
        Register compatiblity with the PS/2 (more on this later).
        Tape Drive Select Register (WOW!).
        Requires a 24MHz Crystal.
 
 
 
        MEANINGLESS DRIVEL
        ------------------
 
         From: DILBERT                                  by Scott Adams
        --------------------------------------------------------------
        "-Government Statistics show that office productivity went
                *down* as computers became widely used.
         -But I didn't believe it.
         -So I wrote a little software program to test that conclusion.
         -It only took a month, but it produce some impressive data.
         -In fact, it was so impressive it took a week to figure out how
                to print it.
         -But before I could print, my computer crashed and I didn't
                have backup copies.
         -So, it seems the government was right; Computers are to
                blame for the decline in productivity.
 
         ====Do you think the employees could be partly responsible?
 
         -Sure, find a scapegoat."
        --------------------------------------------------------------
 
 
 
        THE REVIEW
        ----------
                The question remains: What about the DMA problem?
        My first line of thought is that the net has labored enough
        on this issue for now.   Help on this has come from the most
        unlikely sources.  This all gladifies me.   I am, to some extent
        overwhelmed at the trouble people are taking to corner
        me on my stupid mistakes. :) (Yipeee,,, this was non-sense.)
 
                OK, as to the question: I have several good ideas from
        people and they will be passed to the beta group for testing.
        Results will be posted when they are available.
 
 
        Beneifits
        ---------
                The reset - with a default to the "standard" Intel 8272a
        gives us assurance to some backwards compatibility.   An
        incredible amount of configuration is now available to the FDC
        including "software reset", protected settings, version
        checking, relative seeks, power down modes and more.  However,
        some problems may arise with the new DMA timing (see comments
        below).
 
                The 16 Byte FIFO is meant to beneift applications with
        the newer bus types (Microchannel, EISA, LOCAL).  The appliable
        system lock protects the FIFO from being canceled durning a soft
        reset.   Hence, the FIFO lock is meant for power-up-time
        settings by implementors.
 
                I have never heard of, till this date, a Perpendicular
        Recording Mode.  So, maybe someone in the hardware section can
        thread and let us know what this is about.
 
                The new register compatiblity with the PS/2 makes it
        possible for the QIC-40/80 implementations to work without the
        strict timing requirement support from the OS.  Also, the
        DMA problem will be negated with the new FIFO.  For us
        QIC-40/80 people this is a great plus.  What this means for me
        is - just as the serial port people recommend the NS 16550;
        I now recommend the Intel 87078 as a FDC, with qualificaitons.
        The qualification is that I haven't seen this new chip so when
        I do, I may give it more support.
 
                A new Tape Drive Select Register needs to be qualified.
        So I will check with the QIC-40/80 manufactures that I have on
        my list.
 
                The new requirement for a 24MHz Crystal will make
        allowances for drives/diskettes with more capacity.  The
        aforementioned 2 and 4 meg drives should be a seamless
        implementation.
 
                This completes my notes/comments on this subject.
        Comments, discussions, retorts, critiziums, flames, roasting,
        Toaster wars are welcome.
 
        Please leave the social remarks to a minimum (I.E., "< 10%").
 
 
        NOTES on the DMA timing chart
        -----------------------------
 
                legend
                ======
                DRQ     DMA Request signal
                DAK     DMA Acknowledge signal
                __ __
                RD/WR   READ or WRITE (driven low)
 
                                          __ __
                The new timing for DRQ to RD/WR is 6us. This is with
                                                                __ __
        threshold = 1.  The DRQ now can stay HI through DAK and RD/WR.
                                 __ __
        (YES, I said the DAK and RD/WR can be initated simultaeously.)
                 __ __
        Formerly RD/WR timing was tied to the DRQ timing (ending of
            __ __
        the RW/WR was based on DRQ initiate).   Also new the DAK may
                                                    __ __
        not invert (or revert) the signal until the RW/WR is complete.
 
        Formerly, the DAK signal-relation was not well defined (or in
 
        the National Semiconductor case it had a set (time) length).
 
___________________________________________________________________________
Jesus Monroy Jr                                          jmonroy@netcom.com
Zebra Research
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________


------------------------------

From: rogerb@x.co.uk (Roger Binns)
Subject: Re: Idea, donate a Pentium machine to Linus, anyone?
Date: Thu, 9 Sep 1993 15:59:51 GMT

yuan tzeng (t90yuan@mp.cs.niu.edu) wrote:
: Anyone also comes out with such an idea? It comes into my mind
: 5 seconds ago so I just present it :-) 

How about a 386-10Mhz with 4 Mb ram, and 20 MB disk space.  THat should
help him to improve the resource usage of linux ;-).

Roger
--
+----------------------------------------------------------------------------+
| Roger Binns          | "I can't even begin to think what they think about" |
| rogerb@x.co.uk       |  - Audrey I, Little Shop of Horrors.                |
+--------- two wheels good, four wheels bad ---------------------------------+

------------------------------

From: n62274@pbhrzx.uni-paderborn.de (Kl.Schaefers)
Subject: Re: Status of the NET-2 port
Date: 9 Sep 93 16:42:02 GMT

urlichs@smurf.sub.org (Matthias Urlichs) writes:

>In comp.os.linux.development, article <CCoyIz.9pL@provo.novell.com>,
>  jdsmith@novell.com writes:
>> Can anyone tell me about the status of the BSD NET-2 tape port?
>> 
>Hmm... what exactly are you talking about?

>I know of one port of the BSD networking code to Linux, done by me.
>Right now it is ugly, unfinished, and blocks interrupts for too long at
>times. But it works. There are no Ethernet drivers except for WD8013;
>SLIP is there, and BSDish utilities like slattach and traceroute compile

yeah, you are honest, however. There are several other people working
on the so called net-2 stuff, but they grab bsd sources, and only
remove the header :-) 

There are several probs, because ip-fragmentation
is not supported. What's about your code? NetBSD port ? Good, I even
have 1 NetBSD-system running with a wonderful net.


>/pub/systems/linux/netbsd or thereabouts, this weekend. Currently there's
>a set of patches there which people have been having difficulties with.

>Specifically, the code needs more drivers and better interrupt latency,
>the packetfilter interface has to be LINUXified, netstat should be redone,
>and a few other things.

ok. , but it's the right way .

>Matthias Urlichs -- urlichs@smurf.sub.org -- Phone: NONE; use email or lose.
>Schleiermacherstrasse 12 -- 90491 Nuernberg -- Germany || Linux+Mac Consulting

Good luck
Klaus

--
  / \  n62274@pbhrzx.uni-paderborn.de
<< * >>    klaus@elostar.ms.sub.org
  \ /      Fidonet:  2:242/55.21          
         Realname: Klaus Schaefers

------------------------------

From: keith%gondor@concert.net (Keith B. Kee)
Subject: HELP: tar
Date: 9 Sep 1993 14:13:53 -0400
Reply-To: keith%gondor@concert.net (Keith B. Kee)

The tar which came with SLS1.02 doesn't seem to work with 4mm SCSI tape drive.
I was able to read the tar with my sun SPARC II, and pc under OS/2, but
no luck with Linux.

The message it gave was:
     wrong blocksize xxxxx

What does that mean?


Thanks,
keith
keith@aisg.com

------------------------------

From: michaelw@desaster.hanse.de (Michael Will)
Subject: 99p13Alpha: wierd swap'n'hang behavor
Date: Thu, 9 Sep 1993 11:09:08 GMT

Sorry, I am not on the mailing list, so...

I have applied the alpha-13-patches, and anything compiled nice, even
some of the rs232-problems disappeared, or at least - changed...

I had a uucico running, which worked nicely with i-protocol and at the same
time stuffed my swapspace by computing a large jpg onto my screen.
After that, uucico remained swapped, status D, and could not be removed
with a "kill -9".

I have an i386dx33 with 387, ne2000, 16550, 8MB-RAM, 8MB Swappartition on
/dev/hda1, AHA1542 and /dev/sda. 

gcc 2.4.5 of course :-)

Any help welcome - for now I have to keep stuck with p12 then - sigh...

Cheers, Michael Will
-- 
Michael Will <michaelw@desaster.hanse.de>     Linux - share and enjoy :-)
Life is not there if you can't share it... Hazel'O'Connor  Breaking Glass
Happily using Linux 0.99p12 with X11R5, \LaTeX, cnews/nn/uucp and: PGP!
             >>> Ask for Linux and / or pgp-Information <<<

------------------------------

From: gt6698a@prism.gatech.EDU (Andrew Hobson)
Subject: socket programming question
Date: 9 Sep 93 18:51:45 GMT

Hello.  Included below is a program I picked up from comp.unix.admin
(I think).  It tries to connect to all of the ports of a particular
machine to see if the service connection is available.  It works under
SunOS, but not under linux.  I believe the problem is that is does a 

struct sockaddr_in SocketInetAddr;

connect(SocketDescriptor, &SocketInetAddr,  sizeof(SocketInetAddr));

I know connect takes at its second argument (* struct sockaddr).  So I
guess what I am asking is, why does this work on SunOS and not on
Linux?  And is there a quick and easy way to convert struct
sockaddr_in to struct sockaddr?

I think other programs also use this "technique", such as xtrek.

I am sorry if this is a really stupid question.  Please email me and I
will summarize if there is interest, or if you believe it is of
general interest feel free to post.

Drew

==========================================================================

/*
 * probe_tcp_ports
 */

#include <sys/types.h>
#include <sys/stat.h>
#include <stdio.h>
#include <ctype.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>

#define RETURN_ERR      -1
#define RETURN_FAIL     0
#define RETURN_SUCCESS  1

int             Debug;
int             Hack;
int             Verbose;

main(ArgC, ArgV)
        int             ArgC;
        char          **ArgV;
{
        int             Index;
        int             SubIndex;

        for (Index = 1; (Index < ArgC) && (ArgV[Index][0] == '-'); Index++)
            for (SubIndex = 1; ArgV[Index][SubIndex]; SubIndex++)
                switch (ArgV[Index][SubIndex])
                {
                case 'd':
                        Debug++;
                        break;
                case 'h':
                        Hack++;
                        break;
                case 'v':
                        Verbose++;
                        break;
                default:
                        (void) fprintf(stderr,
                "Usage: probe_tcp_ports [-dhv] [hostname [hostname ...] ]\n");
                        exit(1);
                }

        for (; Index < ArgC; Index++)
                (void) Probe_TCP_Ports(ArgV[Index]);
        exit(0);
}

Probe_TCP_Ports(Name)
        char           *Name;
{
        unsigned        Port;
        char           *Host;
        struct hostent *HostEntryPointer;
        struct sockaddr_in SocketInetAddr;
        struct hostent  TargetHost;
        struct in_addr  TargetHostAddr;
        char           *AddressList[1];
        char            NameBuffer[128];

        extern int      inet_addr();
        extern char    *rindex();

        if (Name == NULL)
                return (RETURN_FAIL);
        Host = Name;
        if (Host == NULL)
                return (RETURN_FAIL);
        HostEntryPointer = gethostbyname(Host);
        if (HostEntryPointer == NULL)
                {
                TargetHostAddr.s_addr = inet_addr(Host);
                if (TargetHostAddr.s_addr == -1)
                        {
                        (void) printf("unknown host: %s\n", Host);
                        return (RETURN_FAIL);
                        }
                (void) strcpy(NameBuffer, Host);
                TargetHost.h_name = NameBuffer;
                TargetHost.h_addr_list = AddressList, TargetHost.h_addr = 
                        (char *) &TargetHostAddr;
                TargetHost.h_length = sizeof(struct in_addr);
                TargetHost.h_addrtype = AF_INET;
                TargetHost.h_aliases = 0;
                HostEntryPointer = &TargetHost;
                }
        SocketInetAddr.sin_family = HostEntryPointer->h_addrtype;
        bcopy(HostEntryPointer->h_addr, (char *) &SocketInetAddr.sin_addr,
                HostEntryPointer->h_length);

/* for non BSDish systems
        memmove(HostEntryPointer->h_addr, (char *) &SocketInetAddr.sin_addr,
                HostEntryPointer->h_length);
*/

        for (Port = 1; Port < 65536; Port++)
                (void) Probe_TCP_Port(Port, HostEntryPointer, SocketInetAddr);
        return (RETURN_SUCCESS);
}

Probe_TCP_Port(Port, HostEntryPointer, SocketInetAddr)
        unsigned        Port;
        struct hostent *HostEntryPointer;
        struct sockaddr_in SocketInetAddr;
{
        char            Buffer[BUFSIZ];
        int             SocketDescriptor;
        struct servent *ServiceEntryPointer;


        SocketInetAddr.sin_port = Port;
        SocketDescriptor = socket(AF_INET, SOCK_STREAM, 6);
        if (SocketDescriptor < 0)
                {
                perror("socket");
                return (RETURN_ERR);
                }
        if (Verbose)
                {
                (void) printf("Host %s, Port %d ", HostEntryPointer->h_name,
                              Port);
                if ((ServiceEntryPointer = getservbyport(Port, "tcp")) !=
                    (struct servent *) NULL)
                        (void) printf(" (\"%s\" service) ",
                                      ServiceEntryPointer->s_name);
                (void) printf("connection ... ");
                (void) fflush(stdout);
                }
        if (connect(SocketDescriptor, (char *) &SocketInetAddr,
                    sizeof(SocketInetAddr)) < 0)
                {
                if (Verbose)
                        (void) printf("NOT open.\n");
                if (Debug)
                        perror("connect");
                }
        else
                {
                if (!Verbose)
                        {
                        (void) printf("Host %s, Port %d ",
                                      HostEntryPointer->h_name, Port);
                        if ((ServiceEntryPointer = getservbyport(Port,"tcp")) !=
                            (struct servent *) NULL)
                                (void) printf(" (\"%s\" service) ",
                                              ServiceEntryPointer->s_name);
                        (void) printf("connection ... ");
                        (void) fflush(stdout);
                        }
                (void) printf("open.\n");
                if (Hack)
                        {
                        (void) sprintf(Buffer, "/usr/ucb/telnet %s %d",
                                       HostEntryPointer->h_name, Port);
                        (void) system(Buffer);
                        }
                }

        (void) close(SocketDescriptor);
        return (RETURN_SUCCESS);
}


--
begin 644 gt6698a@prism.gatech.edu.booby.trap.yes.it.is.gzipped.twice.z.z
M'XL(`,>?#RP"`Y/OYF"8.9]?AXGY[<%&!B`XK##_)[/<DU!&AE$P"D;!*!@%
9HV`4##S(9^-;$,O:T"+'``#DAO:DM0<``"`X
` yes, I know it doesn't have an end line, it will uudecode fine. Or add one.

------------------------------


** 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
******************************
