Certainly it goes deeper, but it is nonetheless convenient to have such
a script. If you don't like it, don't use it! If ya do, do.
> My main concern is getting autofs/automount to work and that's going
> to require some additional parameter passing and parsing. Yes, I
I believe your script handles that under the current situation, although
ideally that wouldn't be necessary.
> think that hooking this out of mount would be sweet and I stand by
> that statement. But that, you see, is actually the easy part. It's
> getting the other stuff, such as /etc/fstab and autofs / automount or
> amd to cooperate with all of the changes.
My recollection is that /etc/fstab is parsed by mount. If you're hacking
mount to understand smbfs from the command line, surely it can't be hard
to understand it from /etc/fstab either. (Quick peek at man page.) Okay,
so a library function _reads_ the file, mount is what _interprets_ its
contents for purposes of mounting. I've got a number of oft-used SMB
shares listed in my /etc/fstab; I can't mount them by service name only
yet (ie, 'mount //GHOSTWHEEL/MUSIC') but only because mount & smbfs
don't like each other (I get that nasty "SMBFS: need mount version 6"
error and then the generic mount error "wrong fs type, bad option, bad
superblock, or too many mounted filesystems"). It's interpreting the
file just fine, it's just not yet aware what to do with it.
I'm not sure about autofs/automount, but I think it works by executing
the mount program, in which case all it should need to do is _not_ treat
smbfs differently from other filesystem types if there is a SMB-aware
mount. (I could be wrong though, I haven't looked that closely at the
code.)
Of course all this talk is academic unless somebody writes some code...
I'll take a look at the mount sources tonight and see how hard it would
be to get it to understand parameters for smbfs and just pass them on to
smbmount (since there's no point in making regular old mount do all the
SMB connection stuff itself IMHO). It _shouldn't_ be hard, but then I
could be wrong in which case I will be publicly humiliated in front of
all the gurus on this list. Oh the shame! ;)
In any case this user space tool issue isn't really kernel-related
anymore, so if anyone wants to follow up to this chain of thought let's
please take it off the list.
> Now, your script could very
> well work with my version checking smbmount script so that you're mount
> script hands off to my smbmount script which, in turn calls the appropriate
> smbmount (smbfs or samba) according to which version we are running.
Yup, in fact I'm using it with your script on 2.1.113 right now. I
haven't actually tested it on 2.0.x yet, I should...
> One serious gotcha with the perl script idea though... You need
> mount to be available and functional during bootup where /usr may not
> even be mounted yet. All of my systems have /usr and /var on separate
> partitions. A perl script will not work under those circumstances and
> would break as soon as you tried to boot up. Now if you used the
Yes, that's certainly true. But I don't claim my script is an ultimate
solution to world hunger, ethnic strife, and disease - it's just a quick
convenience hack and was meant for my own system, where I don't have a
separate /usr partition and thus it's not a problem. Of course you could
have a shell script check if perl is available and then run either the
perl script or mount directly as appropriate, but that's going _way_ too
far deep in scripts IMHO! Or you could install perl under /bin and /lib
directly...
-- brion vibber (brion@pobox.com)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html