* Re: Linus's include file strategy redux
2000-12-15 14:21 ` Werner Almesberger
@ 2000-12-15 17:15 ` ferret
2000-12-15 17:46 ` Werner Almesberger
2000-12-15 18:10 ` LA Walsh
2000-12-15 19:35 ` Matt D. Robinson
2 siblings, 1 reply; 50+ messages in thread
From: ferret @ 2000-12-15 17:15 UTC (permalink / raw)
To: Werner Almesberger; +Cc: Alexander Viro, LA Walsh, lkml
On Fri, 15 Dec 2000, Werner Almesberger wrote:
> Alexander Viro wrote:
> > In the situation above they should have -I<wherever_the_tree_lives>/include
> > in CFLAGS. Always had to. No links, no pain in ass, no interference with
> > userland compiles.
>
> As long as there's a standard location for "<wherever_the_tree_lives>",
> this is fine. In most cases, the tree one expects to find is "roughly
> the kernel we're running". Actually, maybe a script to provide the
> path would be even better (*). Such a script could also complain if
> there's an obvious problem.
>
> I think there are three possible directions wrt visibility of kernel
> headers:
>
> - non at all - anything that needs kernel headers needs to provide them
> itself
> - kernel-specific extentions only; libc is self-contained, but user
> space can get items from .../include/linux (the current glibc
> approach)
> - share as much as possible; libc relies on kernel for "standard"
> definitions (the libc5 approach, and also reasonably feasible
> today)
>
> My personal preference is the third direction, because it simplifies the
> deployment of new "standard" elements, and changes to existing interfaces.
> The first direction would effectively discourage any new interfaces or
> changes to existing ones, while the second direction allows at least a
> moderate amount of flexibility for kernel-specific interfaces. In my
> experiments with newlib, I was largely able to use the third approach.
>
> I don't want to re-open the discussion on which way is better for glibc,
> but I think we can agree that "clean" kernel headers are always a good
> idea.
>
> So we get at least the following levels of visibility:
>
> 0) kernel-internal interfaces; should only be visible to "base" kernel
> 1) public kernel interfaces; should be visible to modules (exposing
> type 0 interfaces to modules may create ways to undermine the GPL)
> 2) interfaces to kernel-specific user space tools (modutils, mount,
> etc.); should be visible to user space that really wants them
> 3) interface to common non-POSIX extensions (BSD system calls, etc.);
> should be visible to user space on request, or on an opt-out basis
> 4) interfaces to POSIX elements (e.g. struct stat, mode_t); should be
> visible unconditionally (**)
>
> Distinguishing level 0 and 1 is always a little difficult. It seems
> that a "kmodcc" that inserts the necessary flags would be useful there
> (*). There needs to be a clear distinction between level 1 and 2 (the
> current #ifdef __KERNEL__). This boundary could certainly be improved
> be moving user-space-visible header files to a separate directory.
>
> Levels 2, 3, and 4 are more difficult to separate, because the people
> who know what should go where are not always the ones writing the
> kernel headers. Perhaps some more input from libc hackers could help.
>
> (*) Crude examples for such scripts (for newlib): newlib-flags and
> newlib-cc in
> ftp://icaftp.epfl.ch/pub/people/almesber/misc/newlib-linux/
> newlib-linux-20.tar.gz
>
> (**) Multiple versions of the interface can be a problem here, e.g.
> struct oldold_utsname vs. struct old_utsname vs.
> struct new_utsname. It would be nice to have them prefixed at
> least with __. Maybe a __LATEST_utsname macro would be useful
> too ;-) (I know, breaks binary compatibility, hence the
> smiley.)
>
> So ... what's the opinion on slowly introducing a redirection via
> scripts ?
Just out of curiosity, what would happen with redirection if your source
tree for 'the currently running kernel' version happens to be configured
for a different 'the currently running kernel', perhaps a machine of a
foreign arch that you are cross-compiling for?
I do this: I use ONE machine to compile kernels for five: four i386 and
one SUN4C. My other machines don't even HAVE /usr/src/linux, so where does
this redirection leave them?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-15 17:15 ` ferret
@ 2000-12-15 17:46 ` Werner Almesberger
2000-12-15 20:29 ` Joe deBlaquiere
0 siblings, 1 reply; 50+ messages in thread
From: Werner Almesberger @ 2000-12-15 17:46 UTC (permalink / raw)
To: ferret; +Cc: Alexander Viro, LA Walsh, lkml
ferret@phonewave.net wrote:
> Just out of curiosity, what would happen with redirection if your source
> tree for 'the currently running kernel' version happens to be configured
> for a different 'the currently running kernel', perhaps a machine of a
> foreign arch that you are cross-compiling for?
Two choices:
1) try to find an alternative. If there's none, fail.
2) make the corresponding asm or asm/arch branch available (non-trivial
and maybe not desirable)
> I do this: I use ONE machine to compile kernels for five: four i386 and
> one SUN4C. My other machines don't even HAVE /usr/src/linux, so where does
> this redirection leave them?
Depends on your distribution: if it doesn't install any kernel-specific
headers, you wouldn't be able to compile programs requiring anything
beyond what it provided by your libc. Otherwise, there could be a
default location (such as /usr/src/linux is a default location now).
The main advantage of a script would be that one could easily compile
for multiple kernels, e.g. with
export TARGET_KERNEL=2.0.4
make
Even if your system is running 2.4.13-test1.
The architecture could be obtained from the tree or the tree could be
picked based on the architecture. This is a policy decision that could
be hidden in the script.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: Linus's include file strategy redux
2000-12-15 17:46 ` Werner Almesberger
@ 2000-12-15 20:29 ` Joe deBlaquiere
2000-12-15 21:27 ` Werner Almesberger
0 siblings, 1 reply; 50+ messages in thread
From: Joe deBlaquiere @ 2000-12-15 20:29 UTC (permalink / raw)
To: Werner Almesberger; +Cc: ferret, Alexander Viro, LA Walsh, lkml
My solution to this has always been to make a cross compiler environment
(even if it is the same processor family). Thusly i386-linux-gcc knows
that the target system's include files are in:
/usr/local/<project>-tools/i386-linux/include (/linux, /asm)
The other advantage to this is that I can switch my host environment
(within reason - compatible host glibcs, ok) and not have to change the
target compiler.
Werner Almesberger wrote:
> ferret@phonewave.net wrote:
>
>> Just out of curiosity, what would happen with redirection if your source
>> tree for 'the currently running kernel' version happens to be configured
>> for a different 'the currently running kernel', perhaps a machine of a
>> foreign arch that you are cross-compiling for?
>
>
> Two choices:
> 1) try to find an alternative. If there's none, fail.
> 2) make the corresponding asm or asm/arch branch available (non-trivial
> and maybe not desirable)
>
>
>> I do this: I use ONE machine to compile kernels for five: four i386 and
>> one SUN4C. My other machines don't even HAVE /usr/src/linux, so where does
>> this redirection leave them?
>
>
> Depends on your distribution: if it doesn't install any kernel-specific
> headers, you wouldn't be able to compile programs requiring anything
> beyond what it provided by your libc. Otherwise, there could be a
> default location (such as /usr/src/linux is a default location now).
>
> The main advantage of a script would be that one could easily compile
> for multiple kernels, e.g. with
>
> export TARGET_KERNEL=2.0.4
> make
>
> Even if your system is running 2.4.13-test1.
>
> The architecture could be obtained from the tree or the tree could be
> picked based on the architecture. This is a policy decision that could
> be hidden in the script.
>
> - Werner
--
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax : (256)-837-3839
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-15 20:29 ` Joe deBlaquiere
@ 2000-12-15 21:27 ` Werner Almesberger
2000-12-15 22:58 ` Joe deBlaquiere
0 siblings, 1 reply; 50+ messages in thread
From: Werner Almesberger @ 2000-12-15 21:27 UTC (permalink / raw)
To: Joe deBlaquiere; +Cc: ferret, Alexander Viro, LA Walsh, lkml
Joe deBlaquiere wrote:
> My solution to this has always been to make a cross compiler environment
;-))) I think lots of people would really enjoy to have "build a
cross-gcc" added to the prerequisites for installing some driver
module ;-)
I know, it's not *that* bad. But it still adds quite a few possible
points of failure. Also, it adds a fair amount of overhead to any
directory name change or creation of a new kernel tree.
> The other advantage to this is that I can switch my host environment
> (within reason - compatible host glibcs, ok) and not have to change the
> target compiler.
Hmm, I don't quite understand what you mean here.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-15 21:27 ` Werner Almesberger
@ 2000-12-15 22:58 ` Joe deBlaquiere
2000-12-15 23:56 ` Werner Almesberger
2000-12-16 22:50 ` Peter Samuelson
0 siblings, 2 replies; 50+ messages in thread
From: Joe deBlaquiere @ 2000-12-15 22:58 UTC (permalink / raw)
To: Werner Almesberger; +Cc: ferret, Alexander Viro, LA Walsh, lkml
Werner Almesberger wrote:
> Joe deBlaquiere wrote:
>
>> My solution to this has always been to make a cross compiler environment
>
>
> ;-))) I think lots of people would really enjoy to have "build a
> cross-gcc" added to the prerequisites for installing some driver
> module ;-)
>
> I know, it's not *that* bad. But it still adds quite a few possible
> points of failure. Also, it adds a fair amount of overhead to any
> directory name change or creation of a new kernel tree.
>
might be a good newbie filter... but actually the best thing about it is
that the compiler people of the work might make generating a proper
cross-toolchain less difficult by one or two magnitudes...
>
>> The other advantage to this is that I can switch my host environment
>> (within reason - compatible host glibcs, ok) and not have to change the
>> target compiler.
>
>
> Hmm, I don't quite understand what you mean here.
>
This way I can upgrade my host system from RH6.2 to RH7 and not worry
about compiler differences affecting my kernel builds for the various
projects I'm working on... including systems based on 2.0, 2.2 and 2.4...
If anybody thinks gcc-2.96 messes up a 2.4 kernel, you should see what
happens when you compile 2.0.33 ;o).
> - Werner
--
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax : (256)-837-3839
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-15 22:58 ` Joe deBlaquiere
@ 2000-12-15 23:56 ` Werner Almesberger
2000-12-16 22:50 ` Peter Samuelson
1 sibling, 0 replies; 50+ messages in thread
From: Werner Almesberger @ 2000-12-15 23:56 UTC (permalink / raw)
To: Joe deBlaquiere; +Cc: lkml
Joe deBlaquiere wrote:
> but actually the best thing about it is
> that the compiler people of the work might make generating a proper
> cross-toolchain less difficult by one or two magnitudes...
You have a point here ... particularly gcc-glibc interdependencies are
a little irritating (not sure if they still cause build failures - they
were great fun in egcs-1.1b)
> This way I can upgrade my host system from RH6.2 to RH7 and not worry
> about compiler differences affecting my kernel builds for the various
> projects I'm working on... including systems based on 2.0, 2.2 and 2.4...
Ah, you mean you _do_ use a different compiler, but you _don't_ have to
change the compiler you normally invoke with "gcc" ? I see.
> If anybody thinks gcc-2.96 messes up a 2.4 kernel, you should see what
> happens when you compile 2.0.33 ;o).
I think a -Wall-as-of=2.7.2 might be convenient at times ;-)
- Werner (drifting off-topic :-( )
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-15 22:58 ` Joe deBlaquiere
2000-12-15 23:56 ` Werner Almesberger
@ 2000-12-16 22:50 ` Peter Samuelson
2000-12-17 0:04 ` Joe deBlaquiere
1 sibling, 1 reply; 50+ messages in thread
From: Peter Samuelson @ 2000-12-16 22:50 UTC (permalink / raw)
To: Joe deBlaquiere
Cc: Werner Almesberger, ferret, Alexander Viro, LA Walsh, lkml
[Joe deBlaquiere]
> might be a good newbie filter... but actually the best thing about it
> is that the compiler people of the work might make generating a
> proper cross-toolchain less difficult by one or two magnitudes...
*WHAT*? How much less difficult could it possibly get? This is the
kernel, there is no cross-libc to worry about, so a cross-toolchain is
already down to a pair of CMMIs[1].
I do agree that anyone who can't do *that* should probably be using a
distro-packaged kernel....
Peter
[1] configure-make-make-install
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-16 22:50 ` Peter Samuelson
@ 2000-12-17 0:04 ` Joe deBlaquiere
2000-12-17 2:05 ` Peter Samuelson
0 siblings, 1 reply; 50+ messages in thread
From: Joe deBlaquiere @ 2000-12-17 0:04 UTC (permalink / raw)
To: Peter Samuelson
Cc: Werner Almesberger, ferret, Alexander Viro, LA Walsh, lkml
Last I recall you have to at least have newlib around to get through the
build process of gcc. libgcc doesn't affect the kernel but you can't do
'make install' without building it.
BTW : The Linux newlib stuff should go a long way toward solving some of
these problems (at least for x86 these days... other arches sure to follow)
Peter Samuelson wrote:
> [Joe deBlaquiere]
>
>> might be a good newbie filter... but actually the best thing about it
>> is that the compiler people of the work might make generating a
>> proper cross-toolchain less difficult by one or two magnitudes...
>
>
> *WHAT*? How much less difficult could it possibly get? This is the
> kernel, there is no cross-libc to worry about, so a cross-toolchain is
> already down to a pair of CMMIs[1].
>
> I do agree that anyone who can't do *that* should probably be using a
> distro-packaged kernel....
>
> Peter
>
> [1] configure-make-make-install
--
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax : (256)-837-3839
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-17 0:04 ` Joe deBlaquiere
@ 2000-12-17 2:05 ` Peter Samuelson
0 siblings, 0 replies; 50+ messages in thread
From: Peter Samuelson @ 2000-12-17 2:05 UTC (permalink / raw)
To: Joe deBlaquiere
Cc: Werner Almesberger, ferret, Alexander Viro, LA Walsh, lkml
[Joe deBlaquiere]
> Last I recall you have to at least have newlib around to get through
> the build process of gcc. libgcc doesn't affect the kernel but you
> can't do 'make install' without building it.
Hmmm. I do not recall needing newlib or anything like it, last time I
built a cross-gcc+binutils. Perhaps it depends on the target arch. If
you pick one where the libgcc math functions haven't all been written
yet, you're probably right.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: Linus's include file strategy redux
2000-12-15 14:21 ` Werner Almesberger
2000-12-15 17:15 ` ferret
@ 2000-12-15 18:10 ` LA Walsh
2000-12-15 21:02 ` Miquel van Smoorenburg
` (2 more replies)
2000-12-15 19:35 ` Matt D. Robinson
2 siblings, 3 replies; 50+ messages in thread
From: LA Walsh @ 2000-12-15 18:10 UTC (permalink / raw)
To: Werner Almesberger, Alexander Viro; +Cc: lkml
> From: Werner Almesberger [mailto:Werner.Almesberger@epfl.ch]
>
> I think there are three possible directions wrt visibility of kernel
> headers:
>
> - non at all - anything that needs kernel headers needs to provide them
> itself
> - kernel-specific extentions only; libc is self-contained, but user
> space can get items from .../include/linux (the current glibc
> approach)
> - share as much as possible; libc relies on kernel for "standard"
> definitions (the libc5 approach, and also reasonably feasible
> today)
>
> So we get at least the following levels of visibility:
>
> 0) kernel-internal interfaces; should only be visible to "base" kernel
> 1) public kernel interfaces; should be visible to modules (exposing
> type 0 interfaces to modules may create ways to undermine the GPL)
> 2) interfaces to kernel-specific user space tools (modutils, mount,
> etc.); should be visible to user space that really wants them
> 3) interface to common non-POSIX extensions (BSD system calls, etc.);
> should be visible to user space on request, or on an opt-out basis
> 4) interfaces to POSIX elements (e.g. struct stat, mode_t); should be
> visible unconditionally (**)
---
The problem came in a case where I had a kernel module that included
standard memory allocation <linux/malloc.h>. That file, in turn, included
<linux/slab.h>, then that included <linux/mm.h> and <linux/cache.h>. From
there more and more files were included until it got down to files in
a kernel/kernel-module only directory "<include/kernel>". It was at that
point, the externally compiled module "barfed", because like many modules,
it expected, like many externally compiled modules, that it could simply
access all of it's needed files through /usr/include/linux which it gets
by putting /usr/include in it's path. I've seen commercial modules like
vmware's kernel modules use a similar system where they expect
/usr/include/linux to contain or point to headers for the currently running
kernel.
So I'm doing my compile in a 'chrooted' environment where the headers
for the new kernel are installed. However, now, with the new include/kernel
dir in the linux kernel, modules compiled separately out of the kernel
tree have no way of finding hidden kernel include files -- even though
those files may be needed for modules. Precisely -- in this case, "memory
allocation" for the kernel (not userland) was needed. Arguably, this
belongs(ed)
in a kernel-only directory. If that directory is not /usr/include/linux or
*under* /usr/include/linux, then modules need a separate way to find it --
namely a new link in /usr/include(<kernel>) to point to the new location,
or we move the internal kernel interfaces to something under the current
<include/linux> so while the intent of "kernel-only" is made clear, they
are still accessible in the way they already are, thus not requiring
rewrites
of all the existing makefiles.
I think in my specific case, perhaps, linux/malloc.h *is* a public
interface that is to be included by module writers and belongs in the
'public interface dir -- and that's great. But it includes files like
'slab.h' which are kernel mm-specific that may change in the future. Those
files should be in the private interface dir. But that dir may still need
to be included by public interface (malloc) file.
So the user should/needs to be blind to how that is handled. They
shouldn't have to change their makefiles or add new links just because
how 'malloc' implements its functionality changes. This would impy that
kernel only interfaces need to be include-able within the current
model -- just moved out of the existing "public-for-module" interface
directory (/usr/include/linux). For that to happen transparently, that
directory needs to exist under the current hierarchy (under
/usr/include/linux),
not parallel.
So at that point it becomes what we should name it under
/usr/include/linux. Should it be:
1) "/usr/include/linux/sys" (my preference)
2) "/usr/include/linux/kernel"
3) "/usr/include/linux/private"
4) "/usr/include/linux/kernel-only"
5) <other>
???
Any other solution, as I see it, would break existing module code.
Comments?? Any preferences from /dev/linus?
Any flaws in my logic chain?
tnx,
-linda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: Linus's include file strategy redux
2000-12-15 18:10 ` LA Walsh
@ 2000-12-15 21:02 ` Miquel van Smoorenburg
2000-12-16 4:04 ` ferret
2000-12-16 23:10 ` Peter Samuelson
2000-12-15 21:21 ` Werner Almesberger
2000-12-16 2:50 ` richard offer
2 siblings, 2 replies; 50+ messages in thread
From: Miquel van Smoorenburg @ 2000-12-15 21:02 UTC (permalink / raw)
To: linux-kernel
In article <NBBBJGOOMDFADJDGDCPHAENMCJAA.law@sgi.com>,
LA Walsh <law@sgi.com> wrote:
>It was at that
>point, the externally compiled module "barfed", because like many modules,
>it expected, like many externally compiled modules, that it could simply
>access all of it's needed files through /usr/include/linux which it gets
>by putting /usr/include in it's path. I've seen commercial modules like
>vmware's kernel modules use a similar system where they expect
>/usr/include/linux to contain or point to headers for the currently running
>kernel.
vmware asks you nicely
where are the running kernels include files [/usr/src/linux/include" >
And then compiles the modules with -I/path/to/include/files
In fact, the 2.2.18 kernel already puts a 'build' symlink in
/lib/modules/`uname -r` that points to the kernel source,
which should be sufficient to solve this problem.. almost.
It doesn't tell you the specific flags used to compile the kernel,
such as -m486 -DCPU=686
> So at that point it becomes what we should name it under
>/usr/include/linux. Should it be:
>1) "/usr/include/linux/sys" (my preference)
/usr should be static. It could be a read-only NFS mount.
Putting system dependant configuration info here (which a
/usr/include/linux/sys symlink *is*) is wrong.
I think /lib/modules/`uname -r`/ should contain a script that
reproduces the CFLAGS used to compile the kernel. That way,
you not only get the correct -I/path/to/kernel/include but
the other compile-time flags (like -m486 etc) as well.
# sh /lib/modules/`uname -r`/kconfig --cflags
-D__KERNEL__ -I/usr/src/linux-2.2.18pre24/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686
Standard module Makefile that will _always_ work:
#! /usr/bin/make -f
CC = $(shell /lib/modules/`uname -r`/kconfig --cc)
CFLAGS = $(shell /lib/modules/`uname -r`/kconfig --cflags)
module.o:
$(CC) $(CFLAGS) -c module.c
Flags could be:
--check Consistency check - are the header files there and
does include/linux/version.h match
--cc Outputs the CC variable used to compile the kernel
(important now that we have gcc, kgcc, gcc272)
--arch Outputs the ARCH variable
--cflags Outputs the CFLAGS
--include-path Outputs just the path to the include files
Generating and installing this 'kconfig' script as part of
"make modules_install" is trivial, and would solve all problems.
Well as far as I can see, ofcourse, I might have missed something..
Mike.
--
RAND USR 16514
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-15 21:02 ` Miquel van Smoorenburg
@ 2000-12-16 4:04 ` ferret
2000-12-16 11:09 ` Miquel van Smoorenburg
2000-12-16 23:10 ` Peter Samuelson
1 sibling, 1 reply; 50+ messages in thread
From: ferret @ 2000-12-16 4:04 UTC (permalink / raw)
To: Miquel van Smoorenburg; +Cc: linux-kernel
On 15 Dec 2000, Miquel van Smoorenburg wrote:
> In article <NBBBJGOOMDFADJDGDCPHAENMCJAA.law@sgi.com>,
> LA Walsh <law@sgi.com> wrote:
> >It was at that
> >point, the externally compiled module "barfed", because like many modules,
> >it expected, like many externally compiled modules, that it could simply
> >access all of it's needed files through /usr/include/linux which it gets
> >by putting /usr/include in it's path. I've seen commercial modules like
> >vmware's kernel modules use a similar system where they expect
> >/usr/include/linux to contain or point to headers for the currently running
> >kernel.
>
> vmware asks you nicely
>
> where are the running kernels include files [/usr/src/linux/include" >
>
> And then compiles the modules with -I/path/to/include/files
>
> In fact, the 2.2.18 kernel already puts a 'build' symlink in
> /lib/modules/`uname -r` that points to the kernel source,
> which should be sufficient to solve this problem.. almost.
>
> It doesn't tell you the specific flags used to compile the kernel,
> such as -m486 -DCPU=686
>
> > So at that point it becomes what we should name it under
> >/usr/include/linux. Should it be:
> >1) "/usr/include/linux/sys" (my preference)
>
> /usr should be static. It could be a read-only NFS mount.
> Putting system dependant configuration info here (which a
> /usr/include/linux/sys symlink *is*) is wrong.
>
> I think /lib/modules/`uname -r`/ should contain a script that
> reproduces the CFLAGS used to compile the kernel. That way,
> you not only get the correct -I/path/to/kernel/include but
> the other compile-time flags (like -m486 etc) as well.
[snip script]
However it happens, the necessary information THAT I KNOW OF is:
0) The kernel headers under linux/include
1) The state information generated by running make configure ; make dep ;
make clean -OR- equivalently by Debian's make-kpkg clean ; make-kpkg
configure which does the same thing but adds packaging-specific metadata.
A SYMLINK from /lib/modules/`uname -r`/ into /path/to/kernel-`uname -r`
will not always work, because:
0) The destination may not even exist (if the kernel has been installed
onto another machine)
1) The destination has no metadata or has the WRONG metadata (if I've just
compiled and installed 2.4.0-test11 on my i386, then am now building same
for my sun4c)
I have been recently told that a full copy of kernel headers and metadata
in /lib/modules/`uname -r`/ isn't going to work either, but the gentleman
who informed me of this hasn't yet shown why.
Debian's kernel package system allows for the creation of a kernel-headers
package which I THINK contains the correct metadata, but I've not
verified. This is placed into /usr/src/kernel-headers-`uname -r`/. This is
distro-specific but still A technically sound solution AFAIK. And not much
different than mentioned in the directly preceding paragraph.
Who else can offer an alternative solution, to the specific problem of
making configured KERNEL headers available for building third-party
modules?
--Ferret
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-16 4:04 ` ferret
@ 2000-12-16 11:09 ` Miquel van Smoorenburg
2000-12-16 17:20 ` ferret
0 siblings, 1 reply; 50+ messages in thread
From: Miquel van Smoorenburg @ 2000-12-16 11:09 UTC (permalink / raw)
To: linux-kernel
In article <Pine.LNX.3.96.1001215194935.19208D-100000@tarot.mentasm.org>,
<ferret@phonewave.net> wrote:
>On 15 Dec 2000, Miquel van Smoorenburg wrote:
>
>> I think /lib/modules/`uname -r`/ should contain a script that
>> reproduces the CFLAGS used to compile the kernel.
>
>However it happens, the necessary information THAT I KNOW OF is:
>0) The kernel headers under linux/include
>1) The state information generated by running make configure ; make dep ;
>make clean -OR- equivalently by Debian's make-kpkg clean ; make-kpkg
>configure which does the same thing but adds packaging-specific metadata.
That state info is in ARCH, CFLAGS, CC and include/linux/autoconf.h
>A SYMLINK from /lib/modules/`uname -r`/ into /path/to/kernel-`uname -r`
>will not always work, because:
>0) The destination may not even exist (if the kernel has been installed
>onto another machine)
Yes but in that case, how are you going to compile a module without
the kernel headers anyway. If you compiled a kernel on one
machine and you know that you want to be able to compile modules
on the second machine you need to copy over /usr/src/linux-x.y.z/include
as well.
>1) The destination has no metadata or has the WRONG metadata (if I've just
>compiled and installed 2.4.0-test11 on my i386, then am now building same
>for my sun4c)
As I said the kconfig script should do some simple sanity checks-
compare version and architecture at least.
>I have been recently told that a full copy of kernel headers and metadata
>in /lib/modules/`uname -r`/ isn't going to work either, but the gentleman
>who informed me of this hasn't yet shown why.
Because lots of use have a small root file system of just 30 MB ?
Hmm, but as soon as you start thinking about cross-compiles etc
you need more and more state - like CROSS_COMPILE, AS, LD, CPP, AR,
NM etc etc. Yuck. It would probably be better to put all that info
in /usr/src/linux/Config.make, and use the current "build" symlink.
A module makefile would then look like this:
#! /usr/bin/make -f
# You might want to point BUILD somewhere else.
BUILD = /lib/modules/$(shell uname -r)/build
include $(BUILD)/Config.make
module.o:
$(CC) $(CFLAGS) -c module.c
Ah yes, this is probably a much better approach then a kconfig script
Mike.
--
RAND USR 16514
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-16 11:09 ` Miquel van Smoorenburg
@ 2000-12-16 17:20 ` ferret
2000-12-17 0:21 ` J . A . Magallon
0 siblings, 1 reply; 50+ messages in thread
From: ferret @ 2000-12-16 17:20 UTC (permalink / raw)
To: Miquel van Smoorenburg; +Cc: linux-kernel
On 16 Dec 2000, Miquel van Smoorenburg wrote:
> In article <Pine.LNX.3.96.1001215194935.19208D-100000@tarot.mentasm.org>,
> <ferret@phonewave.net> wrote:
> >On 15 Dec 2000, Miquel van Smoorenburg wrote:
> >
> >> I think /lib/modules/`uname -r`/ should contain a script that
> >> reproduces the CFLAGS used to compile the kernel.
> >
> >However it happens, the necessary information THAT I KNOW OF is:
> >0) The kernel headers under linux/include
> >1) The state information generated by running make configure ; make dep ;
> >make clean -OR- equivalently by Debian's make-kpkg clean ; make-kpkg
> >configure which does the same thing but adds packaging-specific metadata.
>
> That state info is in ARCH, CFLAGS, CC and include/linux/autoconf.h
Ah, thank you for resolving the state information for me. =)
> >A SYMLINK from /lib/modules/`uname -r`/ into /path/to/kernel-`uname -r`
> >will not always work, because:
> >0) The destination may not even exist (if the kernel has been installed
> >onto another machine)
>
> Yes but in that case, how are you going to compile a module without
> the kernel headers anyway. If you compiled a kernel on one
> machine and you know that you want to be able to compile modules
> on the second machine you need to copy over /usr/src/linux-x.y.z/include
> as well.
My point was that this symlink makes an assumption that is not always
valid. And assuming things that are not always valid (opposing to things
that do not always exist) is generally Wrong.
> >1) The destination has no metadata or has the WRONG metadata (if I've just
> >compiled and installed 2.4.0-test11 on my i386, then am now building same
> >for my sun4c)
>
> As I said the kconfig script should do some simple sanity checks-
> compare version and architecture at least.
>
> >I have been recently told that a full copy of kernel headers and metadata
> >in /lib/modules/`uname -r`/ isn't going to work either, but the gentleman
> >who informed me of this hasn't yet shown why.
>
> Because lots of use have a small root file system of just 30 MB ?
Yes, yes. Very good point. So (as I was thinking this morning as I awoke)
the symlink could stay, IF it could be guarenteed not to be dangling on
the target machine. I suspect making the symlink should therefore be left
to the administrator or local package manager.
We still can say that IF the symlink exists and is not dangling, that
third-party modules source MAY ASSUME it points to headers configured for
the running kernel. But the kernel build process SHOULD NOT make the
symlink.
> Hmm, but as soon as you start thinking about cross-compiles etc
> you need more and more state - like CROSS_COMPILE, AS, LD, CPP, AR,
> NM etc etc. Yuck. It would probably be better to put all that info
> in /usr/src/linux/Config.make, and use the current "build" symlink.
> A module makefile would then look like this:
>
> #! /usr/bin/make -f
>
> # You might want to point BUILD somewhere else.
> BUILD = /lib/modules/$(shell uname -r)/build
> include $(BUILD)/Config.make
>
> module.o:
> $(CC) $(CFLAGS) -c module.c
>
> Ah yes, this is probably a much better approach then a kconfig script
s/better/simpler/
A kconfig script will of course need to override BUILD in certain cases,
but with make this is trivial.
This solves one specific outstanding issue, and IMO at first glance before
my first cup of coffee should solve it well. But a kconfig script is meant
to do many other things as well. Some of these other things are big enough
to be held until 2.5.0, and are mentioned in another post.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-16 17:20 ` ferret
@ 2000-12-17 0:21 ` J . A . Magallon
0 siblings, 0 replies; 50+ messages in thread
From: J . A . Magallon @ 2000-12-17 0:21 UTC (permalink / raw)
To: linux-kernel
Lets try another scenario (from user point of view)
Ship kernel sources split in kernel-headers-2.2.18(tar.bz2,rpm,deb) and
kernel-source-2.2.18, and a binary kernel-2.2.18
One user not doing kernel compiles, but with various installed
kernels to try has:
/usr/include/kernel-2.2.18
/usr/include/kernel-2.4.0
/usr/include/kernel -> kernel-2.2.18 (setup at boot-init scripts
with uname -r)
User can compile userspace apps and test kernel modules including
/usr/include/kernel. If glibc is kernel independent, glibc headers
just include 'kernel'. If it is kernel dependent, include
'kernel-x.y.z'.
User rebuilding kernel: kernel-source-x.y.z always look at
/usr/include/kernel-x.y.z, not just kernel.
A developer building a patched kernel that does not change headers
can manually do
/usr/include/kernel-2.2.18-my-pre -> /usr/include/kernel-2.2.18
If he need to change headers, dup include tree.
--
Juan Antonio Magallon Lacarta #> cd /pub
mailto:jamagallon@able.es #> more beer
Linux werewolf 2.2.19-pre1 #1 SMP Fri Dec 15 22:25:20 CET 2000 i686
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-15 21:02 ` Miquel van Smoorenburg
2000-12-16 4:04 ` ferret
@ 2000-12-16 23:10 ` Peter Samuelson
2000-12-17 1:15 ` Miquel van Smoorenburg
1 sibling, 1 reply; 50+ messages in thread
From: Peter Samuelson @ 2000-12-16 23:10 UTC (permalink / raw)
To: Miquel van Smoorenburg; +Cc: linux-kernel
[Miquel van Smoorenburg]
> In fact, the 2.2.18 kernel already puts a 'build' symlink in
> /lib/modules/`uname -r` that points to the kernel source,
> which should be sufficient to solve this problem.. almost.
>
> It doesn't tell you the specific flags used to compile the kernel,
> such as -m486 -DCPU=686
Sure it does.
make -C /lib/modules/`uname -r`/build modules SUBDIRS=$(pwd)
or, if you like clumsy and slow:
SRCDIR := /lib/modules/`uname -r`/build
CFLAGS := $(shell $(MAKE) -s -C $(SRCDIR) script SCRIPT='echo $$$$CFLAGS')
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-16 23:10 ` Peter Samuelson
@ 2000-12-17 1:15 ` Miquel van Smoorenburg
2000-12-17 2:18 ` Peter Samuelson
0 siblings, 1 reply; 50+ messages in thread
From: Miquel van Smoorenburg @ 2000-12-17 1:15 UTC (permalink / raw)
To: linux-kernel
In article <20001216171000.L3199@cadcamlab.org>,
Peter Samuelson <peter@cadcamlab.org> wrote:
>[Miquel van Smoorenburg]
>> In fact, the 2.2.18 kernel already puts a 'build' symlink in
>> /lib/modules/`uname -r` that points to the kernel source,
>> which should be sufficient to solve this problem.. almost.
>>
>> It doesn't tell you the specific flags used to compile the kernel,
>> such as -m486 -DCPU=686
>
>Sure it does.
>
> make -C /lib/modules/`uname -r`/build modules SUBDIRS=$(pwd)
Excellent. Is there any way to put his in a Makefile?
Mike.
--
RAND USR 16514
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-17 1:15 ` Miquel van Smoorenburg
@ 2000-12-17 2:18 ` Peter Samuelson
0 siblings, 0 replies; 50+ messages in thread
From: Peter Samuelson @ 2000-12-17 2:18 UTC (permalink / raw)
To: Miquel van Smoorenburg; +Cc: linux-kernel
[Peter Samuelson]
> > make -C /lib/modules/`uname -r`/build modules SUBDIRS=$(pwd)
[Miquel van Smoorenburg]
> Excellent. Is there any way to put his in a Makefile?
I don't know why not. Here's what I would start with:
PWD := $(shell pwd)
KERNEL := /lib/modules/$(shell uname -r)/build
CALLMAKE = $(MAKE) -C $(KERNEL) SUBDIRS=$(PWD)
all:
# ...other stuff...
$(CALLMAKE) modules
install:
# ...other stuff...
$(CALLMAKE) modules_install
# ...other stuff...
include $(TOPDIR)/Rules.make
Not *quite* that simple, but it's a start. Note that with this
construction you let the savvy user override $(KERNEL) at the command
line. (I, for one, would insist.)
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-15 18:10 ` LA Walsh
2000-12-15 21:02 ` Miquel van Smoorenburg
@ 2000-12-15 21:21 ` Werner Almesberger
2000-12-15 21:36 ` LA Walsh
2000-12-15 22:48 ` J . A . Magallon
2000-12-16 2:50 ` richard offer
2 siblings, 2 replies; 50+ messages in thread
From: Werner Almesberger @ 2000-12-15 21:21 UTC (permalink / raw)
To: LA Walsh; +Cc: Alexander Viro, lkml
LA Walsh wrote:
> I think in my specific case, perhaps, linux/malloc.h *is* a public
> interface that is to be included by module writers and belongs in the
> 'public interface dir -- and that's great. But it includes files like
> 'slab.h' which are kernel mm-specific that may change in the future.
As far as I understand the scenario you're describing, this seems to
be the only problem. <public>/malloc.h shouldn't need to include
<private>/slab.h.
If there's anything <private>/slab.h provides (either directly or
indirectly) that is needed in <public>/malloc.h, that should either be
in another public header, or malloc.h actually shouldn't depend on it.
Exception: opaque types; there one would have to go via a __ identifier,
i.e.
<public>/foo.h defines struct __foo ...;
<public>/bar.h includes <public>/foo.h
and uses #define FOOSIZE sizeof(struct __foo)
<private>/foo.h either typedef struct __foo foo_t;
or #define foo __foo /* ugly */
Too bad there's no typedef struct __foo struct foo;
I don't think restructuring the headers in this way would cause
a long period of instability. The main problem seems to be to
decide what is officially private and what isn't.
> Any other solution, as I see it, would break existing module code.
Hmm, I think what I've outlined above wouldn't break more code than
your approach. Obviously, modiles currently using "private" interfaces
are in trouble either way.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread* RE: Linus's include file strategy redux
2000-12-15 21:21 ` Werner Almesberger
@ 2000-12-15 21:36 ` LA Walsh
2000-12-15 22:48 ` J . A . Magallon
1 sibling, 0 replies; 50+ messages in thread
From: LA Walsh @ 2000-12-15 21:36 UTC (permalink / raw)
To: Werner Almesberger; +Cc: lkml
> From: Werner Almesberger [mailto:Werner.Almesberger@epfl.ch]
> Sent: Friday, December 15, 2000 1:21 PM
> I don't think restructuring the headers in this way would cause
> a long period of instability. The main problem seems to be to
> decide what is officially private and what isn't.
---
If someone wants to restructure headers, that's fine. I was only
trying to understand the confusingly stated intentions of Linus. I
was attempting to fit into those intentions, not change the world.
> > Any other solution, as I see it, would break existing module code.
>
> Hmm, I think what I've outlined above wouldn't break more code than
> your approach. Obviously, modiles currently using "private" interfaces
> are in trouble either way.
---
You've misunderstood. My approach would break *nothing*.
If module-public include file includes a private, it would still
work since 'sys' would be a directory under 'include/linux'. No new
links need be added, needed or referenced. Thus nothing breaks.
-l
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-15 21:21 ` Werner Almesberger
2000-12-15 21:36 ` LA Walsh
@ 2000-12-15 22:48 ` J . A . Magallon
2000-12-15 23:47 ` Werner Almesberger
2000-12-16 4:11 ` ferret
1 sibling, 2 replies; 50+ messages in thread
From: J . A . Magallon @ 2000-12-15 22:48 UTC (permalink / raw)
To: Werner Almesberger; +Cc: LA Walsh, Alexander Viro, lkml
On 2000/12/15 Werner Almesberger wrote:
> LA Walsh wrote:
>
> Exception: opaque types; there one would have to go via a __ identifier,
> i.e.
>
> <public>/foo.h defines struct __foo ...;
> <public>/bar.h includes <public>/foo.h
> and uses #define FOOSIZE sizeof(struct __foo)
> <private>/foo.h either typedef struct __foo foo_t;
> or #define foo __foo /* ugly */
>
Easier: public kernel interfaces only work through pointers.
<public>/foo.h typedef struct foo foo_t;
foo_t* foo_new();
<private>/foo.h includes <public>/foo.h
struct foo { ............... };
and uses #define FOOSIZE sizeof(foo_t)
Drawback: public access is slow (always through foo_set_xxxx_field(foo_t*))
private access from kernel or modules is fast (foo_t->x = ...)
Advantage: kernel can change, foo_t internals can change and it is binary
compatible. Even public headers can be kernel version
independent.
Too kind-of-classroom-not-real-world-useless-thing ?
All depends on public access needing full fast paths...
--
Juan Antonio Magallon Lacarta #> cd /pub
mailto:jamagallon@able.es #> more beer
Linux werewolf 2.2.19-pre1 #1 SMP Fri Dec 15 22:25:20 CET 2000 i686
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: Linus's include file strategy redux
2000-12-15 22:48 ` J . A . Magallon
@ 2000-12-15 23:47 ` Werner Almesberger
2000-12-16 4:11 ` ferret
1 sibling, 0 replies; 50+ messages in thread
From: Werner Almesberger @ 2000-12-15 23:47 UTC (permalink / raw)
To: J . A . Magallon; +Cc: lkml
J . A . Magallon wrote:
> Easier: public kernel interfaces only work through pointers.
Requires more elaborate wrappers or a new layer of wrapper functions
around system calls, if you want to make this completely general.
Also, doesn't provide FOOSIZE to "public" space.
> Too kind-of-classroom-not-real-world-useless-thing ?
I'm afraid so ...
I don't think there are many opaque types where there's no trival
solution. Actually, I don't think there are many opaque types at
kernel APIs to start with. The one I know offhand is atm_kptr_t
in include/linux/atmapi.h, in this case, there's little risk in
exposing the internal structure.
So I'd consider opaque types more as a hypothetical obstacle.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-15 22:48 ` J . A . Magallon
2000-12-15 23:47 ` Werner Almesberger
@ 2000-12-16 4:11 ` ferret
1 sibling, 0 replies; 50+ messages in thread
From: ferret @ 2000-12-16 4:11 UTC (permalink / raw)
To: J . A . Magallon; +Cc: Werner Almesberger, LA Walsh, Alexander Viro, lkml
On Fri, 15 Dec 2000, J . A . Magallon wrote:
>
> On 2000/12/15 Werner Almesberger wrote:
> > LA Walsh wrote:
> >
> > Exception: opaque types; there one would have to go via a __ identifier,
> > i.e.
> >
> > <public>/foo.h defines struct __foo ...;
> > <public>/bar.h includes <public>/foo.h
> > and uses #define FOOSIZE sizeof(struct __foo)
> > <private>/foo.h either typedef struct __foo foo_t;
> > or #define foo __foo /* ugly */
> >
>
> Easier: public kernel interfaces only work through pointers.
> <public>/foo.h typedef struct foo foo_t;
> foo_t* foo_new();
> <private>/foo.h includes <public>/foo.h
> struct foo { ............... };
> and uses #define FOOSIZE sizeof(foo_t)
>
> Drawback: public access is slow (always through foo_set_xxxx_field(foo_t*))
> private access from kernel or modules is fast (foo_t->x = ...)
> Advantage: kernel can change, foo_t internals can change and it is binary
> compatible. Even public headers can be kernel version
> independent.
I think collectively we're mixing what should really be two seperate but
related issues: userland interface from /usr/include/linux; and exported
kernel header interface for third-party modules.
>From a first reading, your Drawback: appears to belong to the sphere of
kernel interface, and your Advantage: to the sphere of userland interface.
But on the second reading (after opening a bottle of Jones) I can see how
the Advantage: would apply to both spheres.
I'm just asking that people please try to be a little more precise with
the rather imprecise list language.
--Ferret
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-15 18:10 ` LA Walsh
2000-12-15 21:02 ` Miquel van Smoorenburg
2000-12-15 21:21 ` Werner Almesberger
@ 2000-12-16 2:50 ` richard offer
2 siblings, 0 replies; 50+ messages in thread
From: richard offer @ 2000-12-16 2:50 UTC (permalink / raw)
To: linux-kernel
In article <91e0vj$b6alr$1@fido.engr.sgi.com> you write:
>In article <NBBBJGOOMDFADJDGDCPHAENMCJAA.law@sgi.com>,
>LA Walsh <law@sgi.com> wrote:
>>It was at that
>>point, the externally compiled module "barfed", because like many modules,
>>it expected, like many externally compiled modules, that it could simply
>>access all of it's needed files through /usr/include/linux which it gets
>>by putting /usr/include in it's path. I've seen commercial modules like
>>vmware's kernel modules use a similar system where they expect
>>/usr/include/linux to contain or point to headers for the currently running
>>kernel.
>
>vmware asks you nicely
>
>where are the running kernels include files [/usr/src/linux/include" >
>
>And then compiles the modules with -I/path/to/include/files
>
>In fact, the 2.2.18 kernel already puts a 'build' symlink in
>/lib/modules/`uname -r` that points to the kernel source,
>which should be sufficient to solve this problem.. almost.
Don't get me started on that... The link points back to where the code
was when it was built, not where it is installed. This makes a difference
if you're building RPMs... in which case the link points back to (for
example) /usr/src/sgi/BUILD/linux-<version> and not
/usr/src/linux-<version>/.
And, top it all... once the build is completed the BUILD directory
is deleted.
Good Idea, but poorly thought out.
>I think /lib/modules/`uname -r`/ should contain a script that
>reproduces the CFLAGS used to compile the kernel. That way,
>you not only get the correct -I/path/to/kernel/include but
>the other compile-time flags (like -m486 etc) as well.
Anything that uses uname to work out what kernel is running doesn't work
if you're in a chrooted environment. Symlinks work better for this...if
all fails you can manage them manually during the build...
[ changeling 2.2.15-#5 ] uname -r
2.2.15-3SGI_39
[ changeling 2.2.15-#5 ] echo $ROOT
/work/root
[ changeling 2.2.15-#5 ] sudo chroot $ROOT
[ changeling 2.2.15-#5 ] uname -r
2.2.15-3SGI_39
[ changeling 2.2.15-#5 ] rpm -qa | grep kernel
kernel-headers-2.2.16-3
kernel-2.2.16-3
Trust me, $ROOT does not include 2.2.15....
>Mike.
richard.
-----------------------------------------------------------------------
Richard Offer Widget FAQ --> http://reality.sgi.com/widgetFAQ/
{X,Motif,Trust} on {Irix,Linux}
__________________________________________http://reality.sgi.com/offer/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-15 14:21 ` Werner Almesberger
2000-12-15 17:15 ` ferret
2000-12-15 18:10 ` LA Walsh
@ 2000-12-15 19:35 ` Matt D. Robinson
2000-12-15 21:36 ` Werner Almesberger
2 siblings, 1 reply; 50+ messages in thread
From: Matt D. Robinson @ 2000-12-15 19:35 UTC (permalink / raw)
To: Werner Almesberger; +Cc: Alexander Viro, LA Walsh, lkml
Werner Almesberger wrote:
>
> Alexander Viro wrote:
> > In the situation above they should have -I<wherever_the_tree_lives>/include
> > in CFLAGS. Always had to. No links, no pain in ass, no interference with
> > userland compiles.
>
> As long as there's a standard location for "<wherever_the_tree_lives>",
> this is fine. In most cases, the tree one expects to find is "roughly
> the kernel we're running". Actually, maybe a script to provide the
> path would be even better (*). Such a script could also complain if
> there's an obvious problem.
I personally think the definition of an environment variable to point to
a header file location is the right way to go. Same with tools -- that
way I can say build with $(TOOLDIR), which pulls whatever tools that
tree uses, and use $(INCDIR) as my kernel include files.
Then you can build using whatever header files you want to use, using
whatever compilers/linkers/whatever you want to. So:
TOOLDIR=/src/gcctree
INCDIR=/src/2.2.18
or:
TOOLDIR=/src/egcstree
INCDIR=/src/2.4.0-test12-custom
Then a 'make' from my $(TOPDIR) builds everything with the tools in
$(TOOLDIR) and uses -I$(INCDIR) for header files. It's a beautiful
thing.
--Matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Linus's include file strategy redux
2000-12-15 19:35 ` Matt D. Robinson
@ 2000-12-15 21:36 ` Werner Almesberger
0 siblings, 0 replies; 50+ messages in thread
From: Werner Almesberger @ 2000-12-15 21:36 UTC (permalink / raw)
To: Matt D. Robinson; +Cc: Alexander Viro, LA Walsh, lkml
Matt D. Robinson wrote:
> I personally think the definition of an environment variable to point to
> a header file location is the right way to go.
I see two disadvantages of this, compared to a script:
- need to hard-code a default (unless we assume the variables are always
set)
- the way how environment variables are propagated
A script-based approach has the advantage that one can make a single
change (to a file) that instantly affects the whole local environment
(be this system-wide, per-user, or whatever). So there's no risk of
typing "make" to that forgotten xterm and an incompatible build
starts.
I like environment variables as a means to override auto-detected
defaults, though.
Also, environment variables don't solve the problem of conveniently
providing other compiler arguments (the kmodcc idea - the problem is
very old, but I think it's still not solved).
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread