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
Linus Torvalds writes:
>
>
> 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.

Dave made a reasonable point about time delay between kernel features
and something appearing in userspace.

BTW: one of your points about userspace code having to change anyway
when a new feature is added isn't quite true:

#define _KERNEL_FL_DEFAULT (_KERNEL_FL_A | _KERNEL_FL_B)

when someone decides that newer kernels require some flag to be
explicitely set. I remember this happening with the networking code a
while back. In this scenario no userspace source needs to be changed:
just a recompile is needed. And the binary should still work fine with
older kernels.

> I won't be changing constants any time soon, exactly because that would
> break binary compatibility.

My scheme is essentially a published table of magic numbers.

> 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.

And a truckload of userspace utilities which need magic numbers not
provided by libc so they peek at the kernel headers.

> 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.

Because of the libc4/5 legacy and because we don't have a rational
scheme.

> "cp" is your friend. Do it once, and be over with it.

And when a new kernel defines some new magic numbers, off we go and
copy/edit or merge/edit. Finger trouble will likely result in
duplicate defines or missing defines or an assortment of both.

> > > 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.

No, you have kernel-private renaming:
#define __KernelType_u8 u8

Userspace can do it's own renaming which you don't care about.

> - 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.

Slowly migrate magic numbers from existing headers into the interface
headers, and put the renaming in the existing headers. Not only is
this perfectly safe (sans typos) it ensures that only that which needs
to be exported is (because it's a manual process).

> - 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.

In the kernel code you use the renamed stuff. You are free to move
around kernel-private headers. The only things that don't change are
locations of the interface headers and the names therein. Is that so
restrictive?

> > > 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.

All you would now need is the kernel interface headers. These would be
small. You could then build all system utilities under a foreign OS.

> 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".

But it's not a simple "cp". It's copy/edit or merge/edit. This is
because you don't want all the kernel-internals stuff, so you have to
edit it out.

> > 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.

We could start with just magic numbers to prove the concept.

> > 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?

You don't need a committee because the inteface names *don't
matter*. They only need to be unique (sane) and permanent (reliable,
consistent).

Regards,

Richard....

-
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.316 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site