| |||||||||||||
In briefIn briefPosted Aug 25, 2009 21:01 UTC (Tue) by mb (subscriber, #50428)In reply to: In brief by nevets Parent article: In brief
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.
(Log in to post comments)
In brief Posted Aug 25, 2009 23:01 UTC (Tue) by nevets (subscriber, #11875) [Link]
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 (✭ supporter ✭, #313) [Link]
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.
|
|||||||||||||