This is the mail archive of the libc-alpha@sources.redhat.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: Inclusion of Linux headers in current glibc


>>>>> Linus Torvalds writes:

Linus> On 27 Jul 2000, Andreas Jaeger wrote:
>> 
>> Checking all the *.d files on i686 shows that only these 25 headers are
>> needed for compiling (!) glibc:

Linus> [ nice list removed - compare this to the whole kernel header tree, and
Linus>   shudder ]

>> The question is now what we should do, I don't think I've need to
>> rephrase the problems we have with the inclusion of kernel headers
>> (even if every release of glibc includes less headers).  I see the
>> following suggestions and I might consider doing the work if we come
>> (but wouldn't mind if somebody else does it;-) to a consensus:

Linus> What I suggested a few times to Uli was to just copy the specific headers
Linus> you need to the glibc tree, and then even _edit_ them to possibly remove
Linus> unnecessary cruft (stuff inside __KERNEL__ etc - it makes the user land
Linus> compile slower for no good reason).

Linus> Uli, probably correctly, said that it was a maintenance nightmare, and
Linus> that glibc does want to occasionally sync up with the kernel. So
Linus> especially the editing seems to be out. 

Linus> Some kind of automated crawler thing might make the maintenance issue less
Linus> pressing. It might even just something as simple as just automating the
Linus> pruning of the kernel header tree: if it cuts down the tree from 2632
Linus> header files to 25, then at least it's easier to check for changes ;)

Linus> One solution might be an automated pass, followed by some final touches by
Linus> hand. How often does glibc tend to synchronize to a new kernel? And if it
Linus> is often, maybe it wouldn't have to be (ie only do this when a new version
Linus> of glibc is cut, or whenever parts of glibc actually _need_ new kernel
Linus> interfaces, which is probably fairly seldom except on newly developed
Linus> architectures).

For some headers we already copy the kernel header definitions.  Uli
and myself try to go through every new kernel patch and check your
changes manually.  But sometimes we miss changes.  Having a tool to
compare kernel and glibc headers and to report discrepancies would be
really nice.


Linus> I don't know enough about how glibc is developed to really make a good
Linus> judgement..

But we should find a way where all of us are happy

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de

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