a problem to compile...

Peter Samuelson peter at cadcamlab.org
Tue Aug 8 10:15:38 GMT 2000

[Urban Widmark <urban at svenskatest.se>]
> Great. I guess this means I have one supporter of my "let's make
> smbmount independent on what the current kernel sources may be"
> patch.

Yes!  The idea of distributing the necessary kernel headers with the
applications that need them is one that Linus has been pushing for a
long time now.  I.e. smbmount.tar.gz should have its own smb_fs.h,
smb_mount.h, and so forth.

The rationale: it's useless to include a newer kernel header than the
application, because if there's been any added functionality, the
application won't be able to use it anyway.  And it's useless to
include an older kernel header than the application, because it means
the compiled app may be arbitrarily limited in its functionality if and
when the user upgrades his kernel.  (It should instead have a
compatibility mode, if necessary, invoked at runtime.)  So the kernel
header version that makes sense is the newest version available at the
time the app is released.  In which case you may as well copy put those
headers in the tarball.

> The idea at least, if not the actual implementation.

It doesn't matter; I'm not qualified to judge the implementation
anyway.  smbfs totally confuses me: I've never figured out the tangle
of smbmount, smbmnt and smbfs, and exactly which part does what -- much
less actually looked beyond the surface to look at *how* any of it


More information about the samba mailing list