Re: Bug#669647: ITP: hurd-cvsfs -- CVS virtual filesystem for the GNU Hurd
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
Reply to: