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

[rbnsw-plan9@yahoo.com.au]

--- On Wed, 22/6/11, David Lukes <davelukes@mac.com> 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 ;-)
> 
> 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/administrators view of RFS but the under the hood perspective is welcome. I'd forgotten that the variable(!) trailing parameters of the ioctl are opaque at the system call level, i.e. their layouts are only known to the application program and device drivers.

So the best that can be done in a generic manner is to send ioctls only between systems with identical binary representations (possibly remapping major/minor device numbers).

Maybe if RFS had been more successful over NFS, (or Linus knew more about Plan 9) the Unix interface would have been fixed by now. I wonder if there is any level of acceptance amongst *nix kernel developers that this is a problem. I can think of schemes to fix this without having to modify every program that issues an ioctl - though that would be a good idea in the long run - /merely/ having to modify every device driver implementing ioctls to assist in the remote translation. While it might seem unfeasible to modify every device driver in this class to support this behaviour, the kernel interfaces change frequently so perhaps this might indeed be possible.

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.

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. 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 description is desirable, ideally accessible from the file system itself rather than requiring use of a library. While we have learned (been forced) to live with files that are bags of bytes, I think it would be better not to repeat this 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 there's no doubt where the control interface of a device is.

Andrew