In brief

Posted Aug 22, 2009 10:28 UTC (Sat) by dlang (guest, #313)
Parent article: In brief

do the local*module commands have some way of pointing you at a file from another server instead of (I assume) /proc/modules?

there needs to be some way to gather the info from one (probably low-powered) system and taking it to another system to actually do the build on.

In brief

Posted Aug 22, 2009 17:26 UTC (Sat) by rvfh (guest, #31018) [Link] (6 responses)

I suppose you can do local*config on the low-power machine and interrupt it when it starts compiling, then copy the .config file accross. Make sure you have the right compiler and compiler options though...

In brief

Posted Aug 23, 2009 3:21 UTC (Sun) by jzbiciak (guest, #5246) [Link] (5 responses)

It looks like all this make target does is generate the .config. You'd still have to build the kernel and modules afterwards. (At least, that's the impression I got from the linked email.)

In brief

Posted Aug 23, 2009 17:11 UTC (Sun) by nevets (subscriber, #11875) [Link] (4 responses)

Yes exactly. It is just like the other "make *config". It only creates a config file and nothing more. I've used it on embedded boards to get a proper config. I would NFS mount the source, log into the embedded device, cd to the NFS mounted directory and run the "make localmodconfig" (well this is actually a lie, since I really just manually ran streamline_config.pl, but this should also work), and then built the resulting config on a faster box.

In brief

Posted Aug 25, 2009 21:01 UTC (Tue) by mb (subscriber, #50428) [Link] (3 responses)

Well, but many small and embedded devices don't even have make or perl. So isn't there some way to tell the script to look somewhere else than /proc/modules (or wherever it looks into)?
So I could simply scp the modules list from the embedded machine to the build host and do the rest on the big machine.

In brief

Posted Aug 25, 2009 23:01 UTC (Tue) by nevets (subscriber, #11875) [Link] (2 responses)

Yeah, that looks like we can add an enhancement. Perhaps add a "make LOADED_MODULES=embedded.lsmod localmodconfig", where embedded.lsmod is a filename holding the modules of the embedded device. Or have it use an environment variable to find the list of modules. If the environment variable does not exist, then it uses lsmod or /proc/modules. It currently does lsmod, but perhaps it should use /proc/modules directly.

Thanks.

In brief

Posted Aug 25, 2009 23:09 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

if this just executes lsmod and parses the result, then the user can create a lsmod earlier in their path that echo's the results from a different box

or you could allow the user to specify a command to get the data (defaulting to lsmod if nothing is specified)

In brief

Posted Sep 3, 2009 20:35 UTC (Thu) by kabloom (guest, #59417) [Link]

Both of those are a bit of overkill. Why create an executable to generate the data, when a file will do.