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
