From: quale@saavik.cs.wisc.edu (Douglas E. Quale) Subject: Re: problems with the new mount(2) Date: 14 Jul 1992 05:31:32 GMT
In article <1992Jul13.145414.7357@bernina.ethz.ch> almesber@nessie.cs.id.ethz.ch (Werner Almesberger) writes:
>In article <1992Jul11.230357.13628@daffy.cs.wisc.edu> quale@saavik.cs.wisc.edu (Douglas E. Quale) writes:
>> I just got the latest patch to 0.96c and it changes mount(2) in a few
>> ways that I think are a bit suboptimal.
>
>Well, maybe ... I agree that it isn't well coordinated with your mount,
>but the slight difference shouldn't be too difficult to fix. (This is a
>sacrifice to compatibility with the old mount(1).)
>
>By the way, any approach that would have worked with the mount binary
>on the 0.96 root image would possibly have been incompatible with older
>mounts. (I could be wrong on this, though.) Thus, updating mount(1) was
>more or less unavoidable (and I was under the impression that you had
>planned to do that anyway ?).
>
No, either of the two approaches I mentioned would have worked with any
old mount(8) that wasn't broken. If there were broken mounts around,
all bets are off. In fact, if the int flags had been changed to void*
flags, my mount would have supported readonly out of the box. (It would
have supported noexec, nodev and nosuid as well, except that I used
different flag values.)
>> * Linux now has the only 5 argument mount(2) in the Unix universe.
>
>Well, IRIX' mount has even six arguments ;-)
>
Hmm, maybe I'm wrong. In that case, someone else might have a 5 arg
mount(2) after all.
>> * We now have yet another magic number in a system call.
>> * The FS independent mount options (ro, nosuid, noexec, nodev) are in
>> <linux/fs.h>, a file that should never be included by an application.
>
>Considering, that no other program than mount(1) is supposed to know
>about mount(2), this isn't too bad. Although I agree that linux/fs.h
>is "a bit" overloaded :-)
>
Other programs may want to look at the mount flags. BSDs statfs returns
the mount flags, but you need to know their values in order to make any
use of the information.
>> [ BSD compatibility ]
>
>Unless BSD mount(1) gets updated at a high rate, this shouldn't be too
>much of a problem either, unless BSD mount is coded in a terrible way.
>And I sort of doubt that mount(1) will be free from Linux idiosyncrasies
>forever.
>
Really? I don't think that mount(8) is all that Linux idiosyncratic.
And the old Linux mount(2) system call was sooo close to 4.3BSD mount....
Old Linux int mount(const char *__spec, const char *__dir,
const char *__type, int __flags)
BSD int mount(const char *__spec, const char *__dir,
int __type, void *__data)
In many ways I think that char* can be better for the type than int.
But the only real change we needed to make was to change our int flags
to a void*. The Minix and Ext file systems don't have file system
specific options, so they would expect an int to be passed in the flags.
MFS and NFS expect a structure, and when the kernel is ready for them,
mount(8) would be enhanced to pass them a structure in the void* argument.
I am curious how this would break any existing mount(8) binaries.
As an alternative, a new system call number should have been allocated
to the new mount (as was done for the new stat). This would ensure
absolute backward compatibitity for old binaries, and a clean interface
as well.
The advantage of using the BSD flag values is that mount(8) becomes
hairy when NFS is added (numeric valued options, forking to mount in
the background, and so on.) When we get NFS I'd love to simply make
BSD's mount and go, but this prospect is getting dimmer.
>
>Personally, I don't care a lot about what the interface looks like, as
>long as it supports the current functionality. (I always wanted -o ro
>and I needed it now for the MS-DOS FS testers. It's no problem to
>package a simple mount(1) with each release of the MS-DOS FS, that uses
>whatever interface is there. Nothing sophisticated with /etc/fstab or
>such, but sufficient for that limited purpose.)
>
>I think that the current design is reasonable, but ultimately, that's
>left to Linus to decide.
>
I think that it would be good to BSD compatible in the areas in which
the cost isn't too great. Mount(2,8) falls into that category, I think.
-- Doug Quale quale@saavik.cs.wisc.edu