Discussion:
Implemented split, pondering a release.
(too old to reply)
Rob Landley
2013-06-17 07:22:11 UTC
Permalink
I actually got some time to myself this weekend (visited my sister
while the kids were at their father's and she was at work for part of
it), so I banged out one of the remaining low-hanging-fruit commands
that aboriginal linux (actually linux from scratch) needs to build:
split. Got it finished, tested, and checked in, and added tests for it
to the test suite.

Starting to think about a release. I've got to do an aboriginal linux
release for the 3.10 kernel in a couple weeks, and I generally flush
pending toybox stuff into a release so that can use it. (Three fewer
busybox commands, 42 left several of which are duplicates like "[ [[
test" and "ash sh", and of course the toybox multiplexer.)

I'd like to finish the ifconfig cleanup, and documenting all that.
Beyond that nothing's really a release blocker, but I'm open to
suggestions.

(I feel hugely guilty about not getting mount.c looked at. That's
probably the first thing up for next release. Well, I have a
half-finished umount.c that I might do first because it's smaller and
the three mount/umount/losetup are sort of a group. To do mount I need
to set up test environments for nfs and samba, and finally get the root
support in scripts/test so I can do a mount.test...)

Rob
Isaac
2013-06-18 13:55:42 UTC
Permalink
Post by Rob Landley
I actually got some time to myself this weekend (visited my sister
while the kids were at their father's and she was at work for part
of it), so I banged out one of the remaining low-hanging-fruit
commands that aboriginal linux (actually linux from scratch) needs
to build: split. Got it finished, tested, and checked in, and added
tests for it to the test suite.
Starting to think about a release. I've got to do an aboriginal
linux release for the 3.10 kernel in a couple weeks, and I generally
flush pending toybox stuff into a release so that can use it. (Three
fewer busybox commands, 42 left several of which are duplicates like
"[ [[ test" and "ash sh", and of course the toybox multiplexer.)
I'd like to finish the ifconfig cleanup, and documenting all that.
Beyond that nothing's really a release blocker, but I'm open to
suggestions.
Sounds good to me.
Post by Rob Landley
(I feel hugely guilty about not getting mount.c looked at. That's
probably the first thing up for next release. Well, I have a
half-finished umount.c that I might do first because it's smaller
and the three mount/umount/losetup are sort of a group. To do mount
I need to set up test environments for nfs and samba, and finally
get the root support in scripts/test so I can do a mount.test...)
I doubt that it could happen before a 3.10 release...
Doing mount/umount for the next release sounds sensible to me.

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).
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).

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?

Isaac Dunham
Post by Rob Landley
Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: modinfo-basedir.diff
Type: text/x-diff
Size: 1061 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20130618/14333d16/attachment.diff>
Rob Landley
2013-06-20 04:44:08 UTC
Permalink
Post by Isaac
Post by Rob Landley
I actually got some time to myself this weekend (visited my sister
while the kids were at their father's and she was at work for part
of it), so I banged out one of the remaining low-hanging-fruit
commands that aboriginal linux (actually linux from scratch) needs
to build: split. Got it finished, tested, and checked in, and added
tests for it to the test suite.
Starting to think about a release. I've got to do an aboriginal
linux release for the 3.10 kernel in a couple weeks, and I generally
flush pending toybox stuff into a release so that can use it. (Three
fewer busybox commands, 42 left several of which are duplicates like
"[ [[ test" and "ash sh", and of course the toybox multiplexer.)
I'd like to finish the ifconfig cleanup, and documenting all that.
Beyond that nothing's really a release blocker, but I'm open to
suggestions.
Sounds good to me.
Post by Rob Landley
(I feel hugely guilty about not getting mount.c looked at. That's
probably the first thing up for next release. Well, I have a
half-finished umount.c that I might do first because it's smaller
and the three mount/umount/losetup are sort of a group. To do mount
I need to set up test environments for nfs and samba, and finally
get the root support in scripts/test so I can do a mount.test...)
I doubt that it could happen before a 3.10 release...
Doing mount/umount for the next release sounds sensible to me.
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...
Post by Isaac
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
Post by Isaac
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

Rob
Isaac
2013-06-21 04:24:48 UTC
Permalink
Post by Rob Landley
Post by Isaac
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.
Post by Rob Landley
Post by Isaac
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.
http://landley.net/toybox/code.html#lib_args
Post by Isaac
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.diff>
Isaac
2013-06-21 04:24:48 UTC
Permalink
Post by Rob Landley
Post by Isaac
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.
Post by Rob Landley
Post by Isaac
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.
http://landley.net/toybox/code.html#lib_args
Post by Isaac
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-0002.diff>
Rob Landley
2013-06-23 19:39:14 UTC
Permalink
Post by Isaac
Post by Rob Landley
Post by Isaac
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...
Ok.
Post by Isaac
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 haven't got an objection if it's actually being used somewhere, I
just didn't see it on my system.
Post by Isaac
Post by Rob Landley
Post by Isaac
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.
http://landley.net/toybox/code.html#lib_args
Post by Isaac
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 feel I should make the documentation more clear, but dunno how.
Post by Isaac
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).
Wouldn't the presence of a / character indicate use of a path?
Post by Isaac
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.
Hmmm... I guess an actual file is going to have the .ko extension,
although strstr() doesn't confirm it _ends_ with .ko...

The difference between if (strchr(str, '/')) and checking for .ko is
that "modinfo filename.ko" would work with the second but not the
first. We could also always check for the argument as a file, but that
would mean if you do have a file in the current directory of the same
name it would load that file, and that's a bit like not having "." in
the $PATH by default...

Eh, changing behavior based on extension is normalish. I'd like to add
a check to make sure it's actually at the end until the further
extension support is implemented.
Post by Isaac
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.
Except it's still xopen(), so it'll abort if unable to open the file,
but return error if it can't map it. (And leak the filehandle.) Hmmm...
all modinfo_file() actually uses is the filename, no reason to go
through dirtree() for that... Nothing is actually _checking_ the return
value of modinfo_file()... Huh, and this thing is doing a blob of
global data (I try to combine globals into the union)...

Checking in a cleanup on top of your commit. (And I need to dig up the
-b patch...)

Thanks,

Rob
Isaac
2013-06-24 07:29:59 UTC
Permalink
Post by Rob Landley
Post by Isaac
Post by Rob Landley
Post by Isaac
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...
Ok.
Post by Isaac
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 haven't got an objection if it's actually being used somewhere, I
just didn't see it on my system.
Looking at the kmod documentation, I see that the function is a little
different from what I thought:
it's changing the root for your search (eg, -b ~/projects/out/ where that's the contents of a future boot filesystem).
Of course, that means the patch to add -b is broken.
Post by Rob Landley
Post by Isaac
Post by Rob Landley
http://landley.net/toybox/code.html#lib_args
Post by Isaac
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 feel I should make the documentation more clear, but dunno how.
You can't clarify everything. It seems obvious reading it, but try reading
anything when you can barely stay awake...
Post by Rob Landley
Wouldn't the presence of a / character indicate use of a path?
Post by Isaac
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.
Hmmm... I guess an actual file is going to have the .ko extension,
although strstr() doesn't confirm it _ends_ with .ko...
The difference between if (strchr(str, '/')) and checking for .ko is
that "modinfo filename.ko" would work with the second but not the
first. We could also always check for the argument as a file, but
that would mean if you do have a file in the current directory of
the same name it would load that file, and that's a bit like not
having "." in the $PATH by default...
Eh, changing behavior based on extension is normalish. I'd like to
add a check to make sure it's actually at the end until the further
extension support is implemented.
OK.
modinfo ath_pci.ko
is something that I have done from time to time.
Post by Rob Landley
Post by Isaac
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.
Except it's still xopen(), so it'll abort if unable to open the
file, but return error if it can't map it. (And leak the
filehandle.) Hmmm... all modinfo_file() actually uses is the
filename, no reason to go through dirtree() for that... Nothing is
actually _checking_ the return value of modinfo_file()... Huh, and
this thing is doing a blob of global data (I try to combine globals
into the union)...
Checking in a cleanup on top of your commit. (And I need to dig up
the -b patch...)
Thanks.

See above (-b patch is broken). But it's after midnight here, so I'm
not rewriting it atm.
Post by Rob Landley
Thanks,
Rob
Isaac
2013-06-25 04:55:43 UTC
Permalink
modinfo: support -b basedir and -k kernel.release, fix two bugs
Add two less-frequently used flags for modinfo; -b specifies an alternate
root and -k replaces the output of uname -r.

Additionally, avoid a potential overflow in sprintf,
and correct an inverted test.
Post by Rob Landley
Except it's still xopen(), so it'll abort if unable to open the
file, but return error if it can't map it. (And leak the
filehandle.) Hmmm... all modinfo_file() actually uses is the
filename, no reason to go through dirtree() for that... Nothing is
actually _checking_ the return value of modinfo_file()... Huh, and
this thing is doing a blob of global data (I try to combine globals
into the union)...
Checking in a cleanup on top of your commit. (And I need to dig up
the -b patch...)
The cleanup looks to have broken -F. Ah, it's line 23 (!strcmp -> strcmp)
I could split the patch out, but it's one line.

Now to add -b (and maybe -k, which specifies a kernel version instead of
using uname).
Ok, pretty simple.
And all this shows up one hole:
/toybox modinfo -b $(for a in `seq 40960`; \
do printf /; done ) ath5k
Segmentation fault

There's a potential overflow whenever user-controlled text is copied into
toybuf. So I decided to change sprintf to
snprintf(toybuf, sizeof(toybuf), string, ...)
If snprintf returns sizeof(toybuf), it didn't find enough space for the final
"\0", so we need to exit.
Post by Rob Landley
Thanks,
Rob
HTH,
Isaac Dunham
-------------- next part --------------
A non-text attachment was scrubbed...
Name: modinfo-basedir.diff
Type: text/x-diff
Size: 1580 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20130624/b17e38be/attachment.diff>
Isaac
2013-06-24 07:29:59 UTC
Permalink
Post by Rob Landley
Post by Isaac
Post by Rob Landley
Post by Isaac
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...
Ok.
Post by Isaac
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 haven't got an objection if it's actually being used somewhere, I
just didn't see it on my system.
Looking at the kmod documentation, I see that the function is a little
different from what I thought:
it's changing the root for your search (eg, -b ~/projects/out/ where that's the contents of a future boot filesystem).
Of course, that means the patch to add -b is broken.
Post by Rob Landley
Post by Isaac
Post by Rob Landley
http://landley.net/toybox/code.html#lib_args
Post by Isaac
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 feel I should make the documentation more clear, but dunno how.
You can't clarify everything. It seems obvious reading it, but try reading
anything when you can barely stay awake...
Post by Rob Landley
Wouldn't the presence of a / character indicate use of a path?
Post by Isaac
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.
Hmmm... I guess an actual file is going to have the .ko extension,
although strstr() doesn't confirm it _ends_ with .ko...
The difference between if (strchr(str, '/')) and checking for .ko is
that "modinfo filename.ko" would work with the second but not the
first. We could also always check for the argument as a file, but
that would mean if you do have a file in the current directory of
the same name it would load that file, and that's a bit like not
having "." in the $PATH by default...
Eh, changing behavior based on extension is normalish. I'd like to
add a check to make sure it's actually at the end until the further
extension support is implemented.
OK.
modinfo ath_pci.ko
is something that I have done from time to time.
Post by Rob Landley
Post by Isaac
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.
Except it's still xopen(), so it'll abort if unable to open the
file, but return error if it can't map it. (And leak the
filehandle.) Hmmm... all modinfo_file() actually uses is the
filename, no reason to go through dirtree() for that... Nothing is
actually _checking_ the return value of modinfo_file()... Huh, and
this thing is doing a blob of global data (I try to combine globals
into the union)...
Checking in a cleanup on top of your commit. (And I need to dig up
the -b patch...)
Thanks.

See above (-b patch is broken). But it's after midnight here, so I'm
not rewriting it atm.
Post by Rob Landley
Thanks,
Rob
Isaac
2013-06-25 04:55:43 UTC
Permalink
modinfo: support -b basedir and -k kernel.release, fix two bugs
Add two less-frequently used flags for modinfo; -b specifies an alternate
root and -k replaces the output of uname -r.

Additionally, avoid a potential overflow in sprintf,
and correct an inverted test.
Post by Rob Landley
Except it's still xopen(), so it'll abort if unable to open the
file, but return error if it can't map it. (And leak the
filehandle.) Hmmm... all modinfo_file() actually uses is the
filename, no reason to go through dirtree() for that... Nothing is
actually _checking_ the return value of modinfo_file()... Huh, and
this thing is doing a blob of global data (I try to combine globals
into the union)...
Checking in a cleanup on top of your commit. (And I need to dig up
the -b patch...)
The cleanup looks to have broken -F. Ah, it's line 23 (!strcmp -> strcmp)
I could split the patch out, but it's one line.

Now to add -b (and maybe -k, which specifies a kernel version instead of
using uname).
Ok, pretty simple.
And all this shows up one hole:
/toybox modinfo -b $(for a in `seq 40960`; \
do printf /; done ) ath5k
Segmentation fault

There's a potential overflow whenever user-controlled text is copied into
toybuf. So I decided to change sprintf to
snprintf(toybuf, sizeof(toybuf), string, ...)
If snprintf returns sizeof(toybuf), it didn't find enough space for the final
"\0", so we need to exit.
Post by Rob Landley
Thanks,
Rob
HTH,
Isaac Dunham
-------------- next part --------------
A non-text attachment was scrubbed...
Name: modinfo-basedir.diff
Type: text/x-diff
Size: 1580 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20130624/b17e38be/attachment-0002.diff>
Rob Landley
2013-06-17 07:22:11 UTC
Permalink
I actually got some time to myself this weekend (visited my sister
while the kids were at their father's and she was at work for part of
it), so I banged out one of the remaining low-hanging-fruit commands
that aboriginal linux (actually linux from scratch) needs to build:
split. Got it finished, tested, and checked in, and added tests for it
to the test suite.

Starting to think about a release. I've got to do an aboriginal linux
release for the 3.10 kernel in a couple weeks, and I generally flush
pending toybox stuff into a release so that can use it. (Three fewer
busybox commands, 42 left several of which are duplicates like "[ [[
test" and "ash sh", and of course the toybox multiplexer.)

I'd like to finish the ifconfig cleanup, and documenting all that.
Beyond that nothing's really a release blocker, but I'm open to
suggestions.

(I feel hugely guilty about not getting mount.c looked at. That's
probably the first thing up for next release. Well, I have a
half-finished umount.c that I might do first because it's smaller and
the three mount/umount/losetup are sort of a group. To do mount I need
to set up test environments for nfs and samba, and finally get the root
support in scripts/test so I can do a mount.test...)

Rob
Isaac
2013-06-18 13:55:42 UTC
Permalink
Post by Rob Landley
I actually got some time to myself this weekend (visited my sister
while the kids were at their father's and she was at work for part
of it), so I banged out one of the remaining low-hanging-fruit
commands that aboriginal linux (actually linux from scratch) needs
to build: split. Got it finished, tested, and checked in, and added
tests for it to the test suite.
Starting to think about a release. I've got to do an aboriginal
linux release for the 3.10 kernel in a couple weeks, and I generally
flush pending toybox stuff into a release so that can use it. (Three
fewer busybox commands, 42 left several of which are duplicates like
"[ [[ test" and "ash sh", and of course the toybox multiplexer.)
I'd like to finish the ifconfig cleanup, and documenting all that.
Beyond that nothing's really a release blocker, but I'm open to
suggestions.
Sounds good to me.
Post by Rob Landley
(I feel hugely guilty about not getting mount.c looked at. That's
probably the first thing up for next release. Well, I have a
half-finished umount.c that I might do first because it's smaller
and the three mount/umount/losetup are sort of a group. To do mount
I need to set up test environments for nfs and samba, and finally
get the root support in scripts/test so I can do a mount.test...)
I doubt that it could happen before a 3.10 release...
Doing mount/umount for the next release sounds sensible to me.

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).
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).

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?

Isaac Dunham
Post by Rob Landley
Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: modinfo-basedir.diff
Type: text/x-diff
Size: 1061 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20130618/14333d16/attachment-0002.diff>
Rob Landley
2013-06-20 04:44:08 UTC
Permalink
Post by Isaac
Post by Rob Landley
I actually got some time to myself this weekend (visited my sister
while the kids were at their father's and she was at work for part
of it), so I banged out one of the remaining low-hanging-fruit
commands that aboriginal linux (actually linux from scratch) needs
to build: split. Got it finished, tested, and checked in, and added
tests for it to the test suite.
Starting to think about a release. I've got to do an aboriginal
linux release for the 3.10 kernel in a couple weeks, and I generally
flush pending toybox stuff into a release so that can use it. (Three
fewer busybox commands, 42 left several of which are duplicates like
"[ [[ test" and "ash sh", and of course the toybox multiplexer.)
I'd like to finish the ifconfig cleanup, and documenting all that.
Beyond that nothing's really a release blocker, but I'm open to
suggestions.
Sounds good to me.
Post by Rob Landley
(I feel hugely guilty about not getting mount.c looked at. That's
probably the first thing up for next release. Well, I have a
half-finished umount.c that I might do first because it's smaller
and the three mount/umount/losetup are sort of a group. To do mount
I need to set up test environments for nfs and samba, and finally
get the root support in scripts/test so I can do a mount.test...)
I doubt that it could happen before a 3.10 release...
Doing mount/umount for the next release sounds sensible to me.
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...
Post by Isaac
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
Post by Isaac
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

Rob
Rob Landley
2013-06-23 19:39:14 UTC
Permalink
Post by Isaac
Post by Rob Landley
Post by Isaac
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...
Ok.
Post by Isaac
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 haven't got an objection if it's actually being used somewhere, I
just didn't see it on my system.
Post by Isaac
Post by Rob Landley
Post by Isaac
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.
http://landley.net/toybox/code.html#lib_args
Post by Isaac
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 feel I should make the documentation more clear, but dunno how.
Post by Isaac
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).
Wouldn't the presence of a / character indicate use of a path?
Post by Isaac
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.
Hmmm... I guess an actual file is going to have the .ko extension,
although strstr() doesn't confirm it _ends_ with .ko...

The difference between if (strchr(str, '/')) and checking for .ko is
that "modinfo filename.ko" would work with the second but not the
first. We could also always check for the argument as a file, but that
would mean if you do have a file in the current directory of the same
name it would load that file, and that's a bit like not having "." in
the $PATH by default...

Eh, changing behavior based on extension is normalish. I'd like to add
a check to make sure it's actually at the end until the further
extension support is implemented.
Post by Isaac
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.
Except it's still xopen(), so it'll abort if unable to open the file,
but return error if it can't map it. (And leak the filehandle.) Hmmm...
all modinfo_file() actually uses is the filename, no reason to go
through dirtree() for that... Nothing is actually _checking_ the return
value of modinfo_file()... Huh, and this thing is doing a blob of
global data (I try to combine globals into the union)...

Checking in a cleanup on top of your commit. (And I need to dig up the
-b patch...)

Thanks,

Rob
Continue reading on narkive:
Loading...