headers

headers

[Andries.Brouwer]

    From garzik@gtf.org  Mon Aug 18 20:14:47 2003

    I support include/abi, or some other directory that segregates
    user<->kernel shared headers away from kernel-private headers.

    I don't see how that would be auto-generated, though.  Only created
    through lots of hard work :)

Yes, unfortunately. I started doing some of this a few times,
but it is an order of magnitude more work than one thinks at first.
Already the number of include files is very large.
And the fact that it is not just include/abi but involves the architecture
doesn't make life simpler.

No doubt we must first discuss a little bit, but not too much,
the desired directory structure and naming.
Then we must do 5% of the work, and come back to these issues.

In case people actually want to do this, I can coordinate.

In case people want to try just one file, do signal.h.

Andries

Re: headers

[Randy.Dunlap]

On Mon, 18 Aug 2003 21:07:44 +0200 (MEST) Andries.Brouwer@cwi.nl wrote:

|     From garzik@gtf.org  Mon Aug 18 20:14:47 2003
| 
|     I support include/abi, or some other directory that segregates
|     user<->kernel shared headers away from kernel-private headers.
| 
|     I don't see how that would be auto-generated, though.  Only created
|     through lots of hard work :)
| 
| Yes, unfortunately. I started doing some of this a few times,
| but it is an order of magnitude more work than one thinks at first.

I expected that.

| Already the number of include files is very large.
| And the fact that it is not just include/abi but involves the architecture
| doesn't make life simpler.
| 
| No doubt we must first discuss a little bit, but not too much,
| the desired directory structure and naming.
| Then we must do 5% of the work, and come back to these issues.
| 
| In case people actually want to do this, I can coordinate.
| 
| In case people want to try just one file, do signal.h.

Hm, interesting.

Since there are 20+ <arch>/signal.h files and they don't always agree
on signal bit numbers e.g., do we have 20+ abi/arch/signal.h files?
Or 1 abi/signal.h file with many #ifdefs?  ugh.

The ABI is still per-arch, right?  Not _one ABI_ for any/all arches.

Or maybe I'm all wet.

--
~Randy
"Everything is relative."

Re: headers

[Jeff Garzik]

Randy.Dunlap wrote:
> Hm, interesting.
> 
> Since there are 20+ <arch>/signal.h files and they don't always agree
> on signal bit numbers e.g., do we have 20+ abi/arch/signal.h files?
> Or 1 abi/signal.h file with many #ifdefs?  ugh.
> 
> The ABI is still per-arch, right?  Not _one ABI_ for any/all arches.


Correct.  So there would be an include/abi/i386 or include/abi/arch/i386 
or whatever, in addition to regular 'ole include/abi.  Or maybe 
include/asm-$arch/abi.  Take your pick :)  Arch separation is definitely 
a requirement, as you guessed.

	Jeff

Re: headers

[Andries Brouwer]

On Mon, Aug 18, 2003 at 02:57:09PM -0700, Randy.Dunlap wrote:
> | In case people want to try just one file, do signal.h.
> 
> Since there are 20+ <arch>/signal.h files and they don't always agree
> on signal bit numbers e.g., do we have 20+ abi/arch/signal.h files?
> Or 1 abi/signal.h file with many #ifdefs?  ugh.
> 
> The ABI is still per-arch, right?  Not _one ABI_ for any/all arches.

Yes, per arch.

Re: headers

[H. Peter Anvin]

Followup to:  <UTC200308181907.h7IJ7im12407.aeb@smtp.cwi.nl>
By author:    Andries.Brouwer@cwi.nl
In newsgroup: linux.dev.kernel
>
>     From garzik@gtf.org  Mon Aug 18 20:14:47 2003
> 
>     I support include/abi, or some other directory that segregates
>     user<->kernel shared headers away from kernel-private headers.
> 
>     I don't see how that would be auto-generated, though.  Only created
>     through lots of hard work :)
> 
> Yes, unfortunately. I started doing some of this a few times,
> but it is an order of magnitude more work than one thinks at first.
> Already the number of include files is very large.
> And the fact that it is not just include/abi but involves the architecture
> doesn't make life simpler.
> 
> No doubt we must first discuss a little bit, but not too much,
> the desired directory structure and naming.
> Then we must do 5% of the work, and come back to these issues.
> 
> In case people actually want to do this, I can coordinate.
> 
> In case people want to try just one file, do signal.h.
> 

Oh yes, this is a whole lot of work.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: headers

[Rob Landley]

On Monday 18 August 2003 21:45, H. Peter Anvin wrote:
> Followup to:  <UTC200308181907.h7IJ7im12407.aeb@smtp.cwi.nl>
> By author:    Andries.Brouwer@cwi.nl
> In newsgroup: linux.dev.kernel
>
> >     From garzik@gtf.org  Mon Aug 18 20:14:47 2003
> >
> >     I support include/abi, or some other directory that segregates
> >     user<->kernel shared headers away from kernel-private headers.
> >
> >     I don't see how that would be auto-generated, though.  Only created
> >     through lots of hard work :)
> >
> > Yes, unfortunately. I started doing some of this a few times,
> > but it is an order of magnitude more work than one thinks at first.
> > Already the number of include files is very large.
> > And the fact that it is not just include/abi but involves the
> > architecture doesn't make life simpler.
> >
> > No doubt we must first discuss a little bit, but not too much,
> > the desired directory structure and naming.
> > Then we must do 5% of the work, and come back to these issues.
> >
> > In case people actually want to do this, I can coordinate.
> >
> > In case people want to try just one file, do signal.h.
>
> Oh yes, this is a whole lot of work.

But is it 2.6 work, or 2.8 work?

Rob

Re: headers

[Randy.Dunlap]

On Tue, 19 Aug 2003 08:55:06 -0400 Rob Landley <rob@landley.net> wrote:

| On Monday 18 August 2003 21:45, H. Peter Anvin wrote:
| > Followup to:  <UTC200308181907.h7IJ7im12407.aeb@smtp.cwi.nl>
| > By author:    Andries.Brouwer@cwi.nl
| > In newsgroup: linux.dev.kernel
| >
| > >     From garzik@gtf.org  Mon Aug 18 20:14:47 2003
| > >
| > >     I support include/abi, or some other directory that segregates
| > >     user<->kernel shared headers away from kernel-private headers.
| > >
| > >     I don't see how that would be auto-generated, though.  Only created
| > >     through lots of hard work :)
| > >
| > > Yes, unfortunately. I started doing some of this a few times,
| > > but it is an order of magnitude more work than one thinks at first.
| > > Already the number of include files is very large.
| > > And the fact that it is not just include/abi but involves the
| > > architecture doesn't make life simpler.
| > >
| > > No doubt we must first discuss a little bit, but not too much,
| > > the desired directory structure and naming.
| > > Then we must do 5% of the work, and come back to these issues.
| > >
| > > In case people actually want to do this, I can coordinate.
| > >
| > > In case people want to try just one file, do signal.h.
| >
| > Oh yes, this is a whole lot of work.
| 
| But is it 2.6 work, or 2.8 work?

I think that we are currently discussing it as 2.7 work.

--
~Randy
"Everything is relative."