830 lines
29 KiB
Plaintext
830 lines
29 KiB
Plaintext
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
|
|
******************************
|