Sidebar to smbmount patch (re mutating structs)

[Urban Widmark]

[Sorry for sending the question twice, but on this list I apparently don't
 get to see my own posts but on the samba list I do. If there is a flag
 somewhere I missed for this, please point me, I have failed to find it. ]

On Mon, 17 Jul 2000, David Collier-Brown wrote:

> 	At the binary level, it's fairly straightforward to 
> 	deal with callers passing in both "old" and "new"
> 	formats of struct: just labourious.

Not terribly, but yes. I don't want to answer the questions why smbmount
stopped working, I believe it is much less work making sure it keeps
working.


> 	[anyone interested send me email: I have a paper
> 	from my Multics days on the subject I can scan or
> 	type in]

If its not too much work for you I'm interested (scan+ocr seems a lot
easier than typing it ... :)

> 	However, this is "breaking the contract" between the
> 	producer and the consumer of the struct, and is one of 

Not really, it wasn't my intention to break the existing "contract"
(but I think I made it sound a lot like that because I wasn't very clear 
 on the details in my own head, much less in writing).

Breaking it generates support. Support bad.

It's more about where/how that contract is defined. There is a clear
message from "leading kernel developers" that userspace and kernelspace
should be separated even on the include-file level.
    http://www.uwsg.indiana.edu/hypermail/linux/kernel/9806.2/0010.html
(it's old now, but the issue comes up every now and then with similar
 responses)

The idea is that it is easier for a package maintainer to to have defines
that match the versions the package supports than it is for the kernel
tree to have defines for every version in existance. As I understand it.
That helps the next time you want to improve the interface.

My current idea for this is something like:

#define SMB_MOUNT_VERSION       6
#ifdef __KERNEL__
#define __SMB_MOUNT_VERSION     7
#endif

Which would neatly hide the new version from old code. New code would have
to break the rules by giving a -D__KERNEL__ or copy the definitions.

And there is the practical problem of compiling smbmount on an
installation where the kernel and smbmount both understands v7 structs but
it reads v6 kernel header files from the /usr/include tree (many
distributions send a separate header tree matching the version glibc was
compiled with (?), not the currently installed kernel version/latest
version).

Again it's much less support work if smbmount has the v6 & v7 definitions
itself. No need to tell people to point the compiler to the right
includes, that they may or may not have.


> 	So I reccomend that smbmount version x.y+1 be #ifdef'd
> 	so as to require version 7 structs, and produce a

The ifdef allows you to remove support for old things but not add new in
a nice overlaping way. or?

It wouldn't be very nice for smbmount-2.0.8 (or whatever) to stop
compiling with linux 2.2.14. It would be nice if smbmount-2.0.8 can
support both 2.2.14 and a 2.4.xyz with new parameters.

/Urban