This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A linux patch for a typo
- To: Linus Torvalds <torvalds at transmeta dot com>
- Subject: Re: A linux patch for a typo
- From: Ulrich Drepper <drepper at cygnus dot com>
- Date: 25 May 1998 14:07:47 -0700
- Cc: "Ronald F. Guilmette" <rfg at monkeys dot com>, "H.J. Lu" <hjl at lucon dot org>, GNU C Library <libc-hacker at cygnus dot com>, egcs at cygnus dot com, linuxgcc <linux-gcc at vger dot rutgers dot edu>, Kenneth Albanowski <kjahds at kjahds dot com>, Kenneth Osterberg <lmfken at lmf dot ericsson dot se>, ian at lasermoon dot co dot uk, Mat Hostetter <mat at lcs dot mit dot edu>, Andy Dougherty <doughera at lafcol dot lafayette dot edu>, Brian Bourgault <brian at mathworks dot com>, "John W. Christy" <john at etools dot com>, Craig Groeschel <craig at metrolink dot com>, Warner Losh <imp at village dot org>, Rob Farnum <robf at Willows dot Com>, Michael Meissner <meissner at cygnus dot com>, Thomas Roell <roell at xinside dot com>, Craig Burley <burley at gnu dot org>, John Polstra <linux-binutils-in at polstra dot com>, Galen Hazelwood <galenh at micron dot net>, Ralf Baechle <ralf at mailhost dot uni-koblenz dot de>
- References: <Pine.LNX.3.95.980525113526.10917B-100000@penguin.transmeta.com>
- Reply-To: drepper at cygnus dot com (Ulrich Drepper)
Linus Torvalds <torvalds@transmeta.com> writes:
> I thought glibc had moved away from using kernel header files already.
> I've talked about this to various people before, and that was one of the
> advantages with glibc as far as I was concerned.
Stop. You haven't talked to anybody, at least not to anybody involved
in glibc development. You decided everything on your own and let us
standing behind. How else would you explain that there still is
movement towards a stable solution?
You say that the only solution is for the libc to duplicate
everything. Yeah, fine for you. But simply count the extra files and
definitions this would add. And all must be kept in sync, no errors
must be introduced, updates must become available when you decide to
add new definitions and so on.
I see this is the perfect situation for you. Let some other idiots do
the work, right? You're too busy to care for APIs.
In glibc we've already replacement headers for lots of the kernel
files, mostly because namespace rules are not followed or because
definitions were in wrong headers or kernel-internal types were used.
We had to correct this. But fortunately some headers were rather
clean, they contained only the needed definitions and this makes life
much easier at this side of the syscalls. BTW, your argumentation with
`struct stat' is completely void, situations like this are handled
differently.
Just to summaries: duplicating all the kernel header information in libc
will
- introduce more bugs/incompatibilities
- slow down overall development
- more often required new releases not possible due to resource lack
And guess who gets blamed if any of the above happens? A tip: it's not you.
I always hoped that we can get an arrangement were the basic
definitions which can be shared with the userlevel can remain in the
kernel sources and that we have strict rules for writing and changing
these files. Note that I don't mean all files, only a few selected
ones (and don't argue that development is so slow that this isn't
necessary, let yet another device with new ioctls appear and we're
again forced to make changes). I've made such an proposal almost two
years ago. Nothing happened. The current form of the headers is not
usable and there is no will on the kernel developers side to change
this. You make your life easier at the cost of others. Thank you!
-- Uli
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------