From [email protected] 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
On Mon, 18 Aug 2003 21:07:44 +0200 (MEST) [email protected] wrote:
| From [email protected] 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."
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
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.
Followup to: <[email protected]>
By author: [email protected]
In newsgroup: linux.dev.kernel
>
> From [email protected] 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
--
<[email protected]> at work, <[email protected]> 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
On Monday 18 August 2003 21:45, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: [email protected]
> In newsgroup: linux.dev.kernel
>
> > From [email protected] 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
On Tue, 19 Aug 2003 08:55:06 -0400 Rob Landley <[email protected]> wrote:
| On Monday 18 August 2003 21:45, H. Peter Anvin wrote:
| > Followup to: <[email protected]>
| > By author: [email protected]
| > In newsgroup: linux.dev.kernel
| >
| > > From [email protected] 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."