[Toybox] [PATCH] Re: modinfo...

[Isaac]

On Wed, Jun 19, 2013 at 11:44:08PM -0500, Rob Landley wrote:
> On 06/18/2013 08:55:42 AM, Isaac wrote:
> >
> >Oh, there's a trivial option to add to modinfo: -b <basedir>
> >(used for constructing an initrd-it locates the modules within
> >a given directory).
> 
> Um, where's this from? My host's modinfo hasn't got it, and I don't
> know of an actual standard for this...
> 

I noticed it on my Lucid system:

Usage: modinfo [-0][-F field][-k kernelversion][-b basedir]  module...
 Prints out the information about one or more module(s).
 If a fieldname is given, just print out that field (or nothing if not found).
 Otherwise, print all information out in a readable form
 If -0 is given, separate with nul, not newline.
 If -b is given, use an image of the module tree.

I googled it and found indications that it was used in initrd scripts,
but now I see it does not appear to be used in Debian/Ubuntu scripts.
In fact, the only time modinfo is used is in this line:
  firmwares=$(modinfo -F firmware "${mam_x}")

So I don't see a high priority; on the other hand, it might hypothetically be 
useful if firmware requirements change in a new kernel version.
In other words, sounds like something to hold off on.

> >I have a patch to add it, but I'm wondering why
> >NEWTOY(..."<b:F:0"...)
> >GLOBALS(
> >  char *field;
> >  char *basedir;
> >..
> >works right, and putting the GLOBALS in the same order as the
> >option string breaks (tested on glibc and musl).
> 
> The option strings parse from right to left. F: is the rightmost
> captured string so it goes in the first slot, b: is in the next
> rightmost captured string, so it goes in the second slot.
> 
> The documentation describes this:
> http://landley.net/toybox/code.html#lib_args
> 
> >modinfo also should support specifying an absolute or relative path
> >to a module; the one complication is that modinfo_file() takes a
> >struct dirtree, not a filename; can dirtree_read handle a filename
> >or a relative path?
> 
> Yes: http://landley.net/toybox/code.html#lib_dirtree

Thanks for the answer; I missed that, probably due to trying to read 
rather late.
I have a patch that assumes that the presence of the string ".ko" indicates
use of a path to a module (*.ko.xz and similar included, but not supported).

While I am not aware of any rules forbidding a module like "barf.ko.ko",
an strace of module-init-tools modinfo indicates that they use similar logic.

It adds 6 lines, with 41 bytes increase in binary size (GCC 4.4, 
glibc/dynamic and musl/static, according to make baseline/bloatcheck).
I'm not sure if the void->int change was needed, though it does keep GCC
quiet. But perror_exit; -> perror_msg; return; was needed.

Thanks,
Isaac Dunham
-------------- next part --------------
A non-text attachment was scrubbed...
Name: modinfo-mod.ko.diff
Type: text/x-diff
Size: 1192 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20130620/ae6b967b/attachment-0007.diff>