In article >[email protected]>,
H. Peter Anvin <[email protected]> wrote:
>Followup to: <[email protected]>
>By author: [email protected] (Miquel van Smoorenburg)
>In newsgroup: linux.dev.kernel
>> Why? As I said you can use a glue layer. Note that you still
>> cannot mix /usr/include/net and /usr/src/linux/include/net anyway,
>> so clashes will always exist with the current system.
>> I agree it should probably be fixed.
>A GLUE LAYER IS FREQUENTLY NOT AN OPTION,
No need to shout, I did say I agreed with you ;)
>because you have no data
>types to carry around the semantic contents in. You really *DO* need
>to mix both types.
Yes. So it should be fixed, right? Perhaps in 2.5 then we should
- moving kernel headers around: linux/include now contains
To make sure we _can_ use libc headers and kernel headers we must
eliminate clashes. linux/include/net isn't the same as /usr/include/net,
same goes for /usr/include/scsi etc. So it's probably best to move
everything one level to:
o linux/kernel/*.h (this was most of linux/*.h)
o linux/public/*.h (contains public interfaces to the kernel)
Hmm, perhaps that is not nessecary. If we're going to have a
linux/public hierarchy, you wouldn't need the rest of the
headers anyway, so they don't need to be moved. Cool ;)
- We need a script in /lib/modules/version/kernel-config that prints
the CFLAGS used to compile that kernel on stdout to compile modules.
Now, I think that all of this has been mentioned before on this
list, those are not completely my ideas. Somebody mentioned marking
structures/defines/etc that need to be exported with a special
comment so that a script could generate a set of headers with the
public interfaces. That is about the same as the public/ idea,
and perhaps a bit easier, since it wouldn't annoy the hell out
of all those device driver writers that see the interface change again..
Cistron Certified Internetwork Expert #1. Think free speech; drink free beer.