lkml.org 
[lkml]   [1996]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Horrible things with 1.3.78
Brian Blackmore writes:
> But using the libc headers instead of the correct kernel headers
> isn't necessarly going to work either, we are going to get people
> upgrading their kernel to one where a few ioctl's have changed and
> the wondering why they are not getting the new functionality (the
> reason being of course that they linked with the wrong includes).

This is a relatively simple problem and could be dealt with using a
more carefully phrased set of instructions in /usr/src/linux/README.

> In addition to this having a large number of what are essentally
> kernel defines/typedefs having to be duplicated by a different
> group of people on what is essentally a different project is asking
> for the two sets to get out of step rather often (ask anyone whos
> ever worked on a large project and they will tell you this).

You're confusing libc development with libc use. Development of libc
can continue to happen using the current mechanisms.

On the other hand, the portions of libc which interfaces with the
kernel ought to be carefully factored into an architecture-dependent
area. For example, take a look at elf/d-link/i386/ -- why isn't this
stuff in sysdeps/i386/elf/? Or, take a look at
include/pthread/mit/unistd.h...

I suspect that this sort of stuff will get dealt with, somehow, as the
linux porting projects gain more ground. Maybe some of this has even
been cleaned up with more recent versions of libc?

--
Raul


\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.043 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site