Bug#129550: [PATCH] Proposed rewording of umount() info doc

[GOTO Masanori <gotom@debian.or.jp>]

At Tue, 31 Dec 2002 09:10:56 -0500,
H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> On Mon, Dec 30, 2002 at 12:16:40PM +0900, GOTO Masanori wrote:
> > At Fri, 27 Dec 2002 12:10:19 -0500,
> > H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> [snip]
> > BTW, from manpages umount(2):
> > 
> > HISTORY
> >        The  original  umount  function  was called as umount(device) and would
> >        return ENOTBLK when called with something other than  a  block  device.
> >        In  Linux  0.98p4  a  call  umount(dir)  was added, in order to support
> >        anonymous devices.  In Linux 2.3.99-pre7 the  call  umount(device)  was
> >        removed,  leaving only umount(dir) (since now devices can be mounted in
> >        more than one place, so specifying the device does not suffice).
> > 
> > So... this description is true after 2.4 iff its kernel is linux, if
> > this manpage is correct.  I think this description depends on your
> > kernel.  It's kernel issue, not glibc issue.  I wonder this bug has
> > the right point.
> [snip]
> 
> Hmm. In this case, maybe the right thing to do would be to add a note to
> the documentation stating that on some kernels, namely, Linux 2.4.x (or
> more precisely, 2.3.99-pre7 and up), umount() requires its argument to be
> the mount point.

Actually, glibc works not only on linux but also bsd/hurd/... and so
on.  Glibc info is written in non system specific style.  Glibc works
perfect - but kernel system call is rejected.  If we wrote each
architecture related issue, info needs more pages.

I don't know whether glibc maintainers think this description is
needed for umount() or not... It's only my opinion.  However, you can
grep libc info, and you find such system specific issue is not
addressed in this info.

From user's point of view, it's easy to find umount() behavior on
linux for convenience.  But umount() is system specific call, it's not
standardized, and exactly manpage says umount() changes.  Closing this
bug without your patch (sorry!) is more appropriate from maintainer's
point of view...  Do you think about it?

Regards,
-- gotom