bryce@hoser.berkeley.edu (Bryce Nesbitt) (01/11/88)
This was sent to me via private E-Mail. Since it pertains to our
discussion, I've posted it here. (usenet only... this has not been
posted to BIX)
From bpa!vu-vlsi!devon!stb!michael@RUTGERS.EDU Sat Jan 9 16:59:19 1988
To: bryce@hoser.berkeley.edu
Organization: STB BBS, La, Ca, USA, 90402
Sounds good. BUt it also seems like it would require re-writting most of
serial.device for each device, when the only thing that should need re-writing
is
A) Read one character
B) Write one character
C) Set up the uart.
Consider printers. RIght now the printer driver code only contains device
specific stuff. The brunt of graphic work is done in a common routine
before going to the driver. Something similar to this should be done
for the serial device.
[Note: What's the differneces between the serial.device and parallel.device?
I say the answer is "nothing fundamental" and there should not be two
separate devices. Perhaphs port '0' could be the built-in serial and
port '1' the built-in parallel. -bryce]
Say for example, I make an eithernet board. I have software that supports
multiplexing the single eithernet channel, and I know from tests, etc. that
about 5 or 6 virtual serial lines can run over the eithernet before noticing
serious problems. Ideally I should be able to use the serial.device for
this--users would not have to worry about "does this term program support
either.device" or what not.
But there is no reason that the regular serial line can't be multiplexed.
As long as the standard device will be expanded for multiple units, it
should be possible to replace the character I/O for the standard unit with
something that allows multiplexing the port. Say, for example, something
that speaks the uw protocol. This way you can have 4 or 5 general term
programs, a kermit server or two, (:-), and who knows what else.
[Fine, but the serial.device is a low-level transport interface. It
shoves 'dem bits out the port you want. If several programs want to
gang up and multiplex the port, fine. It is not up to the serial.device
layer.
If you were to add multiplexing to this layer, you'd need to pick a
protocal. Every multiplexer I have ever seen uses something different.
-bryce]
Michael
: --
---
: Michael Gersten ihnp4!hermix!ucla-an!remsit!stb!michael
: sdcrdcf!trwrb!scgvaxd!stb!michael
: "A hacker lives forever, but not so his free time"
|\ /| . Ack! (NAK, SOH, EOT)
{o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (or try "cogsci")
(")
U "Your theory is crazy... but not crazy enought to be true." -Niels Bohrbryce@hoser.berkeley.edu (Bryce Nesbitt) (01/11/88)
In article <> ihnp4!hermix!ucla-an!remsit!stb!michael writes: < < Say for example, I make an eithernet board.... < ...about 5 or 6 virtual serial lines can run over the ethernet... < ....Ideally I should be able to use the serial.device for < this--users would not have to worry about "does this term program support < either.device" or what not. The clean solution is to add "6 or 7" units to the serial.device, then internally route them all to the same hardware port. |\ /| . Ack! (NAK, SOH, EOT) {o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (or try "cogsci") (") U "Your theory is crazy... but not crazy enought to be true." -Niels Bohr
michael@stb.UUCP (Michael) (01/21/88)
In response to my mail, Bryce writes >[Fine, but the serial.device is a low-level transport interface. It >shoves 'dem bits out the port you want. If several programs want to >gang up and multiplex the port, fine. It is not up to the serial.device >layer. >If you were to add multiplexing to this layer, you'd need to pick a >protocal. Every multiplexer I have ever seen uses something different. >-bryce] > The point is this: I want to consider existing uses of "Serial.device" not as a low-level transport, but a medium level transport. A "raw-serial.device" or something similar, would do multiplexing at the amiga end, and another copy of it would do the demuxing on the other end. The point is: When a program opens "Serial.device", they are essentially getting a one dimensional array of unknown, indefinite length that they can stick stuff into provided they never stuff out of order or backtrack. Whether that is a 1-1 correspondence with what goes out the port or not doesn't matter, as long as its whats read in on the other end. Michael -- : Michael Gersten ihnp4!hermix!ucla-an!remsit!stb!michael : uunet!scgvaxd!stb!michael : "A hacker lives forever, but not so his free time"