Hmm, maybe it was somewhere else I wrote it then.
> Writing to /proc/mtab like we do /etc/mtab means allowing
> full file read,write,truncate,seek functionality on a
> multi-page tlob just to emulate current behavior and support
> a second data source with a disconnect from the kernel.
I certainly don't want that. I'd much rather see something
slightly similar to files in /proc/sys/. I only want the
write system call to work, and I don't want the write call
to make use of any file offset. (Maybe it would require a
buffer for cases where a write does not end with a newline,
but that is just a minor detail.) Every full line written
to /proc/mtab would then be parsed (as simple as finding
the spaces and verify that there are exactly five). The
relevant fields in the mountpoint listed in field two will
then be updated.
> > >
> > > mount(8) and umount(8) are the only almost the only things that
> > > write mtab all others are readers.
> > What are you saying? Are they the only writers, or are there
> > other writers? IIRC smbmount will write /etc/mtab on its own.
> Hence the qualifier. My point is that the list of things
> that call mount(2) directly and write to /etc/mtab is small
> and the most critical of them are linux specific. This
> gives us a degree of freedom in our approach.
We agree on that.
> What i would lean towards, assuming that data couldn't list
> all options not supported by mountflags would be to add a
> char *userdata or useropts argument. That would be attached
> to struct vfsmount. Userdata would be what /proc/mtab or
> whatever reported, either as the option list or the whole
> To detect the old interface users a NULL userdata or (as
> alternatives) a missing MS_USERDATA flag or calling the old
> mount syscall would cause a warning that identifies the
> offending process. For the short term either construct a
> fake userdata or mtab could fallback to what /proc/mounts
> does when it hits NULL. Long term might be to fail mount(2)
> on such an error.
That is another possible solution. And as I think a litle
more about it, that is probably a better than the solution I
There are a few details of the API that needs to be defined
before it can be implemented. So I hope people will say how
they like it. As I see it there are a few different
1) Make a new mount system call. Finally get rid of the old
magic value in the flag register and add the extra argument
which is then required. Make the old mount system call
obsolete, but keep it for some versions. The old mount
system call should then just behave as if the user data
was the empty string.
2) Add a new flag for the old mount system call, which
indicates that there is one more argument containing the
> I think our goals are the same.
> The only reason i chimed in
> on this discussion was to remind people that /etc/mtab was a
> hack we no longer really need and then because it sounded
> like what was being proposed was to emulate that
> obsolescence with another layer of cruft.
I never wanted a /proc/mtab to emulate the existing /etc/mtab.
In fact I wanted it to resemble the existing /proc/mounts as
much as possible, just with a few new features and probably
a different string in the device field in some cases.
-- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:firstname.lastname@example.org for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/