--- On Tue, 28/6/11, erik quanstrom <quans...@quanstro.net> wrote:
>> Speaking of device numbers, I was surprised that Plan 9 has a similar
>> notion. However, they are only useful with kernel resident device
>> numbers. Does Plan 9 have some other mechanism that allow one to
>> identify the class of device/file server it belongs to?
>>
>> In most cases, a name is good enough, but sometimes its not.
>
> no. most stereotypical drivers are written in the
> miniport style. (please excuse the reference.) where one
> bag of generic code provides the interface, so one interacts with all
> ethernet, serial or storage devices in the same way.
Ok, then I misunderstand what the stat man page means by "Type identifies the
server type, and dev says which of a group of servers of the same type is the
one responsible for this file" Code that relies on testing the server type is
bad style anyway, its better if the server can supply a bunch of predicates so
a client can test what operations a server supporta, a client should not
mistake one type of device for another one. After all, an ethernet doesn't
provide the same level of persistence a storage device does!
>
>> And speaking of opaqueness, while Plan 9 might use portable data
>> representations, some interfaces are perhaps unnecessarily opaque in a
>> different way. Consider the uart ctl file with its encoded string of
>> device attributes.
>
> what kind of abstract manipulation of serial devices could
> you imagine would be useful?
I wasn't motivated about manipulating serial devices per se, I was thinking
about reflective interfaces and programs that use metadata to learn about the
behaviour of interfaces and provide user friendly UIs.
Having separate files for each attributes makes that a little easier. A
separate hierarchy mirroring that of the ctl directory might return the
allowable values/syntax for attributes/operations.
Serial devices are not that interesting for abstract manipulation but for the
sake of the argument: we can classify the comms devices into virtual circuit
based and datagram based. The VC based into permanent and switched VC (PVC and
SVC). And we can classify VCs into byte oriented (stream) and record oriented.
We probably should have QOS attributes too, A serial line can be considered a
byte oriented PVC with indeterminate or perhaps configurable QOS. If we include
serial lines as a type of PVC, we better know if PVCs are 8 bit clean -
alternatively perhaps only 8 bit clean devices can be PVCs. There's nothing
here about manipulation really, PVCs don't have much scope for that, but stay
tuned, so far this is more about attributes that allow clients to select the
comms medium they're interested in. Speaking of which, some optional attributes
that make the implicit local and remote addresses/identifier explicit as well
as the implied upper level protocol
are useful too. Most of these are read only attributes too, but some will be
read-write so they can have their values set by administrators.
So what can be manipulated? Flow control is something common to many virtual
circuits including serial lines. Uart allow input and output queue lengths to
be set which I assume affect flow control/blocking. TCP has windows which
provide the same affect, *nixes allows them to be indirectly controlled by
setting the send and receive buffer sizes via setsockopt or configured system
wide, but Plan 9 doesn't seem to offer this facility.
However, if one adds a modem to a serial line or the end of any PVC for that
matter we can treat it like a SVC, in much the same way we treat TCP. Apart
from QOS the only real difference is that the number of SVCs has a much lower
limit than TCP.
>
>> Oh, and it would be better if the uart device was consistent with the
>> files in net with their separate data and ctl files, if one is going
>> to rely on conventions they should be consistent. Despite the other
>> faults of ioctl there's no doubt where the control interface of a
>> device is.
>
> but it does. there's eia0status, eia0ctl and eia0 (the data file).
> ; ls '#t'
> '#t/eia0'
> '#t/eia0ctl'
> '#t/eia0status'
> '#t/eia1'
> '#t/eia1ctl'
> '#t/eia1status'
>
Sorry, I meant structured like the files in net. So, the uart could instead by
structured as:
eia/
0/
ctl
data
status
1/
ctl
data
status
there could also be clone entry directly under eia if we wished to have an
allocation scheme if the various serial lines are equivalent, e.g. attached to
modems and of course a stats interface too.
Regards,
Andrew
> - erik
>
