From: jw schultz <jw@pegasys.ws>
To: Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: About /etc/mtab and /proc/mounts
Date: Wed, 5 Mar 2003 17:18:50 -0800 [thread overview]
Message-ID: <20030306011850.GA16552@pegasys.ws> (raw)
In-Reply-To: <3E65F454.825890F4@daimi.au.dk>
On Wed, Mar 05, 2003 at 01:57:57PM +0100, Kasper Dupont wrote:
> jw schultz wrote:
> > 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.
And umount? Anything that umounts or remountes a filesystem
has to modify /etc/mtab to remove or alter the relevant
line.
I traced a umount and it did the write-to-temp+rename
routine. I wouldn't expect that to work to well in proc.
And you should have seen the ugly fstat64,_llseek,write
loop it used.
To put this in kernel means changing how it is updated.
Once we do that we might as well go all the way.
> > 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
> > line.
> >
> > 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
> suggested.
>
> 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
> possibilities:
>
> 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.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: jw@pegasys.ws
Remember Cernan and Schmitt
next prev parent reply other threads:[~2003-03-06 1:08 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 [this message]
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
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=20030306011850.GA16552@pegasys.ws \
--to=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).