Subject: DeskWriter daemon - suggestions?
To: None <macbsd-development@NetBSD.ORG>
From: Bill Studenmund <wrstuden@loki.Stanford.EDU>
List: macbsd-development
Date: 07/02/1995 15:30:58
I have some questions from the DeskWriter driver studies I've asked the
-general list about.
1) How robust is support for the serial port? The DeskWriter runs at
57600 bps, hardware handshaking. Any gotcha's other than setting
/etc/ttys for 57600 rtscts handshaking? Oh, and no getty.
2) The printer sends a status byte every other second describing its
state-of-affairs (idle, busy, etc). I'm thinking that it would be
nice to have a process capture them and translate them into a
readable status. So I (eventually) need to write a daemon. What are
good references?
3) I want to do all this efficiently. Graphics files might be tens or
hundreds of k long. All files will (until I learn more about
font support) be graphics, except bare text. Also, this daemon
will need to come alive once every other second to monitor status.
I have ideas, but I'm not sure what's best.
Idea A: Have the daemon sit around & people/processies feed it files
which it then spits out the serial port. It would also look at
the input status bytes, and either write a status file or be
ready for other processes to link to it to get the status.
Problems: A disk I/O every other second for data that doesn't need to be
on disk seems wasteful. Actually, with the procfs, how hard is it
to teach one program to look in another process to see a string in
another? So anything which is interested need only look at the
daemon's innards. How do you (I) do this?
Other problem: It seems wasteful for the daemon to have to pass all
the data out to the printer. Is it possible for two or more processes
to have access to a tty? Specifically I want the daemon to be
the one to get the status bytes, but it and anyone else can write
to the tty. I've never heard of exclusive-read, promiscuous-write
access before.
I realize this is a bit long-winded, but I'd appreciate any input. It will
probably be a while before the daemon appears, but I might have the
driver problem solved soon (a beta version later this week maybe).
Thanks!
Bill