On Mon, Apr 23, 2012 at 03:47:18PM +0100, Ben Hutchings wrote: > 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 : > > > 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.
Just to touch back on this topic. I would definitely like to remove the initscripts support for mtab generation for jessie. It's not used on linux or kfreebsd any longer, which makes hurd the sole user. While I already did the work to make mtab generation work, the reality is that it's going to bitrot if no one is actually using it seriously, and a dynamic mtab is needed by hurd in any case. The logic is a horrible hack in any case, requiring earlier initscripts to be re-run with special arguments to run in mtab-generating mode, and that's an improvement on the previous implementation, which required reimplementing the logic from all scripts doing mounting twice, inconsistently... To come back to the point about it being difficult on Hurd due to there being "no central place where filesystems are to be recorded", this is a very obvious reason why a static /etc/mtab is very bad: it doesn't necessarily reflect the reality that different processes have a different set of mounts. It's just as buggy as a static mtab on Linux with different mount namespaces. So having hurd provide a dynamic mtab would be greatly desirable for several reasons; it doesn't need to use /proc/mounts; it just needs /etc/mtab to contain dynamic content by whatever mechanism is deemed appropriate. It would also be helpful to know to what extent hurd supports booting with sysvinit/initscripts in wheezy, and what (if anything) will be changing in jessie, since knowing exactly what support hurd needs from sysvinit/initscripts will affect any changes which we might want to make. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
