In message <[EMAIL PROTECTED]>, Alexander Viro
writes:
>
>
> On Fri, 16 Jun 2000, Erez Zadok wrote:
>
> > On a related note, since we do have /proc/mounts, and assuming that procfs
> > is pretty much necessary nowadays, are we going to get rid of /etc/mtab and
> > completely move all getmntent info into the kernel? I never liked the fact
> > that people doing mounts (such as automounters) have to ensure that they
> > correctly maintain a separate text file in /etc.
>
> I'm not sure that we need to keep it on procfs - especially with the
> union-mounts coming into the game.
Procfs or not, I'm advocating for keeping it in the kernel only, where it
belongs, and removing the kludgy need (ala Sun and many others) to maintain
a separate /etc/mtab file.
> > Hmmm, maybe that's a question to the glibc folks. I guess as long as all
> > the necessary tools and libraries will use /proc/mounts if available, and
> > avoid using /etc/mtab, that'd be ok.
>
> How many programs actually need this getmntent(), in the first
> place?
Programs like df(1) need to read mtab. Automounters (such as amd, which I
maintain) and /bin/mount need to write it. The problem with a separate mtab
file is that there's no way to guarantee that the file in /etc is in sync w/
the actual mounts in the kernel. There are many reasons why you can get an
mtab file that's out of sync w/ the actual in-kernel mounts. AIX, Ultrix,
and BSD44 did the right thing by moving this mtab list into the kernel, and
rewriting "[gs]etmntent" (they also renamed them) so they query the kernel
via a syscall. Solaris 8 move that way too, but kept backwards
compatibility using their special mntfs.
Anyway, I'd like to see a new syscall that returns a list of mounts and
associated info in linux. Currently that can be done by reading
/proc/mounts, but not if procfs isn't available or we're going to take
/proc/mounts away. It would make programs like df more reliable, and
programs like /bin/mount won't have to rewrite the mtab file each time a
mount(2) is made. And it'll make amd work a little faster (I already
auto-detect in-kernel vs. in-/etc mount tables and handle that in amd).
Anyway it's not a big thing or something that we need to do right now.
Erez.
