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
