* headers
@ 2003-08-18 19:07 Andries.Brouwer
2003-08-18 21:57 ` headers Randy.Dunlap
2003-08-19 1:45 ` headers H. Peter Anvin
0 siblings, 2 replies; 7+ messages in thread
From: Andries.Brouwer @ 2003-08-18 19:07 UTC (permalink / raw)
To: Andries.Brouwer, Dominik.Strasser, hch, jgarzik, linux-kernel, torvalds
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: headers
2003-08-18 19:07 headers Andries.Brouwer
@ 2003-08-18 21:57 ` Randy.Dunlap
2003-08-18 22:04 ` headers Jeff Garzik
2003-08-18 22:17 ` headers Andries Brouwer
2003-08-19 1:45 ` headers H. Peter Anvin
1 sibling, 2 replies; 7+ messages in thread
From: Randy.Dunlap @ 2003-08-18 21:57 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: Dominik.Strasser, hch, jgarzik, linux-kernel, torvalds
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."
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: headers
2003-08-18 21:57 ` headers Randy.Dunlap
@ 2003-08-18 22:04 ` Jeff Garzik
2003-08-18 22:17 ` headers Andries Brouwer
1 sibling, 0 replies; 7+ messages in thread
From: Jeff Garzik @ 2003-08-18 22:04 UTC (permalink / raw)
To: Randy.Dunlap
Cc: Andries.Brouwer, Dominik.Strasser, hch, linux-kernel, torvalds
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: headers
2003-08-18 21:57 ` headers Randy.Dunlap
2003-08-18 22:04 ` headers Jeff Garzik
@ 2003-08-18 22:17 ` Andries Brouwer
1 sibling, 0 replies; 7+ messages in thread
From: Andries Brouwer @ 2003-08-18 22:17 UTC (permalink / raw)
To: Randy.Dunlap
Cc: Andries.Brouwer, Dominik.Strasser, hch, jgarzik, linux-kernel, torvalds
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: headers
2003-08-18 19:07 headers Andries.Brouwer
2003-08-18 21:57 ` headers Randy.Dunlap
@ 2003-08-19 1:45 ` H. Peter Anvin
2003-08-19 12:55 ` headers Rob Landley
1 sibling, 1 reply; 7+ messages in thread
From: H. Peter Anvin @ 2003-08-19 1:45 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: headers
2003-08-19 1:45 ` headers H. Peter Anvin
@ 2003-08-19 12:55 ` Rob Landley
2003-08-19 15:45 ` headers Randy.Dunlap
0 siblings, 1 reply; 7+ messages in thread
From: Rob Landley @ 2003-08-19 12:55 UTC (permalink / raw)
To: H. Peter Anvin, linux-kernel; +Cc: Jeff Garzik
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: headers
2003-08-19 12:55 ` headers Rob Landley
@ 2003-08-19 15:45 ` Randy.Dunlap
0 siblings, 0 replies; 7+ messages in thread
From: Randy.Dunlap @ 2003-08-19 15:45 UTC (permalink / raw)
To: rob; +Cc: hpa, linux-kernel, jgarzik
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."
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2003-08-19 15:49 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-08-18 19:07 headers Andries.Brouwer
2003-08-18 21:57 ` headers Randy.Dunlap
2003-08-18 22:04 ` headers Jeff Garzik
2003-08-18 22:17 ` headers Andries Brouwer
2003-08-19 1:45 ` headers H. Peter Anvin
2003-08-19 12:55 ` headers Rob Landley
2003-08-19 15:45 ` headers Randy.Dunlap
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).