Messages in this thread |  | | | Date | Sat, 13 Jun 1998 21:32:02 +0200 | | From | ak@muc ... | | Subject | Re: 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
|  |