linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kasper Dupont <kasperd@daimi.au.dk>
To: jw schultz <jw@pegasys.ws>, Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: About /etc/mtab and /proc/mounts
Date: Fri, 07 Mar 2003 00:30:55 +0100	[thread overview]
Message-ID: <3E67DA2F.500EEE5B@daimi.au.dk> (raw)
In-Reply-To: 20030306011850.GA16552@pegasys.ws

jw schultz wrote:
> 
> And umount?  Anything that umounts or remountes a filesystem
> has to modify /etc/mtab to remove or alter the relevant
> line.

That is not an issue. With my suggestion the line is automatically
removed by the kernel at umount. If the umount program changes the
line before calling the umount system call, the changed line is
discareded anyway. If the umount program try to change the line
after calling umount, it is simply ignored. Currently this is not
going to happen anyway with a umount program that see /etc/mtab
is a symlink and simply skips the update. An updated umount
program for the new approach will simply remove all the code
related to updating mtab.

> 
> To put this in kernel means changing how it is updated.
> Once we do that we might as well go all the way.

Yes, in this case it means umount is not going to write at all.
It only needs to read the file for the user specific options.
(To know if the calling user is allowed to umount.) The read can
be done either through the /etc/mtab symlink or the /proc
interface, I prefer the later.

> >
> > 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
> >    user data.
> 
> #2 with warnings i like better than keeping a deprecated mount
> syscall until 2038.

But by adding options to the existing systemcall we are going
to keep historic options and magic values in that system call
forever. With the new system call we have at least collected all
the historic parts in a single obsolete system call, that can
eventually be removed. Anyway I think this is a minor detail,
both approaches will be an improvement over the current mtab
file. So whatever people prefer I'd be happy with.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

  reply	other threads:[~2003-03-06 23:20 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-19 11:21 About /etc/mtab and /proc/mounts 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 [this message]
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
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=3E67DA2F.500EEE5B@daimi.au.dk \
    --to=kasperd@daimi.au.dk \
    --cc=jw@pegasys.ws \
    --cc=linux-kernel@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).