lkml.org 
[lkml]   [1998]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: OFFTOPIC: e2fsprogs and +2Gb partitions
On Sat, Jun 13, 1998 at 08:03:21PM +0200, Ulrich Drepper wrote:
> ak@muc.de writes:
>
> > The __ variants are 100% name space clean.
>
> It's safe in the way they do not violate standards. But these names
> are far to common (since too short) to not be used in other
> situations.

So don't define _LINUX_SOURCE then.

>
> > If they're all ifdefed with _LINUX_SOURCE then the name space
> > problem is moot anyways - _GNU_SOURCE adds name space polution,
> > _BSD_SOURCE adds name space pollution - why is Linux so special?
>
> I'm tired of repeating this on and on
>
> > I think this is a bad hack. Do you really want to duplicate kernel includes
> > in all kinds of packages? This gives bad source control problems and makes
> > extending the kernel very difficult .
>
> Talk to Linus about this. His intention is to have no user-level code
> using kernel headers and I agree. This also means that very special
> headers (like the filesystem headers) will have to come with the
> package which need them.

This is a very bad idea. If he said this he is just misguided.

Maybe he doesn't need to fix nettools when they break..



>
> > And there exists a large body of code that uses these types, if you like
> > it or not. And sometimes we need to write Linux specific code, simply because
> > Linux has some interfaces that don't exist on other systems (for example
> > the netlink interface, the SO_FILTER extension Alan pointed out etc. etc.)
>
> You miss the point. System specific code must be written, sure. But
> system specific code in the libraries is wrong since it makes these
> definitions appear as the way to go when writing a program.

Exactly, it must be writen. But currently much of this code can't be writen
with glibc, but one has to revert to libc5.

Do you really advocate duplication of kernel includes as a good solution here?

I think it would be much more profitable and generally a better solution
if we allowed sharing of specific includes between glibc programs and the
kernel as painless as possible.

I understand that this won't work for all includes because of the different
glibc ABI. It would be nice if it was possible to make the kernel includes
glibc friendly with a minimal amount of #ifdefs. I'm willing to do this work
for the network headers I'm interested in (and possible others).

But glibc needs to add some support for this too. The __uXXX/__sXXX types
are definitely needed. They are there and won't go away any time soon.

>
> And by the way: what number of programs (and what percantage) do we
> talk about? These are mainly problems for programs which are close to
> the kernel and written by the same people who wrote the kernel stuff.
> Of course you've used the same names etc which I fully can understand
> for a first implementation. But ince the programs are released to the
> world these problems should have been fixed and since the nubmer is
> quite low there is no such problem.

Fixed == duplicating the kernel includes into the program source? For me
this is not a mess, this is just generating a hard to maintain mess for
dubious gains.

-Andi


-
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.228 / U:0.096 seconds]
©2003-2011 Jasper Spaans. Advertise on this site