On Tue, 1 Aug 2000, Petr Vandrovec wrote:
> At least with ncpfs there is problem that some of mount options are
> parsed completely in userspace (passwd,ipserver), some are passed to
> mountpoint with ioctl (ttl,volume,codepage), some are mapped into VFS flags
> (ro,rw,noatime,...), some are ignored completely (auto,noauto) and some
> are pasted into binary mount structure (mode,uid,gid,owner)... So
> ncpmount has to parse options anyway...
Same for smbfs. I have a feeling I am not explaining this very well.
The mount program parses the options and filters out the ones intended for
it (passwd,ipserver,ttl,volume,codepage,ro,rw,noatime,...). That list is
known when the program is built. Any unknown options are sent to the fs
and parsed there. The command:
mount -t smbfs -o username=foo,win95,soft,intr,case=sensitive //x/y /z
ends up sending as "mount_data" the string:
version=7,win95,soft,intr,case=sensitive
(to use a silly example)
The special mount program still sets up the connection, does ioctls, ...
The only difference is that what used to be a fixed binary struct is now a
flexible ascii string. This allows an old smbmount to send a parameter to
smbfs that was not known when that samba version was released a few months
ago. That is the only thing I'm thinking about changing.
Obviously it is required to keep supporting the binary format for some
time.
> mount() failed. If there is general consensus that passing binary
> structure to mount() is stupid, I can change ncpfs behavior for 2.5.x...
No, it seems to be just me.
ncpmount and mount can be released with much shorter intervals (I know
mount is, there is always a new util-linux version whenever I check) than
smbmount can since smbmount is included with samba. That is the right
place for smbmount, but it is also why I think it needs to be more
disconnected from smbfs.
/Urban
