Available at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/
Changes:
- updated to 2.6.7
- some minor fixes
Enjoy.
Llh is all good and nice, cause it works (most of the times anyway), but with
every new release the possibility of desync from kernel increases - downfalls
of maintaining it as a separate package. Could anybody point me to some
conclusions about how the thing should be done The Right Way (preferably with
some input from high profile kernel hackers, so I can have some assurance
that once something gets done it will get merged)?
--
In the year eighty five ten
God is gonna shake his mighty head
He'll either say,
"I'm pleased where man has been"
Or tear it down, and start again
Mariusz Mazur wrote:
> Llh is all good and nice, cause it works (most of the times anyway), but
> with
> every new release the possibility of desync from kernel increases -
> downfalls
> of maintaining it as a separate package. Could anybody point me to some
> conclusions about how the thing should be done The Right Way (preferably
> with
> some input from high profile kernel hackers, so I can have some assurance
> that once something gets done it will get merged)?
Not a high profile hacker, but you might try submitting a patch adding an
include/user_abi directory (or whatever it should be called) and putting one of
your files there, with patches to the original kernel header file to remove the
userspace bits and include the new file. That would maybe kick off some discussion.
Chris
On czwartek, 24 czerwca 2004 00:54, Chris Friesen wrote:
> Not a high profile hacker, but you might try submitting a patch adding an
> include/user_abi directory (or whatever it should be called) and putting
> one of your files there, with patches to the original kernel header file to
> remove the userspace bits and include the new file. That would maybe kick
> off some discussion.
I'm interested in guidelines, not discussion :)
Kernel guys had a couple of years since 2.4 for discussing this so something
*must* have been agreed upon.
--
In the year eighty five ten
God is gonna shake his mighty head
He'll either say,
"I'm pleased where man has been"
Or tear it down, and start again
Mariusz Mazur wrote:
> Available at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/
> Changes:
> - updated to 2.6.7
> - some minor fixes
>
> Enjoy.
>
>
> Llh is all good and nice, cause it works (most of the times anyway), but with
> every new release the possibility of desync from kernel increases - downfalls
> of maintaining it as a separate package. Could anybody point me to some
> conclusions about how the thing should be done The Right Way (preferably with
> some input from high profile kernel hackers, so I can have some assurance
> that once something gets done it will get merged)?
HPA suggested include/abi and I don't think anyone objected.
But that's most likely a 2.7 project :(
Jeff
On czwartek, 24 czerwca 2004 01:17, Jeff Garzik wrote:
> HPA suggested include/abi and I don't think anyone objected.
I'll google around.
> But that's most likely a 2.7 project :(
Why? The sooner the better.
--
In the year eighty five ten
God is gonna shake his mighty head
He'll either say,
"I'm pleased where man has been"
Or tear it down, and start again
Mariusz Mazur wrote:
> I'm interested in guidelines, not discussion :)
> Kernel guys had a couple of years since 2.4 for discussing this so
> something
> *must* have been agreed upon.
After a bit of googling...
Andries Brouwer suggested include/linuxabi with arch-specific dirs
H. Peter Anvin apparently suggested putting them in include/abi, with
arch-specific dirs. However, he thinks its too much work for 2.6 and sees it as
an early 2.7 thing.
Matthew Wilcox apparently suggested something similar
Jeff Garzik approved the idea
Rob Landley suggested moving your headers there and then cleaning up the other
headers, and expressed willingness to submit patches.
Sam Ravnborg supported the idea
Eric Biederman supported the idea, suggested linux-only namespace and
version-based naming, figured it was 2.7 work
David Miller approved the idea
Maybe this should be a topic for the kernel summit or a BOF session at OLS?
Chris
On Wed, Jun 23, 2004 at 07:48:56PM -0400, Chris Friesen wrote:
>
> Maybe this should be a topic for the kernel summit or a BOF session at
> OLS?
I don't see any objections, just no patches have been submitted that do
this work. Why would a BOF be needed to create a patch? :)
greg k-h
Greg KH wrote:
> On Wed, Jun 23, 2004 at 07:48:56PM -0400, Chris Friesen wrote:
>
>>Maybe this should be a topic for the kernel summit or a BOF session at
>>OLS?
>
>
> I don't see any objections, just no patches have been submitted that do
> this work. Why would a BOF be needed to create a patch? :)
Agreed... It's just getting 'down and dirty' and separating the ABI
stuff from the non-ABI stuff. It's not necessarily difficult, just
incredibly long and tedious, and potentially political.
But nonetheless a worthy goal :)
Jeff
On czwartek, 24 czerwca 2004 11:18, Jeff Garzik wrote:
> Agreed... It's just getting 'down and dirty' and separating the ABI
> stuff from the non-ABI stuff. It's not necessarily difficult, just
> incredibly long and tedious, and potentially political.
One step at a time. It's quite simple to remove userland definitions from a
header and place them somewhere else (at least technically). Since kernel
headers are currently useless in userland anyway, nobody should care if they
get altered any more (yeah... right :). My plan is to take care of the
functionality covered by glibc first and start separating that stuff to some
abi dir (that is why I've requested more details). Once a patch for
separating header A gets merged and a new kernel gets released I'd simply
make llh use that abi header thus making llh a kind of compatibility layer -
apps could still include the old linux/ stuff while in fact using the new abi
headers. Nothing would get broken this way.
Once all glibc covered stuff got separated, glibc (and all other libcs for
that matter) would probably start using it (would they?), thus removing all
those bloody conflicts and making glibc always up to date.
Doable plan (at least in theory). The main question is - will those patches
get gradually merged into mainline? (Is there any possibility of getting a
yes/no answer from Linus?)
If not, the thing gets pointless, since maintaining such patches outside the
kernel would only need additional work, give no real benefit and accumulate
errors with time.
--
In the year eighty five ten
God is gonna shake his mighty head
He'll either say,
"I'm pleased where man has been"
Or tear it down, and start again
On Wed, Jun 23, 2004 at 10:58:32PM -0700, Greg KH wrote:
> On Wed, Jun 23, 2004 at 07:48:56PM -0400, Chris Friesen wrote:
> >
> > Maybe this should be a topic for the kernel summit or a BOF session at
> > OLS?
>
> I don't see any objections, just no patches have been submitted that do
> this work. Why would a BOF be needed to create a patch? :)
Let me contradict this. Several people, probably independently,
submitted a header setup and a patch that did the required work
for a small handful of header files.
As far as I know Linus has not reacted to such patches.
Since the total amount of work is, like Jeff says, incredibly long and tedious,
it is unreasonable to expect that all be done before anything is put in the
default kernel tree.
At some point in time Linus either has to describe his setup, or
accept a setup someone submits. Maybe a BOF would be useful to
find out precisely what requirements there are, but only if Linus
is present, because we have had enough discussion already.
Andries
On Thu, Jun 24, 2004 at 03:53:43PM +0200, Andries Brouwer wrote:
> Let me contradict this. Several people, probably independently,
> submitted a header setup and a patch that did the required work
> for a small handful of header files.
Header file cleanup has a tendency to break the compile in some configurations.
This was obvious during the effort to clean up the include mess in the 2.5 time.
That's maybe the primary reason to postpone it to 2.7.
Sam
Jeff Garzik <[email protected]> writes:
> HPA suggested include/abi and I don't think anyone objected.
>
> But that's most likely a 2.7 project :(
I think we should start with (and it doesn't have to wait for 2.7):
/usr/include/abi -> linux/include/abi
/usr/include/linux -> abi (obsolete, to be removed with 2.8)
Appropriate $ARCH + generic dirs (names?).
in the kernel:
mkdir linux/include/abi (and appropriate $ARCH + generic dirs - names?)
for f in all-user-space-header-names; do
copy << EOF >> linux/include/abi/$f
#ifndef __ABI_HEADER_H
#define __ABI_HEADER_H
#ifdef __KERNEL__
#include <linux/header.h>
#else
#include <linux-internal/header.h>
#endif
#endif
I above scheme should give us a) source compatibility with both kernel
and userland files, b) smooth transition without a single 50 MB patch,
c) allows each maintainer to move/clean "her/his" headers independently.
After a header file is "cleaned" it would look like:
#ifndef __ABI_HEADER_H
#define __ABI_HEADER_H
#include <abi/required_headers.h>
... actual ABI definitions
#endif
-------
#ifndef __LINUX_HEADER_H
#define __LINUX_HEADER_H
#include <abi/required_headers.h>
#include <linux/required_headers.h>
... kernel-only stuff
#endif
--
Krzysztof Halasa, B*FH
hi :)
On Thu, Jun 24, 2004 at 06:43:56PM +0200, Krzysztof Halasa wrote:
> > HPA suggested include/abi and I don't think anyone objected.
well, include/abi looks very generic. For userspace code, I really
like to have 'linux' in the include file name, so that it's clear that
some linux-specific header is being used.
> /usr/include/abi -> linux/include/abi
> /usr/include/linux -> abi (obsolete, to be removed with 2.8)
> Appropriate $ARCH + generic dirs (names?).
what about keeping /usr/include/linux for the userspace visible part
of the linux headers and using a new name for the internal headers.
That way we don't have to change userspace applications and can
do all modifications in the kernel tree at the time we want.
For example:
* mkdir include/kernel (plus arch-specific versions)
* add placeholer files that simply #include the old include/linux file
* start replacing in-kernel #includes with the include/kernel version.
* move the #ifdef __KERNEL__ parts from include/linux to include/kernel
This can be done incrementally, too.
--
Martin Waitz
On Fri, Jun 25, 2004 at 11:25:57AM +0200, Martin Waitz wrote:
> * mkdir include/kernel (plus arch-specific versions)
> * add placeholer files that simply #include the old include/linux file
> * start replacing in-kernel #includes with the include/kernel version.
> * move the #ifdef __KERNEL__ parts from include/linux to include/kernel
See http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/1008.html
(and e.g. http://lwn.net/Articles/51754/ )
On Wednesday 23 June 2004 17:20, Mariusz Mazur wrote:
> Available at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/
> Changes:
> - updated to 2.6.7
> - some minor fixes
>
> Enjoy.
>
>
> Llh is all good and nice, cause it works (most of the times anyway), but
> with every new release the possibility of desync from kernel increases -
> downfalls of maintaining it as a separate package. Could anybody point me
> to some conclusions about how the thing should be done The Right Way
> (preferably with some input from high profile kernel hackers, so I can have
> some assurance that once something gets done it will get merged)?
Follow the thread:
http://seclists.org/lists/linux-kernel/2004/Jun/4713.html
Randy Dunlap mentioned a linux abi mailing list. I subscribed a few days ago,
but no traffic's come across it yet...
http://zytor.com/mailman/listinfo/linuxabi
Rob
--
http://www.linucon.org: Linux Expo and Science Fiction Convention
October 8-10, 2004 in Austin Texas. (I'm the con chair.)