[ANNOUNCE] linux-libc-headers 2.6.7.0

[ANNOUNCE] linux-libc-headers 2.6.7.0

[Mariusz Mazur]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.7.0

[Chris Friesen]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.7.0

[Mariusz Mazur]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.7.0

[Chris Friesen]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.7.0

[Greg KH]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.7.0

[Jeff Garzik]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.7.0

[Mariusz Mazur]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.7.0

[Andries Brouwer]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.7.0

[Sam Ravnborg]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.7.0

[Jeff Garzik]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.7.0

[Mariusz Mazur]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.7.0

[Krzysztof Halasa]

Jeff Garzik <jgarzik@pobox.com> 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

Re: [ANNOUNCE] linux-libc-headers 2.6.7.0

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] linux-libc-headers 2.6.7.0

[Andries Brouwer]

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/ )

Re: [ANNOUNCE] linux-libc-headers 2.6.7.0

[Rob Landley]

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
-- 
www.linucon.org: Linux Expo and Science Fiction Convention
October 8-10, 2004 in Austin Texas.  (I'm the con chair.)