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