lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory mail-archive

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:25:02 -05:00
parent 07129c3397
commit a778c607a4
1056 changed files with 796887 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

829
mail-archive/linux-devel/Volume1/digest5XX/digest507 Normal file
View File

@@ -0,0 +1,829 @@
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: 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 <i0a90.n1.t1a9bb757@email.teaser.com>:
> 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 <CLsnCq.BIr@seas.ucla.edu>,
Arthur D. Jerijian <jerijian@hurricane.seas.ucla.edu> 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.
<a href="http://siva.cshl.org/boutell.html">Click <em>here</em></A>
------------------------------
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 <CLsnCq.BIr@seas.ucla.edu>,
Arthur D. Jerijian <jerijian@hurricane.seas.ucla.edu> 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 <sys/termio.h>, 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 <garrettCLuDvD.GJ@netcom.com>, Garrett D'Amore <garrett@netcom.com>
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 <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/time.h>
#include <sys/ioctl.h>
#include <errno.h>
#include <termios.h>
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
******************************