:: Re: [Dng] Purpose of all this compl…
Top Page
Delete this message
Reply to this message
Author: Isaac Dunham
Date:  
To: karl
CC: dng
Subject: Re: [Dng] Purpose of all this complicated device management?
On Sat, Jan 17, 2015 at 08:06:05PM +0100, karl@??? wrote:
> Gravis:
> > karl, what's with the hostility?
>
> Oh, maybe it come out to harsh, sorry for that.
>
> > vdev is by no means required and
> > nothing depends on it, so nobody is being forced to even install it.
> > also, since it is based on FUSE, it won't actually add/remove static
> > device files, so when the program exits, it will go back to your
> > static device files. you can set rules in the vdev config file so
> > that you can make devices behave as you wish. vdev is still in
> > development, so no behavior is set in stone and can updated for new
> > situations as they are discovered/reported.
>
> I think I was mostly talking about udev, or rather about people who
> don't accept that some users actually don't need udev.
>
> ///
>
> One use case I could find useful is to have an xdev that I could
> run from-time-to-time to check if I'm missing something in /dev.


For what it's worth, I've used "busybox mdev -s" for this purpose.
Note that it *creates* devices, rather than outputting a list of
filenames with attributes.

> Also a lib that maps major/minor to /dev/name and the like, a command
> that "scans lspci" and the like, and suggests kernel modules,
> which I then at my own discretion can add to /etc/modules.
> I.e. an udev that instead of taking over the system, gives me some
> tools I could use to examine a system.


To map major/minor/devtype to /dev/name (note: /dev/zero has the same
major/minor as /dev/ram5; one is char, the other is block) you really
need to recurse through /dev and find the first file that matches.

I could write a non-threadsafe version of said function using nftw()
in a day, I suppose; if I lift the dirtree code from toybox and patch
it to fit, it might be not be much more work...

So does "libsysdev" sound like a good name, and
char * sysdev_getdevname(int major, int minor, int ischar);
seem like a good prototype?


Your proposed command that would "scan lspci" is roughly equivalent to
either of these command lines:
find /sys -name modalias | xargs sort -u | xargs resolve_modalias
find /sys -name uevent -exec sed -ne 's/^MODALIAS=//p' + | \
    sort -u | xargs resolve_modalias


where resolve_modalias is a command that finds all entries in
/lib/modules/`uname -r`/modules.alias expanding to match each
argument.
Sample:
$ resolve_modalias pci:v00008086d000027D8sv00001025sd0000015Bbc04sc03i00
snd_hda_intel

I've implemented resolve_modalias in the past, and there have been
similar commands written elsewhere.


But really, your requests are very close to the standard usage for mdev.
Substitute "modprobe -abq" for "resolve_modalias", and the command line
above is the standard way to autoload drivers.

> Regards,
> /Karl Hammar


Hope this helps,
Isaac Dunham