Re: [9fans] RFS alternatives (Was: Living with Plan 9)

[rbnsw-plan9@yahoo.com.au]

--- On Tue, 28/6/11, erik quanstrom <quanstro@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
>