From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sat, 18 Sep 93 06:13:07 EDT Subject: Linux-Development Digest #107 Linux-Development Digest #107, Volume #1 Sat, 18 Sep 93 06:13:07 EDT Contents: Re: mapping high memory (Jon Tombs) Re: Anybody ever try crashme on Linux? (Alain knaff) Re: To all device driver writers; boot-time messages. (Donald J. Becker) Re: Status of the NET-2 port (Donald J. Becker) Re: [Q] biff and comsat? (Rafal Maszkowski) Re: Status of the NET-2 port (Fred N. van Kempen,Voorhout,+31-2522-30205,+31-2522-30205) Re: Strange 'ping' behaviour (Linus Torvalds) Re: Another multiple sector IDE driver... (Jan Richert) PATCH!:Linux and a mouse demon (Re:Whatdopeoplethinkabout/config?) (Tuomas J Lukka) Re: Test of the Intel 8254 shut-down/parity-check command (Jesus Monroy Jr) ---------------------------------------------------------------------------- Crossposted-To: comp.os.linux.help From: jon@robots.ox.ac.uk (Jon Tombs) Subject: Re: mapping high memory Date: Sat, 18 Sep 1993 00:45:36 GMT In article <27d7u0$pmd@viper.CS.Berkeley.EDU> curtis@viper.CS.Berkeley.EDU (Curtis Yarvin) writes: > >I'm working with a video card (Cornerstone CVC-2) that can map >its frame buffer into the extended address space. So I put it >at 14-16 MB, which is fine because I only have 8MB, and then... >I'm having trouble mapping it into the user (X server) address >space. mmap(/dev/mem) doesn't work. > >Is there any way I can do this from user mode? Or do I have to >write a device driver? What kernel are you using? With the straight pl12 kernel you need to use MAP_FIXED in order to map /dev/mem. If you get the latest ALPHA-pl13 kernel you can use mmap without the mallocing space first. To map /dev/mem, address Base onto pointer base for length Size you can open /dev/mem (fd) and use the following. base = (pointer)mmap((caddr_t)0, Size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, (off_t)Base); I use this to mmap the S3 localbus video memory that is often around the 128MB mark, as of the earlier ALPHA-pl13 this works fine. Jon. ------------------------------ From: knaff@imag.fr (Alain knaff) Subject: Re: Anybody ever try crashme on Linux? Date: Fri, 17 Sep 1993 16:32:27 GMT -- s9329053@sandcastle.cosc.brocku.ca (Darcy Boese) writes: >You want to crash Linux? Simple as pie... > >Try deleting a file on a DOS disk using mtools when the disk is >write-protected... Or even simpler, try this small C-program: main(){main();} It doesn't exactly crash the machine, but it locks it up quite efficiently, espacially if run from an xterm... I had to reboot my computer after trying this out. It is also quite amusing on DECstations too,... (The DEC didn't need a reboot, but it took several seconds to react to my Control-C, and even after that, the xterm where I ran the program from was in a messy state...) -- AK ------------------------------ From: becker@super.org (Donald J. Becker) Subject: Re: To all device driver writers; boot-time messages. Date: Fri, 17 Sep 1993 18:44:13 GMT In article <27c5fp$17g@bambi.zdv.uni-mainz.de>, Dominik Kubla wrote: >I agree with you about the boot-time messages, but i think we should leave an >option to include drivers for non-detected hardware: That was the tie-in with the "wish list" subject: A mechanism to scan the boot-time messages should only produce a list of defaults, which can then be accepted as-is, edited, or interactively changed. I'm still looking for comments on the main points, especially suggestions on the content and (loose) format of boot-time messages. >But i am thinking of another configuration scheme, which seems better suited >for networks and development: > All drivers build their own objects which are copied to a special directory > let's call it /kernel. Then you run a special makefile which just links the > desired modules to the core (consisting of swapper, scheduler, i/o-monitor, > and what else is independent from the driver selection.) You are forgetting the initialization calls. > This way you can > easily upgrade drivers, create special kernels with/without certain drivers > and commercial software/hardware developers can provide binary only drivers. This would be a Very Bad Thing. Luckily the GPL should protect the kernel itself from object-only distributions. [[ Slightly off topic here...]] But if we had a standard, published interface definition for loadable device drivers I suspect it would take only weeks before we had proprietary, binary-only drivers. People with a short-term perspective might not find that dangerous, or even undesirable, but I certainly do. >BTW: Donald, there is some problem with the 3COM EtherLink II driver: > Our EL2 is configured to IRQ9, but the auto-detection code always detects > IRQ5. I guess the problem is a spurious interrupt from the 2nd parallel > port. Bad guess. There is no way to configure the 3c503/EL2 to a specified address, so the driver selects the first free IRQ (free in both hardware and software) in the order {5, 2/9, 3, 4}. Does this happen incorrectly with your hardware? Several people have reported a spurious interrupt-conflict message that sometimes occurs just after booting. This doesn't cause a function problem, and I'll try to track it down when I can find a 3c503 to borrow. -- Donald Becker becker@super.org IDA Supercomputing Research Center 17100 Science Drive, Bowie MD 20715 301-805-7482 ------------------------------ From: becker@super.org (Donald J. Becker) Subject: Re: Status of the NET-2 port Date: Fri, 17 Sep 1993 20:47:49 GMT In article <1993Sep17.170934.17178@aston.ac.uk>, Mark Evans wrote: >I wonder how much of the initialisation code could be shared between >the PLIP and parallel printer drivers. Checking the same piece of >hardware to see if exists twice appears to be overkill. PLIP's probe for the parallel port is pretty trivial, it would take more code space to share the probe. But perhaps people are annoyed with multiple plip boot-time messages? Should we get rid of all but one? >: Coupled with this is my frustration at the way new bugs were introduced >: with "Net-2", and then "development team" abandoned the code with the >: promise "everything will be fixed when we come out with yet another >: completely new structure". I feel hamstrung, because any improvement > >Such as? There cannot be very many sensible data structures to hold an >IP datagram. I was referring to the overall structure and layering of the source code, not a particular type of 'struct'. Check out DDI, which is intended to eventually encompass all device drivers. >: A notable example is the use of 'mbufs', a structure that >: is at the core of BSD networking. It was designed to hold packets as >: a linked list of protocol headers and data pages. This was a good >... >Most notably in fragment reassembly, the original size of the datagram >is unknown until the last (the one without the more-fragments bit set) >arrives, this is quite likely to be the last to arrive. >So that enforcing a linear buffer all the time has an >allocate-copy-deallocate cycle of buffer. You don't need to realloc() a new data buffer every time a packet comes in -- that would be silly. What you do is allocate a reasonable-sized data buffer, perhaps 4K-- long. (An IP implementation is only required to reassemble a ~576-byte packet, but bigger is better.) As each fragment comes in you fill in the packet. If you are clever, you keep track of the "holes" instead of the "fills". If you are very clever (like, say, MIT people sometimes were;-) you keep your list of holes _in_ the holes. When the last packet comes in and I've run out of holes, I ship the whole packet off to the upper layers instead of the small one. An alternate implementation, keeping a linked list of fragments, is used in Net-2e. With a linked list you have to keep all of packets around (with a big overhead for each one), and either painfully insert each one into its proper place, or sort the list when you think you have them all. Think about what happens if you have a router that always tends to drop the N'th fragment since frags are usually back-to-back to the same destination. Comments? Suggestions? [[ Pedants should pardon my looseness with "packet". People find it easier to understand than using the precise "frame" "segment"... terms. Also note you always have to record the offset-0 frag packet for ICMP and options.]] >: idea in the days of microcoded machines with complex addressing modes, >: short pipelines, and very small memories. On modern machines they are >: slower than storing always storing the packet linearly. (Would > >I have wondered about using a linked structure, optimised to minimise >copying. Though this needs quite a bit of modifications in various places. >Depends how bored I get this weekend. One thing I've been thinking about is using a linked list only for "mongo" packets of >4K. Protocols with normal-sized packets wouldn't have to check yet we could still deal with 8K UDP packets. Alternately we could put an indirect-block-list in sk_buff to allow really big segments. Both of these would be easy to implement, but add complexity. For the near term, keeping around a special-case pool for 8K NFS/UDP packets seems to be the fastest and easiest solution to handling the only common big-packet reassembly task. >: someone care to comment on how many times 'mpullup()' occurs in BSD, >: and how expensive it is?) > [blank space] No comment on that one, eh? -- Donald Becker becker@super.org IDA Supercomputing Research Center 17100 Science Drive, Bowie MD 20715 301-805-7482 ------------------------------ From: rzm@oden.oso.chalmers.se (Rafal Maszkowski) Subject: Re: [Q] biff and comsat? Date: Sat, 18 Sep 1993 02:02:12 GMT Johannes Grosen (grosen@argv.cs.ndsu.nodak.edu) wrote: : In article <1993Sep16.141819.23697@nrao.edu> rzm@oden.oso.chalmers.se (Rafal Maszkowski) writes: : >Have anybody ported biff and comsat (are these 2 enough to get : I have `ported' them to my machine but there really isn't any need if you : are running `bash' as your shell. Check the `MAIL' and `MAILPATH' You mean You have new mail in /var/spool/mail/rzm? I like it but like all those beepings and flashes from comsat more. I only don't know how to run it. I tried from both inetd.conf and standalone. As far as I understand comsat listens on udp 512 - but which program is sending user@offset there? R. PS. if such questions are more apropriate for col.help - follow there. -- Rafal Maszkowski rzm@oso.chalmers.se rzm@mat.torun.edu.pl <-finger for public snail: Omgangen 464-82, 412-80 Goteborg, Sweden; tel: +46-31-7780831 key Opinia publiczna powinna byc zaalarmowana swoim nieistnieniem - S.J.Lec ------------------------------ From: waltje@metallica (Fred N. van Kempen,Voorhout,+31-2522-30205,+31-2522-30205) Subject: Re: Status of the NET-2 port Date: Fri, 17 Sep 93 21:22:27 ABout this endless BSD vs. GPL crap, Matt [Welsh] writes: : Yes. I am aware now that there is very little problem (legally) with : including BSD code in a GPL application as long as proper credit is : given (it is not given, by the way, in kernels previous to 0.99.pl13a. : Thanks to Don Becker, it is now.) Hmm, as far as I know (and I should, considering the fact that I am supposed to maintain it...), there has ALWAYS been a file called `COPYRIGHT' in the SLIP driver directory, bearing the contents of the version ID's and UCB Statement of Copyright wrt. the SLHC code. Fred -- ------------------------------ From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Subject: Re: Strange 'ping' behaviour Date: 18 Sep 1993 10:20:43 +0300 In article <1993Sep17.115543.907@hotblack.sh.sub.org>, Andreas Mengel wrote: >Hi there! > >I just found that ping behaves very strange. I just ping'ed myself and after >reporting 32 (icmp_seq=0..31) successful pings it just stops ! >It seems to send out the packet with icmp_seq=32, but does not receive any >response on that. It doesn't send out further packets either (if I hit ^C after >some time it reports: > 64 bytes from 127.0.0.1: icmp_seq=31 ttl=119 time=0 ms > > --- localhost ping statistics --- > 33 packets transmitted, 32 packets received, 3% packet loss > round-trip min/avg/max = 0/0/1 ms > >'ps al' says it hanging on interrupt (WCHAN=interrupt). > >This is linux-0.99.ALPHA-13 with networking stuff from SLS1.02 Get the really latest ALPHA-pl13 which should fix this loopback bug. It's not ping, it's the kernel. I'll make a real pl13 this weekend, I think. Linus ------------------------------ From: jrichert@krefcom.GUN.de (Jan Richert) Subject: Re: Another multiple sector IDE driver... Date: Fri, 17 Sep 1993 16:50:53 GMT jrichert@krefcom.GUN.de (Jan Richert) writes: >fsommer@krefcom.GUN.de (Frank Sommer) writes: >>Here is my multiple sector IDE driver with EISA support. >>Any suggestions and comments should be directed to: >Hi.. >I'm quite happy with this driver.. at least it did not (yet) >corrupt my filesystem as Mark Lord's did (sorry). Aaaaaaaaarrrrghh!! I shouldn't have posted this! Some minutes later my file system was corrupted (ST1239A drive) just the same way as with Mark Lord's patch. This means masses of "data out of iozone" errors. The problem occured at the moment when Usenet News were sorted in.. the same sittuation that "broke" Mark Lord's patch... No more hd patches for me - thanks! Jan -- Jan Richert (NIC-ID: JR482) | Internet: jrichert@krefcom.GUN.de Krefeld, FRG | Datex-J: 02151399843-0001 Voice: +49 2151 313124 | IRC-Nick: jrichert FAX: +49 2151 396479 | Data: +49 2151 396479 (12-20h MEDT) ------------------------------ From: lukka@klaava.Helsinki.FI (Tuomas J Lukka) Subject: PATCH!:Linux and a mouse demon (Re:Whatdopeoplethinkabout/config?) Date: 18 Sep 1993 12:37:40 +0300 > Also, outside of selection, has anyone thought of a way to allow >hooking into the mouse in an easy, integrated into linux way? What do >people thing about some mouse hook routines as part of the linux api? I've actually done this. I've patched my A-pl13 kernel and selection to use the xterm control codes for mouse tracking on the consoles that want it and standard selection on others. It's not perfect but it's a proof-of-a-concept thing. I made them to be able to use, on a vc, the new fancy newsreader (strn) that uses xterm mouse tracking at school. Now if only someone would extend ncurses to use this and make a fancy text-mode windowing system ;) I'm not sure if I'm going to do anything with these patches ever any more.. if someone wants to start maintaining them, please drop me line. What I'd like to see is a possibility for graphics use, the modifiers returned, possibility to get selection buffer from the mousing process etc. The patches are against a not-newest ALPHA-pl13 and selection-1.5. As usual, should any of your disk drives halt and catch fire, the agency will deny any everything. Happy hacking! Tjl --- clip for selection-patch diff -ru selection-1.5/mouse.c selection-hack/mouse.c --- selection-1.5/mouse.c Thu Jun 17 23:11:04 1993 +++ selection-hack/mouse.c Thu Sep 16 13:34:26 1993 @@ -240,7 +240,7 @@ } int -get_ms_event(struct ms_event *ev) +real_get_ms_event(struct ms_event *ev) { unsigned char buf[5]; char dx, dy; diff -ru selection-1.5/mouse.h selection-hack/mouse.h --- selection-1.5/mouse.h Thu Jun 17 23:11:04 1993 +++ selection-hack/mouse.h Thu Sep 16 13:37:44 1993 @@ -30,5 +30,6 @@ void ms_params(int argc, char *argv[]); int ms_init(const int maxx, const int maxy); int get_ms_event(struct ms_event *ev); +int real_get_ms_event(struct ms_event *ev); #endif /* MOUSE_H */ Only in selection-hack: mouse.o Only in selection-hack: selection diff -ru selection-1.5/selection.c selection-hack/selection.c --- selection-1.5/selection.c Thu Jun 17 23:11:04 1993 +++ selection-hack/selection.c Thu Sep 16 14:10:30 1993 @@ -36,6 +36,7 @@ struct timeval tv1, tv2; int xs, ys, xe, ye, x1, y1, fd, clicks = 0; sel_mode mode; + int i; fd = open_console(O_RDONLY); ioctl(fd, TIOCGWINSZ, &win); @@ -54,6 +55,10 @@ gettimeofday(&tv1, (struct timezone *)NULL); + for(i=0; i<10; i++) /* The first few events are garbage on my mouse, eat them */ + if (get_ms_event(&ev)) + exit(1); + restart: while (1) { @@ -135,6 +140,39 @@ } } } + +int +get_ms_event(struct ms_event *ev) +{ + unsigned char buf[sizeof(char) + 5 * sizeof(short)]; + unsigned short *arg = (unsigned short *)(buf + 1); + int fd; + int ret; + static int butstate=0; + if((ret=real_get_ms_event(ev))) + return ret; + + buf[0] = 4; + + arg[0] = ev->ev_x/SCALE+1; + arg[1] = ev->ev_y/SCALE+1; + arg[2] = (butstate < ev->ev_butstate); /* 1=press, 0=release */ + arg[3] = (1-2*arg[2])*(butstate - ev->ev_butstate); /* XXX */ + butstate=ev->ev_butstate; + + printf("Sending: x=%d,y=%d,press=%d,buts=%d\n",(int)arg[0],(int)arg[1],(int)arg[2], + (int)arg[3]); + + fd = open_console(O_WRONLY); + if (ioctl(fd, TIOCLINUX, buf) < 0) + { + perror("selection: ioctl(..., TIOCLINUX, ...)"); + exit(1); + } + close(fd); + return 0; +} + /* We have to keep opening and closing the console because (a) /dev/tty0 changed its behaviour at some point such that the current VC is fixed Only in selection-hack: selection.o Only in selection-hack: test-mouse diff -ru selection-1.5/test-mouse.c selection-hack/test-mouse.c --- selection-1.5/test-mouse.c Thu Jun 17 23:11:04 1993 +++ selection-hack/test-mouse.c Thu Sep 16 13:39:14 1993 @@ -39,7 +39,7 @@ } while (1) { - if (get_ms_event(&ev)) + if (real_get_ms_event(&ev)) { perror("get_ms_event"); exit(1); Only in selection-hack: test-mouse.o =========== Clip for kernel=patch Only in linux/kernel/chr_drv: .depend Only in linux/kernel/chr_drv: atixlmouse.o Only in linux/kernel/chr_drv: busmouse.o Only in linux/kernel/chr_drv: chr_drv.a diff -ru linux-orig/linux/kernel/chr_drv/console.c linux/kernel/chr_drv/console.c --- linux-orig/linux/kernel/chr_drv/console.c Fri Aug 13 20:08:47 1993 +++ linux/kernel/chr_drv/console.c Sat Sep 18 12:24:03 1993 @@ -133,6 +133,12 @@ unsigned char * vc_G1_charset; unsigned char * vc_saved_G0; unsigned char * vc_saved_G1; +#define MOUSETRACK +#ifdef MOUSETRACK +/* Limited mouse tracking a la xterm support: button presses and releases can be + reported. No hilite tracking yet, though */ + unsigned long vc_mousetrack: 2; /* 0=not, 1=old, 2=new */ +#endif /* additional information is in vt_kern.h */ } vc_cons [NR_CONSOLES]; @@ -187,6 +193,7 @@ #define halfcolor (vc_cons[currcons].vc_halfcolor) #define kbdmode (vc_cons[currcons].vc_kbdmode) #define tab_stop (vc_cons[currcons].vc_tab_stop) +#define mousetrack (vc_cons[currcons].vc_mousetrack) #define vcmode (vt_cons[currcons].vc_mode) #define vtmode (vt_cons[currcons].vt_mode) #define vtpid (vt_cons[currcons].vt_pid) @@ -755,6 +762,14 @@ deccm = on_off; set_cursor(currcons); break; +#ifdef MOUSETRACK + case 9: /* Mouse tracking a la xterm -- X10 */ + mousetrack=(on_off?1:0); + break; + case 1000: /* Mouse tracking a la xterm -- X11 */ + mousetrack=(on_off?2:0); + break; +#endif } else switch(par[i]) { /* ANSI modes set/reset */ case 4: /* Insert Mode on/off */ decim = on_off; @@ -1585,6 +1600,64 @@ return (v < l) ? l : ((v > u) ? u : v); } +#ifdef MOUSETRACK +int con_mousetrack(const int arg, struct tty_struct *tty) +{ + unsigned short *args, xs, ys, press, butstate; + int currcons = fg_console; + int ps; + + + if(!mousetrack) + return 0; + + unblank_screen(); + args = (unsigned short *)(arg + 1); + xs = get_fs_word(args++) - 1; + ys = get_fs_word(args++) - 1; + press = get_fs_word(args++) ; + butstate = get_fs_word(args++) ; + + xs = limit(xs, 0, video_num_columns - 1); + ys = limit(ys, 0, video_num_lines - 1); + ps = ys * video_size_row + (xs << 1); + + if (sel_cons != currcons) + { + clear_selection(); + sel_cons = currcons; + } + clear_selection(); + highlight(sel_cons, ps, ps); + sel_start = ps; + sel_end = ps; + if(butstate&7) /* Button was pressed -- send mouse tracking info */ + { + int cb; + char string[7]; + cb=3; /* By default, release. */ + if(press) { + if(butstate & 4) /* left */ + cb=0; + else if(butstate & 2) /* middle */ + cb=1; + else if(butstate & 1) /* right */ + cb=2; + } + if(mousetrack==1 && cb==3) /* X10 form: don't send release events */ + return 0; + strcpy(string,"\x1B[M"); + string[3]=cb+040; + string[4]=xs+040; + string[5]=ys+040; + string[6]=0; + respond_string(string,currcons,tty); + } + return 0; +} + +#endif + /* set the current selection. Invoked by ioctl(). */ int set_selection(const int arg) { @@ -1595,6 +1668,11 @@ int i, ps, pe; char *off = (char *)origin - hwscroll_offset; +#ifdef MOUSETRACK /* Don't do selection if this console supports mousetrack */ + if(mousetrack) + return 0; +#endif + unblank_screen(); args = (unsigned short *)(arg + 1); xs = get_fs_word(args++) - 1; @@ -1726,6 +1804,12 @@ int paste_selection(struct tty_struct *tty) { char *bp = sel_buffer; + int currcons = fg_console; + +#ifdef MOUSETRACK /* Don't do selection if this console supports mousetrack */ + if(mousetrack) + return 0; +#endif if (! *bp) return 0; Only in linux/kernel/chr_drv: console.o Only in linux/kernel/chr_drv: defkeymap.o Only in linux/kernel/chr_drv: keyboard.o Only in linux/kernel/chr_drv: lp.o Only in linux/kernel/chr_drv: mem.o Only in linux/kernel/chr_drv: mouse.o Only in linux/kernel/chr_drv: msbusmouse.o Only in linux/kernel/chr_drv: psaux.o Only in linux/kernel/chr_drv: pty.o Only in linux/kernel/chr_drv: serial.o Only in linux/kernel/chr_drv/sound: .depend Only in linux/kernel/chr_drv/sound: sound.a Only in linux/kernel/chr_drv/sound: sound_stub.o Only in linux/kernel/chr_drv: tpqic02.o Only in linux/kernel/chr_drv: tty_io.o diff -ru linux-orig/linux/kernel/chr_drv/tty_ioctl.c linux/kernel/chr_drv/tty_ioctl.c --- linux-orig/linux/kernel/chr_drv/tty_ioctl.c Wed Aug 18 01:13:07 1993 +++ linux/kernel/chr_drv/tty_ioctl.c Thu Sep 16 13:32:38 1993 @@ -535,6 +535,14 @@ case 3: return paste_selection(tty); #endif /* CONFIG_SELECTION */ +#define MOUSETRACK +#ifdef MOUSETRACK + case 4: + { + extern int con_mousetrack(const int arg, struct tty_struct *tty); + return con_mousetrack(arg,tty); + } +#endif default: return -EINVAL; } Only in linux/kernel/chr_drv: tty_ioctl.o Only in linux/kernel/chr_drv: vt.o ======== ------------------------------ Crossposted-To: comp.os.os2.programmer.misc,comp.os.minix,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.sys.ibm.pc.hardware,comp.sys.ibm.ps2.hardware From: jmonroy@netcom.com (Jesus Monroy Jr) Subject: Re: Test of the Intel 8254 shut-down/parity-check command Date: Sat, 18 Sep 1993 09:35:08 GMT Pat Mackinlay (mackinla@cs.curtin.edu.au) wrote: : jmonroy@netcom.com (Jesus Monroy Jr) writes: : : > This is a condensed version of the posting. : Although you wouldn't know it... : [much crap deleted] : > What does this prove? : Mainly that Jesus Monroy Jr doesn't know what else to do with his time : but annoy others. Does he *REALLY* think that people in all the groups : posted to give a flying fig about their DRAM refresh timing? Even if : they did, it's more likely they'd find what they needed from an Intel : tech. reference... : > Namely that the RAM refresh is controllable via : > the i8254 timer on the IBM/ISA architecture. : Gee duh, and all this time I thought my mouse controlled my refresh... : Will someone shut this guy up? : : My friend, for those with a truely ignorant nature, such as has been witnessed on these newsgroups, You are best informed that this is no bait.... and any attempts to find an Intel mannual with the information I have provide will - find you working at Macdonalds for about $4.35 an hour. have a nice day. ___________________________________________________________________________ Jesus Monroy Jr jmonroy@netcom.com Zebra Research /386BSD/device-drivers /fd /qic /clock /documentation ___________________________________________________________________________ ------------------------------ ** 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 ******************************