From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Mon, 28 Feb 94 03:13:27 EST Subject: Linux-Development Digest #507 Linux-Development Digest #507, Volume #1 Mon, 28 Feb 94 03:13:27 EST Contents: Re: Is there support for HPFS? (Chris Smith) Re: Why not put cluster diffs in nominal kernel before 1.0? (Rick) Re: Keyboard bug (Zeyd M. Ben-Halim) Amiga FileSystem, Anyone? (Sami-Pekka Hallikas) dip at 14.4?? (Jim O'Quinn) SOCKS patches for term 1.11 (enables Mosaic+term from behind firewall) (Skip Montanaro) Re: Pb writing scsi DPT driver (Martin Seine) Re: Linux and X WordPerfect (Thomas Boutell) ISDN card comments wanted (Archie Cobbs) Re: Linux and X WordPerfect (Eric Youngdale) Re: Specialix driver (Robert Lipe) Re: RF Info on pty handling (J. Cowley) ---------------------------------------------------------------------------- From: csmith@convex.com (Chris Smith) Subject: Re: Is there support for HPFS? Date: 28 Feb 1994 01:13:46 GMT From: davison@bruce.cs.monash.edu.au (Andrew Davison) Date: 27 Feb 1994 01:55:41 GMT Hopefully somebody is still working on the read/write [HPFS]... Somebody is still planning to, but don't hold your breath. Not only will it not make 1.0, it may not make 2.0. (Things are busy at work.) The data structures are all in hpfs.h, if someone else is interested in writing some code, do feel free. Especially if you have experience doing concurrent updates to B-tree databases. ------------------------------ From: pclink@qus102.qld.tne.oz.au (Rick) Subject: Re: Why not put cluster diffs in nominal kernel before 1.0? Date: Sun, 27 Feb 1994 23:36:01 GMT muts@compi.hobby.nl (Peter Mutsaers) writes: >I don't want to miss the cluster diffs, even for IDE disks. This >afternoon I compared 15d with cluster-08a with 15h (without cluster >diffs since 08a cannot patch 15h :-( ) and 15d with cluster-08a did >800kb/s read and write on an ext2 filesystem on an IDE disk, 15h did >only 550kb/s. Measured with iozone. While cluster-08a on pl15a and pl15h boost the iozone performance on my FD885+767Mb Seagate, fsck runs 3-4 times slower on a 75% full 200Mb ext2 partition. Anybody else noticed this? Rick. ------------------------------ From: zmbenhal@netcom.com (Zeyd M. Ben-Halim) Subject: Re: Keyboard bug Date: Mon, 28 Feb 1994 01:09:52 GMT In article <1994Feb24.091143.8381@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes: >In article <2khjek$6ob@sleepy.cc.utexas.edu> jc@sleepy.cc.utexas.edu (Jonathan Clark) writes: >> Possible keyboard driver bug : the key 'r' does not come through >>when the keyboard is put in K_RAW mode. Instead the Scroll Lock light >>blinks. Does anyone know why and how I can a. get around this, or b. >>fix it. I am writing a video game for Linux and would prefer that >>any user could run the game (without having to patch). >> >> Thanks, >> JC > >Put the tty into RAW mode too. (the same ioctls stty raw would use). The >scan code for r is translating into the ascii code for a flow control character. >(I think ctrl-s) What is your definition of RAW mode? You need to turn off IXON and IXOFF in addition to ICANON, ECHO, and ISIG. Zeyd -- --- Zeyd M. Ben-Halim zmbenhal@netcom.com 10479 1/4 Santa Monica Blvd, LA, CA, 90025 (310) 470-0281 ------------------------------ From: semi@dream.nullnet.fi (Sami-Pekka Hallikas) Subject: Amiga FileSystem, Anyone? Date: Sun, 27 Feb 1994 07:28:14 GMT Does anyone developing WORKING Amiga filesystem, that you can read amiga disks with you Linux machine. I really like to get this FS if anyone is working with it. I tried old AFFS but it didn't worked anyway :-/. -- +--------------------------+----------+-------------------------------------+ | semi@dream.nullnet.fi | OH1KYL | MAIL MEDIA. Do Not Expose to Flame! | | samip@freeport.uwasa.fi +----------+-------------------------------------| | semi@freenet.hut.fi | Dream World BBS * 358-21-4389843 * 24H * 9600 | +--------------------------+------------------------------------------------+ ------------------------------ From: oquinn@vern.bga.com (Jim O'Quinn) Subject: dip at 14.4?? Date: 28 Feb 1994 03:41:59 GMT Is there a set of patches for dip that will run my modem at 14.4? 9600 is wwwaaayy tttooo ssslllloooowwwww..... Thanks in advance, Jim O'Quinn oquinn@bga.com ------------------------------ Crossposted-To: comp.os.linux.help From: montnaro@spyder.crd.ge.com (Skip Montanaro) Subject: SOCKS patches for term 1.11 (enables Mosaic+term from behind firewall) Reply-To: montanaro@ausable.crd.ge.com (Skip Montanaro) Date: Mon, 28 Feb 1994 04:22:03 GMT A couple days ago, I posted a note to comp.os.linux.help asking how I could use Mosaic+term when my remote term program was behind a firewall. Using Mosaic+term, I could retrieve stuff on the local net at work (like my home page), but couldn't get to external hosts. At our site, we run the ever impressive SOCKS daemon and clients (mostly Mosaic, ftp, and telnet), so I SOCKSified term 1.11 (using SOCKS 4.1). Worked like a charm, except for ftp. The patches are attached to this note for anyone interested. They've only been tested in the context I'm interested in - running Mosaic+term from home to a remote term behind a firewall. I believe ftp fails because Mosaic+term does not set PASV mode for ftp transfers. Term knows nothing about any ftp servers wanting to establish data connections on occasion, so data never gets transferred. Attempts to access anonymous ftp sites just spin Mosaic's globe. ========== *** Makefile Sun Feb 27 22:37:31 1994 --- Makefile~ Sat Jan 8 01:23:32 1994 *************** *** 16,22 **** DEBUGFLAGS= $(DEBUG) -O - SOCKSFLAG = -DSOCKS - SOCKSLIB = -L/usr/local/lib -lsocks -lresolv - # # action --- 16,19 ---- *************** *** 24,28 **** # -DLOGIN_SHELL causes trsh to start a login shell by default ! CFLAGS= $(DEBUGFLAGS) -DLOGIN_SHELL $(OSFLAGS) $(SOCKSFLAG) LINKFLAGS=-O $(OSLINK) --- 21,25 ---- # -DLOGIN_SHELL causes trsh to start a login shell by default ! CFLAGS= $(DEBUGFLAGS) -DLOGIN_SHELL $(OSFLAGS) LINKFLAGS=-O $(OSLINK) *************** *** 79,83 **** sun: ! $(MAKE) AR="ar rc" RANLIB=ranlib LIBS="$(SOCKSLIB)" $(DO) sgi: --- 76,80 ---- sun: ! $(MAKE) AR="ar rc" RANLIB=ranlib $(DO) sgi: *************** *** 155,159 **** tupload: $(UPLOADOBJS) ! $(CC) $(LINKFLAGS) -o tupload $(UPLOADOBJS) $(LIBS) $(SOCKSLIB) tredir: $(REDIROBJS) --- 152,156 ---- tupload: $(UPLOADOBJS) ! $(CC) $(LINKFLAGS) -o tupload $(UPLOADOBJS) $(LIBS) tredir: $(REDIROBJS) *** connect.c Sun Feb 27 22:31:04 1994 --- connect.c~ Thu Jan 6 00:34:02 1994 *************** *** 123,132 **** } c = &cons[i]; - #ifdef SOCKS - c->client = Raccept(svs[loop], (struct sockaddr *) &dum, &sdum); - #else c->client = accept(svs[loop], (struct sockaddr *) &dum, &sdum); - #endif - if ((c->server = get_server(loop)) <0) { --- 123,127 ---- *** link.c Sun Feb 27 22:31:02 1994 --- link.c~ Tue Jan 4 07:11:56 1994 *************** *** 387,395 **** } /* try the actual accept(). */ - #ifdef SOCKS - s = Raccept(clients[s].fd , (struct sockaddr *) &dummy, &din); - #else s = accept(clients[s].fd , (struct sockaddr *) &dummy, &din); - #endif if (s < 0) { ret_fail(cl, local, 1, "Accept failed"); --- 387,391 ---- *************** *** 484,494 **** atoi(portname) ); - #ifdef SOCKS - if (Rconnect(s,(struct sockaddr *)&addr,sizeof(struct - sockaddr_in))<0) { - #else if (connect(s,(struct sockaddr *)&addr,sizeof(struct sockaddr_in))<0) { - #endif ret_fail(cl,local, 1, "connect() failed"); perror ("connect"); --- 480,485 ---- *************** *** 646,654 **** } k=sizeof(addr); - #ifdef SOCKS - if (Rgetsockname(s, &addr, &k) < 0) { - #else if (getsockname(s, &addr, &k) < 0) { - #endif ret_fail(cl, local, 1, "getsockname() failed"); DEBUG_FP(stderr, "%s:getsockname failed\n", term_server); --- 637,641 ---- *** main.c Sun Feb 27 22:27:51 1994 --- main.c~ Sat Jan 8 01:09:36 1994 *************** *** 328,333 **** fprintf(stderr, "Term version: %s\r\n", VERSION); - SOCKSinit(argv[0]); - /* initalize character escapeing. */ for (i = 0; i < 256;i++) { --- 328,331 ---- *************** *** 714,722 **** struct sockaddr_un dummy; int din = sizeof(dummy); - #ifdef SOCKS - i = Raccept(socket , (struct sockaddr *) &dummy, &din); - #else i = accept(socket , (struct sockaddr *) &dummy, &din); - #endif if (i >= 0) { /* a new client */ j = new_client(); --- 712,716 ---- *** redir.c Sun Feb 27 22:38:59 1994 --- redir.c~ Thu Jan 6 00:39:49 1994 *************** *** 44,50 **** int first, i; int svs[MAXREDIR]; - - SOCKSinit(argv[0]); - signal(SIGPIPE, SIG_IGN); first = client_options(argc, argv,"",NULL); --- 44,47 ---- *** socket.c Sun Feb 27 22:25:23 1994 --- socket.c~ Tue Oct 26 09:22:44 1993 *************** *** 56,66 **** /* this way.. We try a maximum of 100 */ /* times... */ - #ifdef SOCKS - while (Rbind(s, (struct sockaddr * ) &sin, - sizeof(sin), sin.sin_addr.s_addr) < 0) { /* while an error.. */ - #else while (bind(s, (struct sockaddr * ) &sin, sizeof(sin)) < 0) { /* while an error.. */ - #endif if (errno != EADDRINUSE) { /* if it wasn't in use */ close(s); --- 56,61 ---- *************** *** 71,79 **** } - #ifdef SOCKS - if (Rlisten(s, 5) == -1) { /* If we can't listen... */ - #else if (listen(s, 5) == -1) { /* If we can't listen... */ - #endif perror("listen"); /* then just dump. We can't handle */ /* errors here. */ --- 66,70 ---- *** tmon.c Sun Feb 27 22:39:27 1994 --- tmon.c~ Thu Feb 11 20:13:49 1993 *************** *** 139,144 **** struct tms Tbuf; - SOCKSinit(argv[0]); - timeout.tv_sec = 0; timeout.tv_usec = 0; --- 139,142 ---- *** trshell.c Sun Feb 27 22:38:12 1994 --- trshell.c~ Tue Mar 9 00:12:22 1993 *************** *** 86,91 **** char * f; - SOCKSinit(argv[0]); - priority = 2; --- 86,89 ---- *** xconn.c Sun Feb 27 22:38:33 1994 --- xconn.c~ Sat Jan 8 01:04:20 1994 *************** *** 37,42 **** #endif - SOCKSinit(argv[0]); - (void) client_options(argc, argv,"",NULL); --- 37,40 ---- ========== -- Skip (montanaro@crd.ge.com) ------------------------------ From: martin@erde.GUN.de (Martin Seine) Subject: Re: Pb writing scsi DPT driver Date: Mon, 28 Feb 1994 02:27:05 GMT cyril (sean@email.teaser.com) wrote in msg : > I am writing a driver for linux for the dpt board but i have a pb Sorry, I can't help you, 'cause I have no info about the DPT-Board but it would be nice if you could send me the driver, if ready... :-))) ciao Martin -- ===================================================================== Martin Seine martin@erde.gun.de Martin.Seine@FernUni-Hagen.de Beam me up, Scotty ! ------------------------------ Crossposted-To: comp.os.linux.help From: boutell@netcom.com (Thomas Boutell) Subject: Re: Linux and X WordPerfect Date: Mon, 28 Feb 1994 04:59:24 GMT In article , Arthur D. Jerijian wrote: > Does Linux support the X WordPerfect package? > No, but thanks for asking the question properly. What I mean by this is that you've got the order right! Linux will be able to run WordPerfect and just about every other major commercial package not written by Microsoft as soon as compatibility with the binary standards of other 80x86 Unixes is achieved. Since this is obviously less effort than porting and maintaing every single application under the sun in a unique Linux version, I encourage those who want to know why commercial product XYZ isn't available for Linux to instead ask why Linux doesn't yet fully support COFF, ELF, IBCS, etc. (There's work being done in this area, but I'd like to hear more from those doing it and I'd like to hear how I might be of help. This is a very important area for Linux.) Followups directed to comp.os.linux.development in hopes of opening further discussion on the subject among the kernelmongers. -T -- boutell@netcom.com, purveyor of fine HTML pages to the biology trade. Click here ------------------------------ From: archie@cory.EECS.Berkeley.EDU (Archie Cobbs) Subject: ISDN card comments wanted Date: 28 Feb 94 05:59:25 GMT A company I've worked for is interested in the possibility of developing an ISDN card for the PC... I suggested that writing a simple (?) device driver for Linux would be the quickest/easiset way to test and play with it :-) Since it's still just an idea, the hardware folks were wondering if people out there more experienced than me with the interplay between hardware and device drivers had any specific suggestions about how the hardware could be designed to make things easier, especially in the context of an O/S like Linux. For example, how important is DMA (for something that runs at maximum 144Kbits/sec), what about interrupt configuration, etc. I'm not real familiar with the inner workings of the ISA bus myself. What do you think? Here's your chance to make a difference. :-) -Archie ------------------------------ From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: Linux and X WordPerfect Date: Mon, 28 Feb 1994 06:36:08 GMT In article , Arthur D. Jerijian wrote: > Does Linux support the X WordPerfect package? I suppose a status report is in order here. I was meaning to post one this weekend, and this thread is a good enough place as any. The iBCS2 code is currently pre-ALPHA, and all of the development code is stored in private directories. The effort is coming along quite nicely, thank you, and it is used to run SVr3, SCO and SVr4 binaries. Obviously there are some differences, but these are being addressed. The COFF and ELF binary loaders are essentially done, and it is only the iBCS2 portion of the kernel code that still needs work. Anyway the big news is that quite recently someone reported that they indeed are able to run an SCO version of WordPerfect under Linux, and yes it *does* run under X11 as well as in a regular VC. I have not seen this with my own eyes, so I do not know how well this actually works or how usable it is, but this should give an indication of how far we have come along. Also, the iBCS2 module can now be used as a loadable kernel module. The COFF and ELF loaders can be loaded as part of this module, and no longer need to be part of the regular kernel. This can reduce the development time quite considerably. There is a iBCS2 compatible version of libc under development that will be usable for both SCO and SVr4 binaries (you have to compile it separately for each of these two cases, of course). My own interests are in being able to run SVr4 binaries under linux. Currently I can get Emacs compiled for SVr4 to come up under linux (non-X only right now), but it only has a limited usability right now. You can modify and save files, however. While it may sound silly to get Emacs working, it makes a good test case because it is free, comes with source code, and because it stresses the system in quite a number of different ways. >(There's work being done in this area, but I'd like to >hear more from those doing it and I'd like to hear >how I might be of help. This is a very important >area for Linux.) Simple. Join the iBCS2 channel. This is where all of the activity is taking place. Once you join you can get the development code and join in. One area that needs a lot of work right now is simply in testing the iBCS2 code with various test programs to verify that everything is being handled correctly. -Eric -- "The woods are lovely, dark and deep. But I have promises to keep, And lines to code before I sleep, And lines to code before I sleep." ------------------------------ Crossposted-To: gnu.misc.discuss From: robertl@arnet.com (Robert Lipe) Subject: Re: Specialix driver Date: Mon, 28 Feb 1994 02:36:15 GMT Re: Specialix drivers. Preface: I'm not a LINUX user. Yet. I've been watching the growth, and am amazed at the contributions. Many times in this discussion, I'll use the term "we" to mean the ports board industry. I'm, of course, not in a position to speak for anyone else, but knowing the internal position of at least 3 companies on this (Arnet, my employer, Digiboard, and Stargate) I have to imagine this is a popular view. Similarly, I'm in no "official" capacity at Arnet - I'm merely head code-layer. Most of the ports-board companies have several UNIX dudes laying around that have extensive experience with their own products plus kernel internals of many UNIXes. Even if it was not a company sponsored event, drivers could and would get done, if only so we didn't have to put a competitors products in our machines at home. :-) IMHO: The reason none of us supports LINUX, BSD-386, 386-BSD, NET/2, is summarized by the preceding 100 messages. We have proprietary card executables that have taken mongo R&D $$$ to develop. As proprietary as these executables is the interface as to how a programmer talks to them. Given the potential legal problems outlined above (I think there were 75 different interpretations in those 100 messages), most of us are willing to "just say no" and focus in a market w/o these hassles. Life is different for us than for say, DPT. I'm sure they wouldn't want Adaptec to really know how their caching schemes work, as that's what really differentiates their product. They are able to "hide" that information from the device drivers by looking like another product. We can't do that. You really wouldn't us to look like a COM1 port if we could. The realities of object-only driver support make it pretty grim when the user has source. "I just changed struct tty, revalued the ioctls in , etc. Your driver stopped working." So that's not a great solution either. Please don't take this as soapbox ranting, I'm just quietly pointing out a few reasons at least some of the ports board companies have chosen to remain silent on the freeware UNIXes. On those products where there _is_ a publicly available interface definition, we have been known to provide manuals and even assistance to those people doing driver development. Help me out - I'm a believer in FSF and similar efforts, I just don't see how it works for us. If we could get a clear, official legal position on this, I think it would only help users of free software. How about it - any other ports-board people have comments? ---- Robert Lipe, Sr. Software Engr, Arnet Corp. robertl@arnet.com ------------------------------ From: julian@uhunix.uhcc.hawaii.edu (J. Cowley) Subject: Re: RF Info on pty handling Date: Mon, 28 Feb 1994 07:32:43 GMT In article , Garrett D'Amore wrote: >I am trying to find information about the correct programming of pty's. >Essentially, what I want to do is have a program that runs a shell, but >examines all the data coming to or from the shell for a couple of escape >sequences, and redirects data to "lpr" between certain escape codes. >The program will be used as a layer of the linux (or other OS) console >to allow it to work with my vtprint program. It's easy once you get the hang of it. Let me see if I can explain it. A pseudo-tty has two parts: the master pty and the slave pty. The usual pathname for a master pty on a Linux system is /dev/ptyXY, where X is a p, q, r, or s, and Y is a lowercase hexadecimal digit. The pathnames for the slave ptys, /dev/ttyXY, correspond one-to-one in the same manner. When the corresponding master and slave pty's (such as /dev/ptyp0 and /dev/ttyp0) are open, characters that are written to the slave using write() can be read() from the master. Vice versa, characters that are written to the master end up on the slave. While this may sound like a FIFO, it is not: the slave pty keeps termios settings. This is important. All characters written to either the slave or the master are processed according to the termios settings before they are read by the other end. A slave pty can also be a controlling terminal, so that a shell can set its foreground process group. Special characters such as ^C or ^Z cause the appropriate signals to be sent to processes that have the slave pty as the controlling terminal. A knowledge of job control may help here. >I'd like the shell to be unaware that it's not being run from a "true" >tty -- e.g. the isatty() call in the shell should return true. So, a >simple filter is unacceptable. A pseudo-tty is a true tty -- don't let the word "pseudo" throw you, since it is a misnomer. The only difference from other ttys is that instead of a piece of hardware such as a serial port or a console/keyboard, the "other end" is a process that has the master pty open. I've included at the end of this article a program that I use to debug the kernel code for "packet mode". It opens up a shell and allows a user to use the shell through the pty. It may help you in what you want to do. Packet mode is a special setting that only applies to pseudo-ttys, but I won't go into details here. Suffice to say that the first byte of the read buffer on the master side is a status byte, and it is usually 0, indicating that the rest of the buffer is data. I should also mention what read() returns when when either the slave or master pty is closed for the last time. When a slave is closed (such as when the user types "exit" to the shell), the master is notified by an EIO error. When a master is closed, the slave gets a read count of 0 (EOF) and a SIGHUP is sent to the shell. This is the same thing that happens when a serial port's DTR goes low, indicating a hangup. Well, hopefully this will be enough to get you going. I don't know of any books to recommend, but perhaps having the source code for a program that does something similar to what you want will help. -=- julian ============================== cut here ============================== /* Open a pty pair and start up a shell. Used to debug packet mode. Written by Julian Cowley, 5Jan94. */ #include #include #include #include #include #include #include char * pty_name(unsigned int i) { static char buf[3]; if (i < 64) { sprintf(buf, "%c%x", 'p' + (i / 16), i % 16); return buf; } else return NULL; } void main(void) { int pty_fd, tty_fd, i, m, n; fd_set readfds, orig_readfds; unsigned char buf[1024], c, *p; struct termios old_tios, tios; int read_cnt = 0, byte_cnt = 0; for (i = 0; i < 64; i++) { sprintf(buf, "/dev/pty%s", pty_name(i)); pty_fd = open(buf, O_RDWR); if (pty_fd < 0) continue; sprintf(buf, "/dev/tty%s", pty_name(i)); tty_fd = open(buf, O_RDWR); if (tty_fd < 0) { close(pty_fd); continue; } break; } if (i == 64) { printf("No ptys available.\n"); exit(1); } printf("Using %s.\n", buf); n = fork(); if (n < 0) { perror("fork"); exit(1); } if (!n) { /* child */ close(pty_fd); /* Set up the slave pty as a controlling terminal. */ setsid(); if (ioctl(tty_fd, TIOCSCTTY, 0) < 0) { perror("ioctl TIOCSCTTY"); exit(1); } /* Create stdin, stdout, and stderr. */ dup2(tty_fd, 0); dup2(tty_fd, 1); dup2(tty_fd, 2); if (tty_fd > 2) close(tty_fd); /* Now pass the file descriptors to the shell. */ execl("/bin/sh", "sh", NULL); exit(1); } /* parent */ close(tty_fd); tcgetattr(0, &old_tios); tios.c_iflag = tios.c_oflag = tios.c_cflag = tios.c_lflag = 0; tcsetattr(0, TCSANOW, &tios); if (ioctl(pty_fd, TIOCPKT, 1) < 0) { perror("ioctl TIOCPKT"); exit(1); } FD_ZERO(&orig_readfds); FD_SET(0, &orig_readfds); FD_SET(pty_fd, &orig_readfds); while (1) { readfds = orig_readfds; if (select(32, &readfds, (fd_set *) 0, (fd_set *) 0, (struct timeval *) 0) < 0) { perror("select"); break; } if (FD_ISSET(0, &readfds)) { n = read(0, buf, sizeof buf); if (n < 0) { perror("read 0"); break; } p = buf; while (n > 0) { m = write(pty_fd, p, n); if (m < 0) { perror("write pty_fd"); break; } p += m; n -= m; } } if (FD_ISSET(pty_fd, &readfds)) { read_cnt++; n = read(pty_fd, buf, sizeof buf); if (!n) break; if (n < 0) { if (errno != EIO) perror("read pty_fd"); break; } c = buf[0]; if (c) { printf("packetmode:"); if (c & TIOCPKT_FLUSHREAD) printf(" FLUSHREAD"); if (c & TIOCPKT_FLUSHWRITE) printf(" FLUSHWRITE"); if (c & TIOCPKT_STOP) printf(" STOP"); if (c & TIOCPKT_START) printf(" START"); if (c & TIOCPKT_NOSTOP) printf(" NOSTOP"); if (c & TIOCPKT_DOSTOP) printf(" DOSTOP"); printf("..."); fflush(stdout); } p = &buf[1]; n--; byte_cnt += n; while (n > 0) { m = write(1, p, n); if (m < 0) { perror("write 1"); break; } p += m; n -= m; } } } if (tcsetattr(0, TCSANOW, &old_tios) < 0) perror("tcsetattr oldtios"); printf("read_cnt = %d byte_cnt = %d avg = %f\n", read_cnt, byte_cnt, (double) byte_cnt / read_cnt); exit(0); } ------------------------------ ** 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 ******************************