linux-libc-headers 2.6.7.0

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

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

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

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

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

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

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

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

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

HPA suggested include/abi and I don't think anyone objected.

But that's most likely a 2.7 project :(

Jeff

I'll google around.

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

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

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.

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

See http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/1008.html

(and e.g. http://lwn.net/Articles/51754/ )

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