From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Mon, 27 Jun 2011 13:24:00 -0400 To: rbnsw-plan9@yahoo.com.au, 9fans@9fans.net Message-ID: In-Reply-To: <1309194435.17968.YahooMailClassic@web30908.mail.mud.yahoo.com> References: <1309194435.17968.YahooMailClassic@web30908.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] RFS alternatives (Was: Living with Plan 9) Topicbox-Message-UUID: f7152792-ead6-11e9-9d60-3106f5b1d025 > 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. > And speaking of opaqueness, while Plan 9 might use portable data > representation, 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 manipuation of serial devices could you imagine would be useful? > 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' - erik