gmane.linux.toybox

Hello, I would like to carve out a project

Terrel Shumway — 2013-05-23T22:13:37

I listened to Rob's "Why Toybox" talk and I understand the urgency.

My recent coding experience has been in Python, but I did some C a long
time ago. I would like to help.

Is there a important command that a semi-newbie could whip out in ~40-80
hours?  I am thinking of pgrep/pkill,  but I am willing to work on
something else that may be a higher priority.

This would be part of my capstone project for B.S.

Re: Regarding if() condition in dirtree_add_node

Rob Landley — 2013-05-21T10:33:13

It's not trying to open the file the link points to, it's trying to  
read the link's value. The symfollow thing is to treate symlinks as  
directories and recurse through them, this is just trying to fill out  
the current node's data, and that data should include the value of the  
symlink if this is a symlink.

Could you give me an example that would let me reproduce the failure  
you're seeing?

By the way, I've had this in my tree for months:

--- a/lib/dirtree.c     Tue May 21 00:23:23 2013 -0500
+++ b/lib/dirtree.c     Tue May 21 05:13:54 2013 -0500
< at >< at > -138,7 +138,7 < at >< at >
    struct dirent *entry;
    DIR *dir;

-  if (!(dir = fdopendir(node->data))) {
+  if (node->data == -1 || !(dir = fdopendir(node->data))) {
      char *path = dirtree_path(node, 0);
      perror_msg("No %s", path);
      free(path);

It's fallout from running the full test suite twice (make defconfig;  
make tests; make tests), which produces entires with crazy permissions  
(such as chmod 000 dirname) that don't get cleaned up by t

[CLEANUP] ifconfig commit 907

Rob Landley — 2013-05-21T05:26:14

http://landley.net/hg/toybox/rev/907

--- show_ip_addr

The function show_ip_addr() is only ever called from display_ifconfig.  
It's called four times in a row, so it's better to have it be a  
function that repeated inline four times. However, it's even better to  
have it be the body of a loop that we iterate over four times, parsing  
a table of data. (Locality of reference makes code easier to read: a  
loop that does its work inline is all in front of you, a loop that  
calls a function has to marshal data into and out of the function and  
you have to go to another page of code to see what it's doing.)

The question is: does the overhead of the table outweigh the advantage  
of having the code moved inline at its only callsite? This is an  
apples/oranges comparison: making the code bigger vs making it easier  
to understand. However, each function call with multiple arguments has  
a certain amount of overhead, as does the extra function body itself,  
so if the table doesn't have more entries than t

[CLEANUP] ifconfig commit 906

Rob Landley — 2013-05-21T05:49:02

http://landley.net/hg/toybox/rev/906

I started by doing the table cleanup I mentioned last message, bringing  
the table back down to three members. I took out the array and made all  
three members separate, called "name", "on", and "off", and just had  
the flag setting logic doing two ? : swaps to handle rev. what used to  
be the t->addr != 0 case is now ((t->off | 0xff) == 0x89ff), in which  
case I zero off before continuing. (I copy on and off to local  
variables so I don't muck up the table in case people do more than one  
instance of the same command, although why they'd do that... Oh well,  
it also makes the ? : stanzas fit in 80 chars more easily.)

Another cleanup: remove every instance of char *req_name in function  
arguments. They stopped being used when xioctl() went in, but they're  
still vestigially there in a lot of places.

The rest of this one is basically just a frenzy of inlining:  
set_metric(), set_qlen(), set_memstart(), and set_ioaddr() all do  
basically the same thing: read

Regarding if() condition in dirtree_add_node

Sandeep Sharma — 2013-05-21T05:36:41

Hi Rob,

               I have came across a condition in dirtree_add_node(), where
we are reading the link even though symfollow is not set :-

               if (S_ISLNK(st.st_mode) {
               if (0>(linklen = readlinkat(fd, name, buf, 4095))) goto
error;
               buf[linklen++]=0;
               }
              In this senario if we land in readonly links it shouts that
the link is not present, even thogh we are not following links.
              I think condition should be
              if (S_ISLNK(st.st_mode) && symfollow). whats your opinion?

             And one more thing:-
             I am using xreadfile() function present in lib.c but it
is commented. Do you mind uncommenting it?


Regards
Sandeep
_______________________________________________
Toybox mailing list
Toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn< at >public.gmane.org
http://lists.landley.net/listinfo.cgi/toybox-landley.net

[CLEANUP] Next ifconfig pass (commit 905)

Rob Landley — 2013-05-19T16:44:40

Cleaning up ifconfig, commit 905:

   http://landley.net/hg/toybox/rev/905

get_strtou() isn't actually needed: it's a wrapper for strtoul() that's  
only ever called once. It sets most of its effort setting errno, but  
all you need to know is that the endptr from strtou isn't the end of  
the string. So the one and only caller can just become:

+    unsigned long p = strtoul(s, &ss, 0);
+    if (*ss || p > 65535) error_exit("bad port '%s'", s);

Using the libc function, and then get_strtou() can go away.

Two more functions, is_host_unix() and get_host_and_port(), are only  
ever called from one place, both in get_sockaddr(). so inline both of  
them.

The is_host_unix() logic only triggers if host starts with "local:", so  
wrap the function's guts in a big if() for that. The rest of the  
function is mostly the same except that swl is just a pointer instead  
of a pointer to a pointer, so dereference one less level.

Next we have the get_host_and_port() plumbing, which is a bit tricky  
for me because I

--help option.

Rob Landley — 2013-05-18T06:36:45

A while back I jadded --help to the toybox multiplexer (as an alias for  
the "help" command), so at least busybox people confused by that would  
have less of a hard time.

I'm trying to figure out if I should just make --help be understood by  
all commands, but...

1) Not everything uses the option parsing infrastructure. "true --help"  
wouldn't do anything if lib/args.c is doing it. I could instead have  
the toy_exec() check for "--help" as one of the arguments, and run help  
instead of the command in question. (Should it check for it as the  
_first_ argument? Sigh, it's uncomfortably magic either way...)

2) This raises the possibility that "ls *" will get confused if a file  
in the current directory is called "--help". Then again, that may  
already be the case...

Rob

Re: add groups implementation to id.c

Rob Landley — 2013-05-19T03:34:11

Looks good to me. (And you're right, loopfiles() is wrong.)

Applied, with minor fixup for a whitespace conflict (I wordwrapped a  
line),

Thanks,

Rob

Re: Would you consider adding showkey...but

Rob Landley — 2013-05-17T05:06:38

So it's the catv logic with newlines?


I dunno what that means. (I honestly haven't used this command.)

I would, however, like to golf clap at the FSF for  
/usr/include/*/sys/kd.h:

/* Copyright (C) 1996, 1997, 2005 Free Software Foundation, Inc.
    This file is part of the GNU C Library.

    Ash nazg durbatulûk, ash nazg bananaphone,
    bananaphone thrakatulûk agh burzum-ishi bananaphone.

    In the land of Mordor, 59 Temple Place, Suite 330, Boston, MA
    02111-1307 USA.  */

#ifndef _SYS_KD_H
#define _SYS_KD_H       1

/* Make sure the <linux/types.h> header is not loaded.  */
#ifndef _LINUX_TYPES_H
# define _LINUX_TYPES_H         1
# define __undef_LINUX_TYPES_H
#endif

#include <linux/kd.h>

#ifdef __undef_LINUX_TYPES_H
# undef _LINUX_TYPES_H
# undef __undef_LINUX_TYPES_H
#endif

#endif  /* sys/kd.h */

Yes, they didn't even bother to block copy out the linux/kd.h contents  
but instead #include the file for you and #undefine its header guards  
after the fact.

What on EARTH this file exists

Re: add groups implementation to id.c

Ivo van Poorten — 2013-05-17T13:13:12

Thanks!


Okay, so I left it as it is now (i.e. username : groups...) for when a
username is specified.


I did it slightly different because the arguments are not files (see
attached patch). Perhaps this could move to lib.c as loopstrings() or
something in the future, although I'm not sure if it's worth it.

Regards,
Ivo
_______________________________________________
Toybox mailing list
Toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn< at >public.gmane.org
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: Would you consider adding showkey...but

Isaac Dunham — 2013-05-15T21:29:25

On Wed, 15 May 2013 11:32:28 -0500
Rob Landley <rob-VoJi6FS/r0vR7s880joybQ< at >public.gmane.org> wrote:


showkey is intended to be used from a VT, not X.
It reads a keypress (apparently from /dev/console), then prints its
keycode/scancode. 
One implementation is esr's showkey, http://catb.org/~esr/showkey/
(which is MIT license, weighing in at 127 lines including whitespace
and comments).
There is also a (1993?!) GPL2+ Debian variant that corresponds to what
busybox has.

Also, timeout=0 may be tricky if you need to wait some time for a
keypress...

Re: Would you consider adding showkey...but

Rob Landley — 2013-05-15T16:32:28

Um, details?

I don't think I've ever used busybox showkey, but I'm happy to look at  
patch submissions. (I may be a little overwhelmed with _dealing_ with  
them, but I'm working as fast as I can. Still chewing on ifconfig when  
I have time, and then mount's queued up right after that...)

Let's see, fire it up in an xterm and see what it does:

landley< at >driftwood:~$ ./busybox-x86_64 showkey
showkey: KDGKBMODE: Invalid argument
                                     landley< at >driftwood:~$

And it left my terminal in raw mode. Very nice. My static busybox lying  
around is 1.19.0, maybe they've fixed this since then? Git log on  
showkey.c says last touched in 2011, so I'm guessing no. Maybe it  
doesn't like xfce's terminal program? Dunno...


Send me a patch?

Thanks,

Rob

Re: new toy: lsusb

Rob Landley — 2013-05-15T05:20:27

You're way ahead of me. :)


If the file exists at /etc/usb.ids we could parse it, but since you  
found info provided by the drivers, using that makes sense.


I fiddled with this code earlier this evening, so the patch doesn't  
apply. I can adapt this to what's currently there but it's after  
midnight, so probably tomorrow.


Thanks,

Rob

Would you consider adding showkey...but

scsijon — 2013-05-15T01:04:33

Would you consider adding the busybox showkey, but with a user set time 
including 0 for immediate, rather than the default 10 seconds?

We wish to add the ability of checking a <ctrl>, <alt>, etc. key in the 
init and control the response depending on the keycode for function, 
rather than expect them to wait 10 seconds each time.

thanks
scsijon

Re: new toy: lsusb

Rob Landley — 2013-05-15T05:08:42

I fixed this while offline by only using entries that had all three of  
the lines of interest. It's currently producing the correct result on  
my test system, although that doesn't mean much...


If DEVTYPE=usb_device is the correct check for this, I'm happy to  
change the code again. I'm just not hugely familiar with the domain  
here, I'm not sure what the code is trying to accomplish. (What are the  
usb_interface entries for? I should plug in some random devices and see  
what I can get, but )

Also, the human readable text part of this comes from  
http://www.linux-usb.org/usb.ids so in theory we could add a config  
option to either look for that in /etc/usb.ids or include a digested  
version of it in the binary, and output human readable info. (I dunno  
what license the file has though.)

Not a huge deal, just potential future expansion...


Linux and android are the systems I'm targeting. I'm not purposely  
excluding others, but I'm not really paying attention to them either. I  
did a video a

Re: new toy: lsusb

Andre Renaud — 2013-05-15T05:06:09

As a separate feature (I'm not suggesting we actually use this patch),
lsusb is supposed to parse /usr/share/misc/usb.ids to get readable
names for devices. Obviously for space reasons we don't want to use
this file. However most devices identify themselves with some kind of
readable string, so alternatively we could just display these strings
to the user. Not all devices have this information, but it's pretty
low overhead. Attached is a patch which adds this functionality. On my
PC it gives moderately useful information about most of the normal
peripherals, however some of the internal ones are a bit useless.

I re-instated readfile as a convenience.

Regards,
Andre
_______________________________________________
Toybox mailing list
Toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn< at >public.gmane.org
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: Commit 897: size reduction, and new warning

Rob Landley — 2013-05-15T01:44:42

No, that's what I was working on the first time I mothballed the  
project.

The tricky bit is I was making both mke2fs and gene2fs in the same  
code, and making it work like an archiver so I could point it at a  
bunch of files and have it spit out an ext2 image that you could pipe  
to gzip. This turns out to be hard because you need to do two passes,  
the first precalculating the metadata (so you know where all the block  
allocations go) and the second writing out the actual contents. Doable,  
but really fiddly.

There was also sparse inode allocation stuff that eventually turned  
into ext4, and I got distracted with other things. (Aboriginal wasn't  
near 1.0 yet. The toybox relaunch happend _after_ Aboriginal was at the  
"does what it says on the tin" stage. Yeah there's a whole follow-up  
project making it bootstrap debian and fedora and gentoo and such, but  
I haven't really opened that can of worms yet...)

But I did most of the research and design work. Now I just need to find  
time to imp

Re: new toy: lsusb

Andre Renaud — 2013-05-14T23:27:24

Hi Rob,

On 15 May 2013 11:06, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ< at >public.gmane.org> wrote:

You're right, relying on the order is a terrible idea (although it is
what busybox does). I'm also not too keen on using a filename wildcard
(although it's better than the ordering). However attached is a patch
that instead only lists DEVTYPE=usb_device entries.
Looking at the Linux code, these DEVTYPE entries appear as a result of
calling device_initialize with something that has it's 'type' set,
which only happens twice in the USB subsystem - once for 'usb_device'
and once for 'usb_interface'. I haven't looked closely, but I assume
that if they shuffle the order of the code within there, the
first-line assumption will be invalid. So it's better this way.

As a separate aside - what is the story with toys like this that are
strictly Linux only - is toybox a linux-only project, or are they just
tagged separately?

Regards,
Andre
_______________________________________________
Toybox mailing list
Toybox-oU9gvf+ajc

Re: new toy: lsusb

Rob Landley — 2013-05-14T23:06:41

Very nice. (Applied.)

Is there something special about the entries that have DEVTYPE= as the  
first line? Depending on the ordering seems darn subtle here. I did a  
quick:

   for i in /sys/bus/usb/devices/*/uevent; do echo $i; cat $i; done

And for example:

   /sys/bus/usb/devices/usb4/uevent

Has DEVTYPE= as entry #4, but will be skipped because it doesn't come  
_first_. (This matches what the host's lsusb is doing, but strace never  
has it opening uevent.)

It looks like the displayed devices are filenames [0-9].*:.* so starts  
with a digit, contains a colon?

Rob

Re: Commit 897: size reduction, and new warning

Isaac Dunham — 2013-05-14T13:38:08

On Mon, 13 May 2013 23:15:48 -0500
Rob Landley <rob-VoJi6FS/r0vR7s880joybQ< at >public.gmane.org> wrote:



Oops, I think I forgot that I built the first one static with musl and
the second shared.
 

Sounds much more reasonable.


This is a custom config including everything I find useful (find xzcat
ifconfig stat, IIRC-on a different laptop right now, so not certain) as
well as pretty much all of defconfig. 
toysh is not included for obvious reasons, and I didn't enable  mke2fs
this time-is it functional?


Ah, thanks for clarifying.

new toy: lsusb

Andre Renaud — 2013-05-14T05:56:00

Hi,
Attached is a pretty simple implementation of lsub. It doesn't
implement any of the flags/options, but does the raw output. I believe
this is essentially the same functionality as what is available from
busybox.

Regards,
Andre
_______________________________________________
Toybox mailing list
Toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn< at >public.gmane.org
http://lists.landley.net/listinfo.cgi/toybox-landley.net