lkml.org 
[lkml]   [1998]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.098 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site