Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bionet!ig!ames!lll-winken!uunet!etnibsd!vsh
From: vsh@etnibsd.UUCP (Steve Harris)
Newsgroups: comp.unix.wizards
Subject: Re: What kinds of things would you want in the GNU OS?
Message-ID: <1050@etnibsd.UUCP>
Date: 6 Jul 89 22:55:52 GMT
References: <20037@adm.BRL.MIL> <205@marvin.moncam.co.uk> <1035@riddle.UUCP> <8906272337.AA24210@cscwam.UMD.EDU> <214@tnl.UUCP> <1549@salgado.Solbourne.COM>
Reply-To: vsh@etnibsd.UUCP (Steve Harris)
Organization: Eaton Ion Beam Systems Div., Beverly, MA
Lines: 22

In article <1549@salgado.Solbourne.COM> dworkin@Solbourne.com (Dieter Muller) writes:
>I'd *really* like a sane tty driver.

Hear hear!!  At a former job we talked a lot about how we would rewrite
the tty driver.  One idea was to give the user, via ioctl's, access to
the uart (or whatever serial-line multiplexer you have).  One ioctl to
get the uart settings (in a bit vector), another to set them, and
another to have the driver(??) send you a signal (for which you would
have to write the appropriate handler) whenever any of the bits changed
(e.g., DTR was deasserted).  Standard configurations (handlers) would
be privided in a library.  Of course, one would be limited by the
capabilities of the uart, but the design would assume total access to
be possible.

A second idea is "copy-on-write symbolic links" -- I have a symlink:
	bar -> foo
When I write to it, a regular file "bar" is created (the symlink is
destroyed), the contents of foo (up to the current file-pointer-offset)
are copied to bar, and the write takes place.  I'm not sure what
happens if foo is not a regular file.
-- 
Steve Harris -- Eaton Corp. -- Beverly, MA -- uunet!etnibsd!vsh