Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!cornell!uw-beaver!tektronix!orca!tekecs!frip!andrew
From: andrew@frip.gwd.tek.com (Andrew Klossner)
Newsgroups: comp.unix.wizards
Subject: Re: Unix kernel calling the kernel
Message-ID: <10559@tekecs.TEK.COM>
Date: 2 Nov 88 22:07:35 GMT
References: <17200@shemp.CS.UCLA.EDU>
Sender: andrew@tekecs.TEK.COM
Organization: Tektronix, Wilsonville, Oregon
Lines: 29

[]

	"Specifically, I am planning to write a device driver for a
	block device that would read the data from a tty device
	(Actually a pseudo tty who's other end is another device driver
	...)"

I've done something like this, as part of a mechanism by which kernel
messages and /dev/console traffic are routed to an X window
if-and-only-if X is up.  You open the routine by calling ptsopen; you
write by calling ptswrite; and you close by calling ptsclose.  There
are several pitfalls:

1) Under some varieties of Unix, the device driver expects the entire
device number, not just the minor number.  You have no easy way of
finding out what the major number is.  I hacked our pty driver not to
care about the major number.

2) If you call ptsclose for a pseudo-terminal that's still open, the
close routine will shut down the pty and the "legitimate" processes
that have it open will have trouble.  On the other hand, if you don't
call ptsclose and nobody had it open, it won't get shut down.  You
either have to interact with the inode locking mechanism, or you need
alternate "open" and "close" entry points into the pty driver.

3) After call call to ptswrite, you need to unschedule yourself so that
the other end of the pseudo-terminal can digest what you've fed it.

  -=- Andrew Klossner   (uunet!tektronix!tekecs!frip!andrew)    [UUCP]
                        (andrew%frip.gwd.tek.com@relay.cs.net)  [ARPA]