[richard offer]
> Or userland libraries/applications that need to bypass libc and make
> direct kernel calls because libc hasn't yet implemented those new
> kernel calls.
Nah, it's still error-prone because it's too hard to guarantee that the
user compiling your program has up-to-date kernel hea
In article <91gr99$bs81o$[EMAIL PROTECTED]> you write:
>
>[Dana Lacoste]
>> Essentially, whatever solution is implemented MUST ensure :
>>
>> 1 - glibc will work properly (the headers in /usr/include/* don't
>> change in an incompatible manner)
>>
>> 2 - programs that need to compile against
On Mon, Dec 18, 2000 at 10:51:09AM -0500, Dana Lacoste wrote:
>
> Can we get a #3 going? I think it could really help both the cross-compile
> people and those who just want to make sure their modules are compiling in
> the 'correct' environment. It also allows for things like 'kgcc vs. gcc' to
On Sun, 17 Dec 2000, Peter Samuelson wrote:
>
> [[EMAIL PROTECTED]]
> > One last question: WHY is the kernel's top-level Makefile handling
> > this symlink?
>
> Where do you think it should be handled? 'make modules_install' seems
> like the most logical place, to me.
I think making the sym
[Dana Lacoste]
> - I write an external/third party kernel module
> - For various reasons, I must have this kernel module installed to boot
> (i can't compile without my module running)
In that case "compile script for dummies" will probably fail anyway.
If you need it to boot, you probably nee
On 18 Dec 00 at 10:51, Dana Lacoste wrote:
> Potential answers that have come up so far :
> 1 - /lib/modules/* directories that involve `uname -r`
> This won't work because i might not be compiling for the `uname -r` kernel
> 2 - /lib/modules//build/include/ :
> we could recommend that all
"Peter Samuelson" <[EMAIL PROTECTED]> wrote :
> [Dana Lacoste]
> > 2 - programs that need to compile against the current kernel MUST
> > be able to do so in a quasi-predictable manner.
> (2) is bogus. NO program needs to compile against the current kernel
> headers. The only things that nee
[[EMAIL PROTECTED]]
> One last question: WHY is the kernel's top-level Makefile handling
> this symlink?
Where do you think it should be handled? 'make modules_install' seems
like the most logical place, to me.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Sun, 17 Dec 2000, Peter Samuelson wrote:
>
> [[EMAIL PROTECTED] <[EMAIL PROTECTED]>]
> > I have not moved or deleted a tree. I do not HAVE a kernel tree in
> > the first place. Therefore, nothing for the symlink to point to when
> > I install the kernel.
>
> If this is not the machine you
[[EMAIL PROTECTED] <[EMAIL PROTECTED]>]
> I have not moved or deleted a tree. I do not HAVE a kernel tree in
> the first place. Therefore, nothing for the symlink to point to when
> I install the kernel.
If this is not the machine you compile your kernels on, why are you
compiling your external
On Sat, 16 Dec 2000, Peter Samuelson wrote:
>
> [[EMAIL PROTECTED]]
> > Do you have an alternative reccomendation? I've shown where the
> > symlink method WILL fail. You disagree that having the configured
> > headers copied is a workable idea. What else is there?
>
> 4.5 more megabytes, per
[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
[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+bi
In article <[EMAIL PROTECTED]>,
Peter Samuelson <[EMAIL PROTECTED]> 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
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/k
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 d
[[EMAIL PROTECTED]]
> Do you have an alternative reccomendation? I've shown where the
> symlink method WILL fail. You disagree that having the configured
> headers copied is a workable idea. What else is there?
4.5 more megabytes, per kernel, on my root filesystem. (That's *after*
pruning the e
[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
[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
ker
[Dana Lacoste]
> Essentially, whatever solution is implemented MUST ensure :
>
> 1 - glibc will work properly (the headers in /usr/include/* don't
> change in an incompatible manner)
>
> 2 - programs that need to compile against the current kernel MUST
> be able to do so in a quasi-pred
On 16 Dec 2000, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> 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.
> >
> >How
On Sat, 16 Dec 2000, Keith Owens wrote:
> On Fri, 15 Dec 2000 19:37:49 -0800 (PST),
> [EMAIL PROTECTED] wrote:
> >Do you have an alternative reccomendation? I've shown where the symlink
> >method WILL fail. You disagree that having the configured headers copied
> >is a workable idea. What else
[EMAIL PROTECTED] (Alan Cox) writes:
> > >Which works because in a normal compile environment they have /usr/include
> > >in their include path and /usr/include/linux points to the directory
> > >under /usr/src/linux/include.
> >
> > No, that a redhat-ism.
>
> Umm, its a most people except Debi
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> 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)
On Fri, 15 Dec 2000, richard offer wrote:
>
> * $ from [EMAIL PROTECTED] at "15-Dec: 8:22pm" | sed "1,$s/^/* /"
> *
> *
> * Once again, I'd like to suggest Debian's kernel package system as a good
> * working example of this sort of administrative-level kernel management. I
> * brought this up
On Fri, 15 Dec 2000 19:37:49 -0800 (PST),
[EMAIL PROTECTED] wrote:
>Do you have an alternative reccomendation? I've shown where the symlink
>method WILL fail. You disagree that having the configured headers copied
>is a workable idea. What else is there?
Use the pcmcia-cs method. Ask where the
On Fri, 15 Dec 2000, richard offer wrote:
> In article <91e0vj$b6alr$[EMAIL PROTECTED]> you write:
> >In article <[EMAIL PROTECTED]>,
> >LA Walsh <[EMAIL PROTECTED]> wrote:
> >>It was at that
> >>point, the externally compiled module "barfed", because like many modules,
> >>it expected, like ma
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.
> >
> > /foo.h defines struct __foo ...;
> > /bar.h includes /foo.h
> >and u
On 15 Dec 2000, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> LA Walsh <[EMAIL PROTECTED]> 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
> >ac
On Fri, 15 Dec 2000, Ingo Oeser wrote:
> On Fri, Dec 15, 2000 at 09:31:57AM -0800, [EMAIL PROTECTED] wrote:
> > > Maybe you did not notice, but for months we have
> > > /lib/modules/`uname -r`/build/include, which points to kernel headers,
> > > and which should be used for compiling out-of-tre
In article <91e0vj$b6alr$[EMAIL PROTECTED]> you write:
>In article <[EMAIL PROTECTED]>,
>LA Walsh <[EMAIL PROTECTED]> 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
>>ac
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 sur
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-n
On Fri, 15 Dec 2000, Dana Lacoste wrote:
> We really need a documented way to deal with this! It's getting silly
> the number of questions that people ask!
Please, that would be helpful - I'm still using a heavily mutated
slackware 3.1 that's been hacked up to the same level (if not beyond) as
R
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,
On 2000/12/15 Werner Almesberger wrote:
> LA Walsh wrote:
>
> Exception: opaque types; there one would have to go via a __ identifier,
> i.e.
>
> /foo.h defines struct __foo ...;
> /bar.h includes /foo.h
>and uses #define FOOSIZE sizeof(struct __foo)
> /foo.h either typedef st
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 h
> From: Werner Almesberger [mailto:[EMAIL PROTECTED]]
> 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 someo
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
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 f
In article <[EMAIL PROTECTED]>,
LA Walsh <[EMAIL PROTECTED]> 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 whic
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/-tools/i386-linux/include (/linux, /asm)
The other advantage to this is that I can switch my
Werner Almesberger wrote:
>
> Alexander Viro wrote:
> > In the situation above they should have -I/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 "",
> this is fine. In most cases, the tre
> From: Werner Almesberger [mailto:[EMAIL PROTECTED]]
>
> 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
On Fri, Dec 15, 2000 at 09:31:57AM -0800, [EMAIL PROTECTED] wrote:
> > Maybe you did not notice, but for months we have
> > /lib/modules/`uname -r`/build/include, which points to kernel headers,
> > and which should be used for compiling out-of-tree kernel modules
> > (i.e. latest vmware uses this
[EMAIL PROTECTED] 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?
On Fri, 15 Dec 2000, Petr Vandrovec wrote:
> On 15 Dec 00 at 10:23, Dana Lacoste wrote:
> > > On Fri, Dec 15, 2000 at 12:14:04AM +, Miquel van Smoorenburg wrote:
> >
> > > It's the version that's in cvs, I just did an cvs update. It's
> > > been in it for ages. If it's wrong, someone *pl
On Fri, 15 Dec 2000, Werner Almesberger wrote:
> Alexander Viro wrote:
> > In the situation above they should have -I/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 "",
> this is fine. I
Dana Lacoste wrote:
>
> > Maybe you did not notice, but for months we have
> > /lib/modules/`uname -r`/build/include, which points to kernel headers,
> > and which should be used for compiling out-of-tree kernel modules
> > (i.e. latest vmware uses this).
>
> What about the case where I'm compil
On 15 Dec 00 at 11:00, Dana Lacoste wrote:
> > Maybe you did not notice, but for months we have
> > /lib/modules/`uname -r`/build/include, which points to kernel headers,
> > and which should be used for compiling out-of-tree kernel modules
> > (i.e. latest vmware uses this).
>
> What about the c
> Maybe you did not notice, but for months we have
> /lib/modules/`uname -r`/build/include, which points to kernel headers,
> and which should be used for compiling out-of-tree kernel modules
> (i.e. latest vmware uses this).
What about the case where I'm compiling for a kernel that I'm
not runni
On 15 Dec 00 at 10:23, Dana Lacoste wrote:
> > On Fri, Dec 15, 2000 at 12:14:04AM +, Miquel van Smoorenburg wrote:
>
> > It's the version that's in cvs, I just did an cvs update. It's
> > been in it for ages. If it's wrong, someone *please* correct it.
>
> I think this is the important par
> On Fri, Dec 15, 2000 at 12:14:04AM +, Miquel van Smoorenburg wrote:
> It's the version that's in cvs, I just did an cvs update. It's
> been in it for ages. If it's wrong, someone *please* correct it.
I think this is the important part.
This subject has come up quite a few times in the pa
On Fri, Dec 15, 2000 at 12:14:04AM +, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> LA Walsh <[EMAIL PROTECTED]> wrote:
> >Which works because in a normal compile environment they have /usr/include
> >in their include path and /usr/include/linux points to the directory
> >u
Alexander Viro wrote:
> In the situation above they should have -I/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 "",
this is fine. In most cases, the tree one expects to find is "roughly
the kerne
"LA Walsh" <[EMAIL PROTECTED]> writes:
> I've seen this setup on RH, SuSE and Mandrake systems. I thought
> this was somehow normal practice?
it's done for us till the 7.2 but next version we gonna to switch to a
different headers directory like Debian/RH does...
--
MandrakeSoft Inc
> Huh?
> % ls -ld /usr/include/linux
> drwxr-xr-x6 root root18432 Sep 2 22:35
> /usr/include/linux/
>
> > So if we create a separate /usr/src/linux/include/kernel dir, does that
> > imply that we'll have a 2nd link:
>
> What 2nd link? There should be _no_ links from /usr/include t
On Thu, 14 Dec 2000, Alexander Viro wrote:
>
>
> On Thu, 14 Dec 2000, David Riley wrote:
>
> > Alexander Viro wrote:
> > >
> > > Actually, I suspect that quite a few of us had done that since long -
> > > IIRC I've got burned on 1.2/1.3 and decided that I had enough. Bugger if I
> >
On Thu, 14 Dec 2000, David Riley wrote:
> Alexander Viro wrote:
> >
> > Actually, I suspect that quite a few of us had done that since long -
> > IIRC I've got burned on 1.2/1.3 and decided that I had enough. Bugger if I
> > remember what exactly it was - ISTR that it was restore(8) bu
Alexander Viro wrote:
>
> Actually, I suspect that quite a few of us had done that since long -
> IIRC I've got burned on 1.2/1.3 and decided that I had enough. Bugger if I
> remember what exactly it was - ISTR that it was restore(8) built with
> 1.3. headers and playing funny games on 1.
On Fri, 15 Dec 2000, Alan Cox wrote:
> > >Which works because in a normal compile environment they have /usr/include
> > >in their include path and /usr/include/linux points to the directory
> > >under /usr/src/linux/include.
> >
> > No, that a redhat-ism.
>
> Umm, its a most people except De
In article <[EMAIL PROTECTED]>,
Alexander Viro <[EMAIL PROTECTED]> wrote:
>On 15 Dec 2000, Miquel van Smoorenburg wrote:
>
>> In article <[EMAIL PROTECTED]>,
>> LA Walsh <[EMAIL PROTECTED]> wrote:
>> >Which works because in a normal compile environment they have /usr/include
>> >in their include
> >Which works because in a normal compile environment they have /usr/include
> >in their include path and /usr/include/linux points to the directory
> >under /usr/src/linux/include.
>
> No, that a redhat-ism.
Umm, its a most people except Debianism. People relied on it despite it
being wrong. R
On Thu, 14 Dec 2000, LA Walsh wrote:
> So I ran into a snag with that scenario. Let's suppose we have
> a module developer or a company developing a driver in their own
> /home/nvidia/video/drivers/newcard directory. Now they need to include
> kernel
> development files and are used to just d
On 15 Dec 2000, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> LA Walsh <[EMAIL PROTECTED]> wrote:
> >Which works because in a normal compile environment they have /usr/include
> >in their include path and /usr/include/linux points to the directory
> >under /usr/src/linux/inc
In article <[EMAIL PROTECTED]>,
LA Walsh <[EMAIL PROTECTED]> wrote:
>Which works because in a normal compile environment they have /usr/include
>in their include path and /usr/include/linux points to the directory
>under /usr/src/linux/include.
No, that a redhat-ism.
Sane distributions simply in
So, I brought up the idea of a linux/sys for kernel level include files.
A few other people came up with a desire of a 'kernel' dir under
include, parallel w/linux.
So I ran into a snag with that scenario. Let's suppose we have
a module developer or a company developing a driver in their own
/
67 matches
Mail list logo
