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