On Mon, 2012-04-23 at 11:20 +0200, Samuel Thibault wrote: > Roger Leigh, le Mon 23 Apr 2012 09:44:32 +0100, a écrit : > > While it's great that Hurd can support all of these esoteric > > translators, in terms of making Hurd a viable *Debian* port, > > we really only need a few specific ones: > > > > - tmpfs > > - procfs > > - ext?fs > > They are already there. > > > - sysfs > > Err, I don't think it's a good idea to let people think it is ok to use > extremely-linuxish things there.
I agree with this. Linux sysfs exposes the kernel's object model (mostly devices). It's not reasonable to expect another kernel to simulate the Linux object model. (VMware tries to do this in ESX/vSphere, but it's not really compatible.) > > Yet we are carrying > > around large amounts of code and extra initscripts to generate > > mtab for the only system which does not support /proc/mounts > > (Hurd). A procfs translator (even an incomplete one) would > > allow all this (barely tested) cruft to be dropped. > > We have an incomplete procfs already. It doesn't have /proc/mounts, > because it's not a trivial thing to implement: since mounts are > distributed, there is no central place where filesystems are to be > recorded. There are plans to somehowe build one. In the meanwhile > things are working already. I don't think spending time on a feature > just to remove some existing code is the best way to spend our time, > either. [...] I would say something *like* /proc/mounts is important for a modern Unix-like system. I'm sure it's not trivial, but it's implementing a standard format (mtab) and not a moving target of 'be like Linux'. In general I would agree it's not reasonable to expect a non-Linux kernel to support much of Linux procfs; even the per-process directories have a lot of Linux-specific scheduler and VM stats. It's a shame procfs has never been standardised. Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison
signature.asc
Description: This is a digitally signed message part