This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A linux patch for a typo


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]