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
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 symlink
[[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
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 compile
[[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
[[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
[[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
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
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 is
[[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
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 kernel,
[[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 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, 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
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
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
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
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
> 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
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 running
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 case where
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 compiling for a
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 *please*
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).
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
27 matches
Mail list logo
