Messages in this thread | | | Date | Tue, 16 Jun 1998 09:44:43 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: OFFTOPIC: e2fsprogs and +2Gb partitions |
| |
On Tue, 16 Jun 1998, Richard Gooch wrote: > > 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
What's the point?
Copy the file _once_ to the library headers, and you never have to worry again.
I won't be changing constants any time soon, exactly because that would break binary compatibility.
But if the file is copied, that means that I don't have to worry about libraries, and the library maintainer doesn't have to worry about kernels.
People claim that it's less work having just one set of header files, but they are _wrong_. It's _more_ work. Every friggin time somebody sends me patches to header files I worry about it.
"cp" is your friend. Do it once, and be over with it.
> > 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?
Because exporting _anything_ means: - I have to use the ridiculous naming scheme. I don't want to. I want to call my constants "HZ" if I want to, and when somebody complains that it is against the ANSI C standard to have such a defince, I tell them to go away and not bother me. - I need to be careful about what else I export. I'd better not export any kernel stuff, because the thing that expects to have __KERNEL_AF_UNIX exported, does _not_ want to have "struct sk_buff *" exported. - it means that I have to always support one location with the exports. So I'd need to forever have include/linux/xxx.h, even though I'd make a change to the setup of the kernel where it would be more logical for me to internally have that in include/linux/yyy.h. Which in turn means that not only do I get to look at the horrible mangled names (for identifier namespace cleanliness), I'd probably have to look at the horrible mangled header file-names too, for "filename namespace" reasons.
That's stiling.
> > 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.
No it isn't.
The ext2 tools needed to contain the constants _anyway_ - if you look at the sources you'll find that the thing compiles under other operating systems, and at least at one point it did _not_ imply having kernel sources available.
And why is duplication bad? That's just some semi-religious mantra, but it has absolutely no meaning. Instead of calling it duplication, think of it as "replication", which for some strange reason is considered a positive thing in CS, even though it means the same thing as "duplication" which has these silly negative connotations.
I'm not suggesting somebody type in the numbers, and maybe get them wrong. I'm suggesting "cp".
> 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.
If it was as easy as just a set of magic numbers, we'd be home free.
> It doesn't *have* to be separated. It just needs to have a sane an > reliable, consistent interface.
Oh. And what committee do you propose to set the standard interface?
No thank you.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |