The proposal I made doesn't suffer from these problems, IMHO. The
reason is that the kernel doesn't care about the naming scheme libc
would like. It simply provides manifest constants and a few special
structures to userspace.
If libc wants a particular constant in file
"i_think_this_is_better_and_stuff_backwards_compatibility.h" then libc
creates such a file and includes the appropriate kernel interface
header, with any renaming as needed.
> It's a mess. When I make small changes to certain header files, I don't
> know what will break in completely unrelated user-level header files.
If you change manifest constants, then binary compatibility will
break. I figure you don't want to do that :-) so this isn't an
issue. The kernel interface files contain just that which userpace
*must have*. Manifest constants are the main candidates here.
> > An extreme solution would be to have all types/macros/whatever in
> > kernel include files prefixed by "Kernel"/"KERNEL_" or something
> > similar. We in effect claim a namespace for eternity.
>
> We do that for certain things. The most basic types have a __kernel_xxx
> name, exactly to allow certain very limited interaction. But it doesn't
> work for everything.
Why not? If that is *all* the kernel exports, where is the problem?
> And one point is really that yes, I can see how you can make it work. You
> can create separate "exported" subtrees of the header files, and create a
> committee to discuss the standards that ensue, etc etc ad nauseam.
No standards. You declare a prefix for all names (claiming a
namespace) and export those. I don't care if you have something like:
#define _KERNEL_family_unix_socket 1
rather than:
#define _KERNEL_AF_UNIX 1
As long as you promise not to change that number (which I know you
don't want to, because it means you're going to break binary
compatibility), there is no problem.
I think the reason you are worried about providing a source interface
is because some anal-retentive person is going to whinge to pretty
please make the name conformant to this afternoon's latest standard.
I say: don't worry! This interface is provided so userspace can get
access to the numbers. It doesn't matter what the names are, as long
as they can be relied upon in the future. Anyone asking for the name
to be changed can be (quite reasonably) told to get stuffed. No, in
fact, tell them to get f**cked. People who want pretty names will be
expected to provide wrapper includes which change the names.
As for choosing what names to put in the first place: once again,
don't worry. The decision is yours (or you maintainers of the relevant
piece of kernel code). Only kernel maintainers have any say in
this. The only requirement is that all names in the exported namespace
are unique. That shouldn't be too hard. Once a name has been define in
the namespace, it is there to say, irrespective if people like it or
not.
If you're still worried, put a warning at the top of each export
header saying that no discussion on renaming will be tolerated.
> But the point is that I DO NOT WANT TO. It is too stifling. I'm more than
> happy to maintain binary compatibility backwards (within reason - even
> that is occasionally broken, especially for "system binaries" like
> "ifconfig" etc). But I refuse to maintain that on a source level, because
> I see absolutely _no_ positive feedback from it.
How is the scheme I'm suggesting stifling?
> For example, what is the advantage for ext2fs-tools to try to use the
> kernel header files?
So they don't have to duplicate the magic numbers. Having the same
piece of information in two places is unhealthy.
> Using the kernel header files is horrible. Imagine somebody at some random
> Linux distribution company, and some developer tracking new kernel
> releases. He does all his development on a new kernel, because he wants to
> personally use new features even if the distribution doesn't actually ship
> with that kernel by default. He does all the debugging, and creates the
> RPM for various packages.
>
> And then they are all compiled for the CD on another machine which happens
> to have a different kernel tree. Does anybody _really_ think that it is
> acceptable that now suddenly the binaries are different from the ones that
> the developer was testing and debugging? Quite frankly, if anybody thinks
> that this is acceptable behaviour, I can only pity them.
Under my scheme a change of a magic number breaks source and binary
compatibility. The problems you mention don't seem to problems with my
scheme.
> In short, the build process _has_ to be completely separated from the
> kernel, if only to make it completely repeatable. When you install a
> compiler and a library, the binaries produced by that compiler and that
> library had better be the same regardless of whether the user has updated
> their kernel. Anything else is simply not sane behaviour.
It doesn't *have* to be separated. It just needs to have a sane an
reliable, consistent interface.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu