Re: [Toybox] Pondering mdev...
On 08/20/2013 11:24:59 PM, Isaac wrote:
On Tue, Aug 20, 2013 at 03:08:37PM -0500, Rob Landley wrote:
On 08/19/2013 11:13:15 PM, Isaac wrote:
Hello,
I've noticed that in mdev coldplug (mdev -s) is supported, but
hotplug is
TODO.
I also note that an optional (busybox) fourth field is not
supported.
This is dir/ to link or =dir/ to move the device into /dev/dir/;
mice root:root 0766 =input/
#creates /dev/input/mice
is one example.
Without these mdev creates a flat directory not grouped by
subsystem.
I'm thinking about poking at mdev and seeing if I can add these
features.
Any thoughts on this (higher priorities, hints as to how to
proceed)?
These days mdev should depend on devtmpfs being there, so I'm not
sure how much is left for it to do. That handles populating the
directory, making entries show up and go away, getting permissions
and even ownership right (albeit for a hardwired list of uid/gid
that Greg KH thought was a good idea). The kernel is now handling
firmware loading.
Unless you have to use an older kernel (I'm using 2.6.32 on one
computer
because ath5k doesn't work and madwifi-hal is the only driver that
does,
but it's abandoned now),
While I'm somewhat sympathetic with that, it's something that's going
to decrease in importance over time. These old systems didn't ship with
toybox, and if you can upgrade them with toybox but _can't_ upgrade
them with a new kernel, that strongly implies end of lifed hardware...
want to use different permissions/gids, need to load
firmware for a proprietary driver (IIRC, the kconfig entry for
userspace
firmware loading claims that out-of-tree drivers need a hotplug
helper;
of course I haven't tested),
Could be.
I'm not saying there's no role remaining for mdev, I'm saying I don't
know what that role is. If you have a better idea of the requirements,
feel free to take point on this. (One thing I need to understand and
don't is the udev/eudev split. What's the role for _eudev_ that
devtmpfs doesn't do? The kernel guys were clearly aiming to obsolete
udev to work around Kay Sievers after Linus chewed him out...)
or you use a set of paths that doesn't match the kernel default.
I agree you'd need a tool for that. I don't understand _why_ you'd want
to do that, though. (Do you need a different set of paths under /proc
or /sys and a tool that will adjust those? Why is /dev different when
it's a kernel filesystem?)
At the design level: what is mdev needed for?
The biggest reason to have a hotplug helper now is to autoload
modules.
According to kernel/kmod.c function call_modprobe() the kernel will call
/sbin/modprobe -q -- $MODULE_NAME
So this isn't a hotplug event going to mdev, this is a
call_usermodehelper_exec().
I guess that means modprobe is higher up.
(Do we want to use depmod when we use modprobe? The alternative is
doing a
file-by-file search, which is more complicated.)
I suspect we need the functionality, and that funky char-major-%d-%d
aliasing. That's the main difference between insmod and modprobe.
Needing a separate demod database is iffy, presumably scanning a config
file and the modules to find the right things to load shouldn't be that
hard to do at runtime. (After the first module they should be cached...)
I'd prefer properly parsing ELF rather than strings-style scanning,
though. But as long as it works. (Not an existing area of expertise for
me, I build static kernels when feasible...)
And a different hotplug helper might be in order; shell-wise, someone
might use something vaguely like this:
#!/bin/sh
[ -n $MODALIAS ] { modprobe -bq $MODALIAS ||
env /var/log/nodriver }
#Read from disk to trigger enumeration of partitions-is this still
needed?
if [ -n ${DEVNAME} -a -n ${DEVTYPE} ]
case $DEVTYPE in
disk)
dd if=/dev/$DEVNAME of=/dev/null count=1
;;
*) ;;
esac
fi
For toys/pending/nbd_client.c I just had to open the device to force
partition table scanning, didn't actually have to read from it...
Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] Fwd: [New Toy - patch] add ps watch
On 08/21/2013 06:47:34 AM, David Seikel wrote: On Wed, 21 Aug 2013 02:11:39 -0500 Rob Landley r...@landley.net wrote: On 08/20/2013 11:15:42 PM, David Seikel wrote: On Tue, 20 Aug 2013 15:55:24 -0500 Rob Landley r...@landley.net wrote: On 08/20/2013 04:46:20 AM, Ashwini Sharma wrote: Hi Rob, Attached are the patches for _watch_ and _ps_ command. Sent _ps_ again, just in case you lost the last one. This one also have a copyright update. I planned to do watch.c after doing less.c because both have the similar printing a chunk of a larger screen logic. If your command output produces too many lines, it shouldn't scroll off, but given that it can wrap around to produce more lines, you can't just count lines. For example: watch 'python -c print 100*\abcdefghijklmnopqrstuvwxyz\' This version just scrolls off. It doesn't capture the output and make an attempt to format it. But toybox needs that logic for less, more, vi, editing command line history... I've been thinking about what you said before about my large editor and screen handling blob. I think I have found a way to at least make one or two much smaller blobs to help ease it into toybox. Finding the time to get to it is a problem we are all too familiar with. I'll get there, I want to actually use it myself. I note that busybox gets this wrong (their watch shows all output each time, scrolling the screen at length for watch ls -lR /), so it's an easy mistake to make. But I want to be _better_ than busybox. Busybox's less also just dumps it all in one go if I remember. Yeah, less needs to do progressive disclosure, which means a select loop responding to new lines of output _and_ user keyboard input at the same time... Also, this is one of them damn fiddly bits whith asynchronous ascii probing of screen size as part of interactive input, responding to dynamic window resizing (keeping in mind that sigwinch won't propogate over a serial port), fixing it so the shell notices when it's not starting at the left edge (in bash echo -n walrus screws up editing of the following line; at one point busybox ash got that right because I complained), That's the first thing I want to do as a single smaller patch, sorting out the various terminal size fiddly bits. I had noticed when I was looking at it last time that I've not completely sorted that out anyway, but I was close. that fun bit about collating escape sequence input while also allowing escape by itself to put vi into command mode (I used 1/3 of a second timeout)... That bit I got solved, also with a time out. Seems the only way. That's what I implemented in busybox. :) Where's your current code for this? Maybe I have time to look at it now... Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] grep corner cases
Rob Landley wrote: On 08/20/2013 12:29:08 PM, Felix Janda wrote: Rob Landley wrote: On 08/19/2013 02:26:55 PM, Felix Janda wrote: Hi, I saw the comment in changeset 1017 on possible bugs in GNU grep. The failing tests are for me: testing grep -vo grep -vo one input two\nthree\n onetwoonethreeone\n testing grep -Fx '' grep -Fx '' input one one one\n one one one\n testing grep -F -e blah -e '' grep -F -e blah -e '' input one one one\n \ one one one\n -o is a GNU extension making grep only output the matched parts of each matched line. So since -v inverts the set of all matched lines grep -vo should not output anything. Does it invert the set of matched _lines_, or does it invert the match criteria? I made it so that: -v Select lines not matching any of the specified patterns. If the -v option is not specified, selected lines shall be those that match any of the specified patterns. Does sound to me like the former. This fits the line based nature of many of the POSIX tools. It however doesn't make grep -vo very useful. Posix does not have the -o option. The -o option is not line based. This is about the effect of other options on the -o option. Since you still can't match things spanning lines -o doesn't seem to make grep into a byte based tool. What should echo on | grep -vo a output? If you say that the sense of matching is inverted shouldn't the output be o n on or some permutation thereof? The current output of toybox is pretting interesting... echo oneandtwoandthree | grep -ov Shouldn't it be echo oneandtwoandthree | grep -ov and Yes. would produce: one two three (I pondered onetwothree but that's not how -o without -v works...) The reason there are deviating test cases to consider is I'm not taking what gcc does as an inherent definition of the right thing to do. But maybe it's a reason to spend some thought on the validity of the test case and maybe do some testing against other implementations. For example busybox grep also doesn't output anything. What other implementations? -o is a gnu/dammit extension. Did you read the last paragraph you are quoting carefully? Just FYI: obase doesn't contain grep. That implies that echo one | grep -F -e walrus -e '' Should match one, but with the gnu/dammit version it only does so _without_ the -F. Or with -F and just one argument... busybox grep also agrees with you. And it's inconsistent: $ echo hello | grep -F -e '' hello $ echo hello | grep -F -e 'one' -e '' $ echo hello | grep -e 'one' -e '' hello (That's pretty clearly a bug. If you're wondering why I'm not slavishly copying gnu/dammit behavior it's because they're not very good at this. They've just had a very large testing base reporting bugs for a very long time.) I don't care specifically about the GNU version. With GNU grep lying in /usr/bin it's just too convenient to run tests against it. Combined with -x IMO it should only match empty lines. I asked the Austin guys how -F and -x interact. It's not obvious to me from reading it. Sounds like a good idea. They said -x nukes '' being a wildcard (which matches the non-F version of the gnu/dammit behavior), but BSD gets it wrong: http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/7923 Thanks. Rob Felix ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
