cross-depmod?

cross-depmod?

[Hollis Blanchard]

Hi Sam, would you take a patch like this:

--- 1.509/Makefile      Tue Aug  3 16:11:35 2004
+++ edited/Makefile     Thu Aug  5 17:12:07 2004
@@ -790,7 +790,11 @@
 endif
 .PHONY: _modinst_post
 _modinst_post: _modinst_
-       if [ -r System.map ]; then $(DEPMOD) -ae -F System.map $(depmod_opts) $(KERNELRELEASE); fi
+       if [ -z "$(CROSS_COMPILE)" -o "$(DEPMOD)" != "/sbin/depmod" ] ; then \
+               if [ -r System.map ]; then \
+                       $(DEPMOD) -ae -F System.map $(depmod_opts) $(KERNELRELEASE); \
+               fi \
+       fi

 else # CONFIG_MODULES

(I don't like hardcoding /sbin/depmod; this is just for conversation.)

My problem is that I cross-build my kernels, and 'make rpm' is very
unhappy when it can't use depmod. I know that I can do 'make
DEPMOD=/bin/true rpm', but can't we figure that out automatically?

In general if you're cross-compiling I don't think you can assume
/sbin/depmod is ok. Someone could do 'make DEPMOD=powerpc-linux-depmod'
though (couldn't they? does anybody bother?), so if $(DEPMOD) has been
specified we still want to let that work...

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: cross-depmod?

[David Vrabel]

Hollis Blanchard wrote:
> 
> My problem is that I cross-build my kernels, and 'make rpm' is very
> unhappy when it can't use depmod. I know that I can do 'make
> DEPMOD=/bin/true rpm', but can't we figure that out automatically?

I'd suggest not running depmod when building an RPM but instead run it 
as part of the RPMs post-installation script.

David Vrabel
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/

Re: cross-depmod?

[Geert Uytterhoeven]

On Fri, 6 Aug 2004, David Vrabel wrote:
> Hollis Blanchard wrote:
> > My problem is that I cross-build my kernels, and 'make rpm' is very
> > unhappy when it can't use depmod. I know that I can do 'make
> > DEPMOD=/bin/true rpm', but can't we figure that out automatically?
>
> I'd suggest not running depmod when building an RPM but instead run it
> as part of the RPMs post-installation script.

I guess Hollis (just like me) is mostly interested in the possible error
messages of depmod, due to missing exported symbols.

Hollis: I asked the same question about six months year ago, cfr. the thread at
http://seclists.org/lists/linux-kernel/2004/Feb/3527.html

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: cross-depmod?

[Sam Ravnborg]

On Fri, Aug 06, 2004 at 03:45:16PM +0200, Geert Uytterhoeven wrote:
> On Fri, 6 Aug 2004, David Vrabel wrote:
> > Hollis Blanchard wrote:
> > > My problem is that I cross-build my kernels, and 'make rpm' is very
> > > unhappy when it can't use depmod. I know that I can do 'make
> > > DEPMOD=/bin/true rpm', but can't we figure that out automatically?
> >
> > I'd suggest not running depmod when building an RPM but instead run it
> > as part of the RPMs post-installation script.
> 
> I guess Hollis (just like me) is mostly interested in the possible error
> messages of depmod, due to missing exported symbols.

This is fixed in modpost so you actually now get a warning when modpost
is executed.

	Sam

Re: cross-depmod?

[Sam Ravnborg]

On Thu, Aug 05, 2004 at 04:51:56PM -0500, Hollis Blanchard wrote:
> Hi Sam, would you take a patch like this:
> 
> --- 1.509/Makefile      Tue Aug  3 16:11:35 2004
> +++ edited/Makefile     Thu Aug  5 17:12:07 2004
> @@ -790,7 +790,11 @@
>  endif
>  .PHONY: _modinst_post
>  _modinst_post: _modinst_
> -       if [ -r System.map ]; then $(DEPMOD) -ae -F System.map $(depmod_opts) $(KERNELRELEASE); fi
> +       if [ -z "$(CROSS_COMPILE)" -o "$(DEPMOD)" != "/sbin/depmod" ] ; then \
> +               if [ -r System.map ]; then \
> +                       $(DEPMOD) -ae -F System.map $(depmod_opts) $(KERNELRELEASE); \
> +               fi \
> +       fi
> 
>  else # CONFIG_MODULES
> 
> (I don't like hardcoding /sbin/depmod; this is just for conversation.)
> 
> My problem is that I cross-build my kernels, and 'make rpm' is very
> unhappy when it can't use depmod. I know that I can do 'make
> DEPMOD=/bin/true rpm', but can't we figure that out automatically?

I assume the problem arises from the fact that depmod are only capable of
reading elf files for the host it is compiled for.
OK, took a look at depmod.
It handles both 32 and 64 bit but assumes same endian.

Rusty: Would it make sense to extend module-init-tools to support
endian as specified in elf file?

	Sam

Re: cross-depmod?

[Rusty Russell]

On Sat, 2004-08-07 at 01:42, Sam Ravnborg wrote:
> I assume the problem arises from the fact that depmod are only capable of
> reading elf files for the host it is compiled for.
> OK, took a look at depmod.
> It handles both 32 and 64 bit but assumes same endian.
> 
> Rusty: Would it make sense to extend module-init-tools to support
> endian as specified in elf file?

Frankly, yes.

In my opinion, it makes even more sense for modprobe to do the work
itself, and cache the info in /lib/modules/`uname
-r`/modules.{dep,alias,symtab}.

I was always planning on doing this after we got rid of the modules.map
files, but that never happened due to reluctance from other people to
transition, and I didn't fight them.

Cheers,
Rusty.
-- 
Anyone who quotes me in their signature is an idiot -- Rusty Russell

Re: cross-depmod?

[Greg KH]

On Mon, Aug 09, 2004 at 09:05:11AM +1000, Rusty Russell wrote:
> 
> I was always planning on doing this after we got rid of the modules.map
> files, but that never happened due to reluctance from other people to
> transition, and I didn't fight them.

The reluctance was just not-enough-time to update the hotplug scripts.

However, if you forced the issue and took away the files, making me fix
the hotplug scripts, that might just cause it to happen a lot sooner :)

thanks,

greg k-h