smbmount mount_data format/kernel independence
David Collier-Brown
David.Collier-Brown at canada.sun.com
Tue Aug 8 12:45:44 GMT 2000
Urban Widmark wrote:
> A different, possibly better, idea would be to replace the current binary
> format with an ascii format. This creates a similar relationship between
> smbfs and smbmount as the one between vfat and mount, ext2 and mount, ...
>
> The mount program parses the options and filters out the ones intended for
> it (username, password, workgroup, ...) the rest is sent to smbfs 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
>
> This makes smbmount capable of handling (almost) any changes to the
> flags/options passed since it does not need to understand (all of) them.
> Not unlike some of the arguments for making smbmount use mount-style
> syntax, it allows autofs to ignore what flags smbfs is using.
This is a good approach: let's see if it meets the
criteria for infinitely malleable...
1) there is a distinguished null value
yes, you can just leave out booleans, and
say "case=,' for an empty value.
2) obsolete options can be ignored
yes
3) new options can be added asynchronoulsy
yes
4) new, as yet unsupported options can be ignored
yes
5) serious incompatability can be signalled
yes, version= will do the job.
I'd go for it!
--dave
--
David Collier-Brown, | Always do right. This will gratify some people
185 Ellerslie Ave., | and astonish the rest. -- Mark Twain
Willowdale, Ontario | //www.oreilly.com/catalog/samba/author.html
Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb at canada.sun.com
More information about the samba-technical
mailing list