Re: [ANNOUNCE] linux-libc-headers 2.6.3.0
From: Chris Friesen
Date: Thu Mar 04 2004 - 16:29:49 EST
Mariusz Mazur wrote:
Parts of abi that are standardized
(http://www.opengroup.org/onlinepubs/007904975/ - this thing; check the
headers section), should be imho provided by C libs. These things do not
change (they can't or everything would blow up) and I see no reason why glibc
should rely on having additional headers available, just to do what it's
supposed to.
And how do you propose to handle a kernel developer that wants to add a
new feature (a scheduling class, for instance) and make it available to
userspace apps?
For the sched class example, the standard says, "Four scheduling
policies are defined; others may be defined by the implementation." I
would like to make it easy for kernel developers to extend the
implementation and expose that to userspace.
It would be nice to have apps be able to include <linux/sched.h> and get
the *real* kernel sched.h userspace export. Then when I add
SCHED_NEW_CLASS to the kernel, userspace can pick up the changes without
me having to modify glibc headers as well.
As to linux-common linux-kernelonly and linux-userland headers (linux-common
used by both) - I just find it weird for userland to require kernel sources.
Linux is supposed to have stable abi.
I would prefer to have the standard userspace kernel headers be owned by
the kernel. If we do it right, we could go back to the days of the
symlink to the headers of the real running kernel. As far as I can
tell, that's the only way to avoid having to make changes in multiple
places.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: cfriesen@xxxxxxxxxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/