sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
- From: Andrew <afrayedknot AT thefrayedknot.armory.com>
- To: sm-discuss AT lists.ibiblio.org
- Subject: Re: [SM-Discuss] linux-new call
- Date: Mon, 30 May 2005 15:30:58 -0700
>
> 2) I know what you mean about the kernel modules not compiling against the
> right
> kernel this is a problem that is greater than the linux spell, the only
> thing
> that can be done is go to each spell that compiles an external kernel module
> and make it use installed_version linux to compile against, I'll be working
> on
> converting the kernels and mobile sections over the summer to use the
> version
> returned by sorcery instead of uname (which is what most of the spells use)
>
> I know your frustration with this problem but this is the only real solution
> for fixing it. And *nothing* can be done in the linux spell to fix this.
I'll make a shameless plug for a small piece of code i wrote for an iso
generation experiment to intercept the uname system call (attached). If
interested you could just roll this into a spell, and then in the module
spells just preload the library. Then anything and everything that uses
uname, either through the uname command or the system call will get our
custom set values.
>
> >I can see two possibilities, either remember somewhere that the modules
> >should be cast later ( install queue ? ) or force their compilation to
> >use different install directory. In either case, I'm not sure how to do
> >that :)
>
> The second part of this is what my solution is basically...
>
> >The second thing is that once the module is recompilled, it dispells old
> >version, which makes old kernel un-usable. If I am going to reboot to
> >older kernel, I have to recast theese modules again. I would like to
> >have the modules stay on the system for each kernel I compiled them.
>
> A solution would be to have sorcery ignore dispel in /lib/modules
Those spells need to simply add a protected file.
Attachment:
unamehack.tar.gz
Description: application/tar-gz
-
[SM-Discuss] linux-new call,
Eric Sandall, 05/30/2005
- <Possible follow-up(s)>
-
RE: [SM-Discuss] linux-new call,
David Michael Leo Brown Jr., 05/30/2005
- Re: [SM-Discuss] linux-new call, Duane Malcolm, 05/30/2005
- Re: [SM-Discuss] linux-new call, neuron, 05/30/2005
-
Re: [SM-Discuss] linux-new call,
David Michael Leo Brown Jr., 05/30/2005
- Re: [SM-Discuss] linux-new call, Sergey A. Lipnevich, 05/30/2005
-
Re: [SM-Discuss] linux-new call,
David Michael Leo Brown Jr., 05/30/2005
-
Re: [SM-Discuss] linux-new call,
Andrew, 05/30/2005
-
Re: [SM-Discuss] linux-new call,
neuron, 05/31/2005
-
Re: [SM-Discuss] linux-new call,
Andrew, 05/31/2005
- Re: [SM-Discuss] linux-new call, neuron, 05/31/2005
-
Re: [SM-Discuss] linux-new call,
Andrew, 05/31/2005
-
Re: [SM-Discuss] linux-new call,
neuron, 05/31/2005
- Re: [SM-Discuss] linux-new call, neuron, 05/31/2005
-
Re: [SM-Discuss] linux-new call,
Andrew, 05/30/2005
-
Re: [SM-Discuss] linux-new call,
David Michael Leo Brown Jr., 05/30/2005
-
Re: [SM-Discuss] linux-new call,
Sergey A. Lipnevich, 05/30/2005
- Re: [SM-Discuss] linux-new call, neuron, 05/31/2005
-
Re: [SM-Discuss] linux-new call,
Sergey A. Lipnevich, 05/30/2005
-
Re: [SM-Discuss] linux-new call,
David Michael Leo Brown Jr., 05/31/2005
- Re: [SM-Discuss] linux-new call, Seth Alan Woolley, 05/31/2005
- Re: [SM-Discuss] linux-new call, Sergey A. Lipnevich, 05/31/2005
Archive powered by MHonArc 2.6.24.