lkml.org 
[lkml]   [2003]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: About /etc/mtab and /proc/mounts
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.085 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site