mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dominik Kubla <dominik@kubla.de>
To: Horst von Brand <vonbrand@inf.utfsm.cl>
Cc: Kasper Dupont <kasperd@daimi.au.dk>, Miles Bader <miles@gnu.org>,
	DervishD <raul@pleyades.net>,
	Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: About /etc/mtab and /proc/mounts
Date: Thu, 27 Feb 2003 17:40:03 +0100	[thread overview]
Message-ID: <200302271740.06139.dominik@kubla.de> (raw)
In-Reply-To: <200302271600.h1RG0Cdh011948@eeyore.valparaiso.cl>

On Thursday 27 February 2003 17:00, Horst von Brand wrote:
> Dominik Kubla <dominik@kubla.de> said:
> > Quoting the Solaris 8 man page:
>
> I fail to see any significant difference to /proc/mounts (possibly
> expanded). Sure, /proc is the wrong place for this kind of stuff, but...

Then i suggest that you re-read the mnttab(4) man page and compare
it to the Linux implementation.  :-)

Keep in mind that i only qouted some parts of the man page. Some thing
are just details (but as we all know details do matter):

[Linux]
# ls -l /proc mounts
lrwxrwxrwx    1 root     root           11 Feb 27 17:10 /proc/mounts -> 
self/mounts
# ls -l /proc/self/mounts
-r--r--r--    1 root     root            0 Feb 27 17:11 /proc/self/mounts
# wc -c /proc/self/mounts
   1058 /proc/self/mounts

[Solaris]
# ls -l /etc/mnttab
 r--r--r--   1 root         1178 Feb 25 16:26 /etc/mnttab
# wc -c /etc/mnttab
    1178 /etc/mnttab

The snapshot feature as quoted in the man page is not present under
Linux.  The poll(2) feature is not implemented. The solaris mntfs also
implements special ioctrls. Quoting the man page again:

[...]
IOCTLS
     The following ioctl(2) calls are supported:

     MNTIOC_NMOUNTS
           Returns the count of mounted resources in the  current
           snapshot in the uint32_t pointed to by arg.

     MNTIOC_GETDEVLIST
           Returns an array of uint32_t's that is twice  as  long
           as the length returned by MNTIOC_NMOUNTS. Each pair of
           numbers  is the major and minor device number for  the
           file  system at the corresponding  line in the current
           /etc/mnttab snapshot. arg points to the memory  buffer
           to receive the device number information.

    MNTIOC_SETTAG
           Sets a tag word into the options list  for  a  mounted
           file  system.  A tag is a notation that will appear in
           the options string of a mounted file system but it  is
           not recognized or interpreted by the file system code.
           arg points to a filled  in  mnttagdesc  structure,  as
           shown in the following example:

           uint_t  mtd_major; /* major number for mounted fs */
           uint_t  mtd_minor; /* minor number for mounted fs */
           char    *mtd_mntpt; /* mount point of file system */
           char    *mtd_tag;  /* tag to set/clear */

           If the tag already exists then it is marked as set but
           not re-added. Tags can be at most MAX_MNTOPT_TAG long.

     MNTIOC_CLRTAG
           Marks a tag in the options list  for  a  mounted  file
           system as not set. arg points to the same structure as
           MNTIOC_SETTAG, which identifies the  file  system  and
           tag to be cleared.
[...]

There is also an extended set of library functions to go along with that,
eg. getmntany(3), getextmntent(3), resetmnttab(3) and hasmntopt(3).

It is very helpful that one can get the time a mount happened! You can
not get this kind of information on Linux, neither from /etc/mtab nor from
/proc/self/mounts.

getextmnttab(3) also gives easy access to the device major and minor
number of the mount point.

So there are quite some differences between the Linux proc file and
the Solaris mntfs filesystem.  If these differences justify us doing it the
same way is debateable.

The strongest argument i see is: It's already been done this way by one
major Unix version, so why should Linux reinvent the wheel. Again.

Regards,
  Dominik
-- 
"What this  country needs is  a short, victorious war  to stem the  tide of
revolution." (V.K. von Plehve, Russian Minister  of Interior on the  eve of
the Russo-Japanese war.)


  parent reply	other threads:[~2003-02-27 16:29 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-19 11:21 DervishD
2003-02-26  9:18 ` Kasper Dupont
2003-02-26 10:26   ` Miquel van Smoorenburg
2003-02-26 11:00     ` Olaf Dietsche
2003-02-26 11:14       ` Måns Rullgård
2003-02-26 11:44         ` Kasper Dupont
2003-02-26 12:16         ` Olaf Dietsche
2003-02-26 12:34           ` Måns Rullgård
2003-02-26 13:39             ` Olaf Dietsche
2003-02-26 13:54               ` Måns Rullgård
2003-02-26 14:23                 ` Olaf Dietsche
2003-02-27  4:14   ` Miles Bader
2003-02-27  6:40     ` Kasper Dupont
2003-02-27  7:03       ` Joseph Wenninger
2003-02-27  8:28         ` Kasper Dupont
2003-03-05  0:03           ` Jamie Lokier
2003-02-27  7:06       ` Miles Bader
2003-02-27  8:25         ` Kasper Dupont
2003-02-27  8:42           ` Miles Bader
2003-02-27  9:21             ` jw schultz
2003-02-27  9:49               ` Miles Bader
2003-02-27 23:33                 ` Kasper Dupont
2003-02-27 12:48               ` Denis Vlasenko
2003-02-27 23:28                 ` Kasper Dupont
2003-02-28  6:15                   ` Denis Vlasenko
2003-03-02 13:04               ` DervishD
2003-03-02 14:16                 ` Kasper Dupont
2003-03-03  1:04                   ` jw schultz
2003-03-03 12:22                     ` Kasper Dupont
2003-03-04  2:02                       ` jw schultz
2003-03-05 12:57                         ` Kasper Dupont
2003-03-06  1:18                           ` jw schultz
2003-03-06 23:30                             ` Kasper Dupont
2003-03-04 11:16                       ` DervishD
2003-03-04 11:08                   ` DervishD
2003-02-27  9:46             ` Kasper Dupont
2003-02-27  9:58               ` Miles Bader
2003-02-27 12:26                 ` Gabriel Paubert
2003-02-27  7:07       ` Joseph Wenninger
2003-02-27  7:08       ` Dominik Kubla
2003-02-27  8:12         ` Kasper Dupont
2003-02-27  9:11           ` Dominik Kubla
2003-02-27 16:00             ` Horst von Brand
2003-02-27 16:31               ` Christoph Hellwig
2003-02-27 16:40               ` Dominik Kubla [this message]
2003-02-27 19:47                 ` Kasper Dupont
2003-02-27 22:13                   ` Valdis.Kletnieks
2003-02-27 22:31                     ` Kasper Dupont
2003-02-27 23:54                       ` Miquel van Smoorenburg
2003-02-28  1:37                         ` Miles Bader
2003-03-02 12:53     ` DervishD
2003-03-02 14:00       ` Kasper Dupont
2003-03-04 11:02         ` DervishD
2003-03-04 12:09           ` Kasper Dupont
2003-03-04 14:53             ` DervishD
2003-03-02 12:51   ` DervishD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200302271740.06139.dominik@kubla.de \
    --to=dominik@kubla.de \
    --cc=kasperd@daimi.au.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miles@gnu.org \
    --cc=raul@pleyades.net \
    --cc=vonbrand@inf.utfsm.cl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®