From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <1309194435.17968.YahooMailClassic@web30908.mail.mud.yahoo.com> Date: Mon, 27 Jun 2011 10:07:15 -0700 From: rbnsw-plan9@yahoo.com.au To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>, David Lukes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] RFS alternatives (Was: Living with Plan 9) Topicbox-Message-UUID: f6f80d7e-ead6-11e9-9d60-3106f5b1d025 --- On Wed, 22/6/11, David Lukes wrote: >... > I'm no RFS guru, thank deity, but I did RTFC once and "F" > was apposite. It took me a little time to figure out RTFC wasn't a remote file system ;-) >=20 > ioctl was handled by having the client "know" exactly what > each ioctl "looked like", i.e. it only worked for known > cases. ... Thanks for pointing out the folly in my thinking. I was hoping for a user/a= dministrators view of RFS but the under the hood perspective is welcome. I'= d forgotten that the variable(!) trailing parameters of the ioctl are opaqu= e at the system call level, i.e. their layouts are only known to the applic= ation program and device drivers. So the best that can be done in a generic manner is to send ioctls only bet= ween systems with identical binary representations (possibly remapping majo= r/minor device numbers). Maybe if RFS had been more successful over NFS, (or Linus knew more about P= lan 9) the Unix interface would have been fixed by now. I wonder if there i= s any level of acceptance amongst *nix kernel developers that this is a pro= blem. I can think of schemes to fix this without having to modify every pro= gram that issues an ioctl - though that would be a good idea in the long ru= n - /merely/ having to modify every device driver implementing ioctls to as= sist in the remote translation. While it might seem unfeasible to modify ev= ery device driver in this class to support this behaviour, the kernel inter= faces change frequently so perhaps this might indeed be possible. Speaking of device numbers, I was surprised that Plan 9 has a similar notio= n. 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 de= vice/file server it belongs to? In most cases, a name is good enough, but sometimes its not. And speaking of opaqueness, while Plan 9 might use portable data representa= tion, some interfaces are perhaps unnecessarily opaque in a different way. = Consider the uart ctl file with its encoded string of device attributes. If= each attribute used a separate file, with meaningful names, the parameters= of the interface, although unfortunately not their range of values, would = be available. Given that it is not, some other form of automated descriptio= n is desirable, ideally accessible from the file system itself rather than = requiring use of a library. While we have learned (been forced) to live wit= h files that are bags of bytes, I think it would be better not to repeat th= is with interfaces too. 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 th= ere's no doubt where the control interface of a device is. Andrew