From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <1309453875.306.YahooMailClassic@web30906.mail.mud.yahoo.com> Date: Thu, 30 Jun 2011 10:11:15 -0700 From: rbnsw-plan9@yahoo.com.au To: 9fans@9fans.net, erik quanstrom In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] RFS alternatives (Was: Living with Plan 9) Topicbox-Message-UUID: f8b6948c-ead6-11e9-9d60-3106f5b1d025 --- On Tue, 28/6/11, erik quanstrom wrote: >> Speaking of device numbers, I was surprised that Plan 9 has a similar >> notion.=A0 However, they are only useful with kernel resident device >> numbers.=A0 Does Plan 9 have some other mechanism that allow one to >> identify the class of device/file server it belongs to? >>=20 >> In most cases, a name is good enough, but sometimes its not. >=20 > no.=A0 most stereotypical drivers are written in the > miniport style.=A0 (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 t= he 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 serv= er 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 clien= t should not mistake one type of device for another one. After all, an ethe= rnet doesn't provide the same level of persistence a storage device does! >=20 >> And speaking of opaqueness, while Plan 9 might use portable data >> representations, some interfaces are perhaps unnecessarily opaque in a >> different way.=A0 Consider the uart ctl file with its encoded string of >> device attributes. >=20 > 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 sep= arate hierarchy mirroring that of the ctl directory might return the allowa= ble values/syntax for attributes/operations. Serial devices are not that interesting for abstract manipulation but for t= he sake of the argument: we can classify the comms devices into virtual cir= cuit 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 reco= rd oriented. We probably should have QOS attributes too, A serial line can = be considered a byte oriented PVC with indeterminate or perhaps configurabl= e 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 PVC= s. There's nothing here about manipulation really, PVCs don't have much sco= pe for that, but stay tuned, so far this is more about attributes that allo= w clients to select the comms medium they're interested in. Speaking of whi= ch, some optional attributes that make the implicit local and remote addres= ses/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 virtua= l circuits including serial lines. Uart allow input and output queue length= s to be set which I assume affect flow control/blocking. TCP has windows wh= ich 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 tha= t matter we can treat it like a SVC, in much the same way we treat TCP. Apa= rt from QOS the only real difference is that the number of SVCs has a much = lower limit than TCP. >=20 >> 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.=A0 Despite the other >> faults of ioctl there's no doubt where the control interface of a >> device is. >=20 > but it does.=A0 there's eia0status, eia0ctl and eia0 (the data file). > ; ls '#t' > '#t/eia0' > '#t/eia0ctl' > '#t/eia0status' > '#t/eia1' > '#t/eia1ctl' > '#t/eia1status' >=20 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 >