On Tue, 1 Aug 2000, Alexander Viro wrote:
> On Tue, 1 Aug 2000, Andreas Gruenbacher wrote:
>
> > We will probably get additional VFS-level mount options for things like
> > filesystem Capabilities and ACLs (and whatever else). There's not enough
> > space left for many extensions like that, so passing them in *data seems
> > better to me anyway.
>
> You know, I'ld rather keep it that way. _Any_ freely extendable interface
> without well-defined semantics is an invitation of ugliness. That way lies
Hmm. Can I hope for an opinion on this then:
smbmount -> smbfs pass flags in a binary structure. To change that struct
I need to find someone with samba cvs access to change it. And no one will
see the change anyway until next samba release which may be months away.
Judging from my attempts to find someone within samba to talk to about
making smbmount not include kernel headers directly that is going to be
a very time consuming process.
I have started thinking about changing smbfs to accept an ascii string and
do the parsing there. This would give smbmount <-> smbfs a relationship
more like that of, say, mount <-> vfat, mount <-> isofs, where the fs
needs parameters that are non-standard and the mount program doesn't have
to care what parameters are passed.
I assume the "invitation of ugliness" is something like it's so easy to
make changes that you will get lots of them, and different fs' would get
different sets of parameters for the same thing. Different options that
should use the same data format don't. ?
The ascii string way is much more flexible and would allow much faster
correction of such ugliness. Example: Currently (for some reason) flags to
smbfs are passed in the high bits of the file mode value.
To correct this with the current binary solution that requires a new
protocol version and a new smbmount (possibly with all sorts of
compile/version problems since it includes kernel headers directly). With
an ascii option string it would probably not have been done like that in
the first place, but changing it requires only administrator changes (fix
your fstab entry, autofs map, script).
Will you hate me forever if I manage to get smbfs to switch to an ascii
format data string? :)
I know you were talking about VFS-level options. Is it more acceptable for
fs-level options? If not, is there a plan/goal to make mount(8) start
passing a binary struct as *data?
smbfs, ncpfs and nfs could all start passing mount options as an ascii
string, if they wanted to.
/Urban
