mdev

[Vladimir Dronnikov]

>
> So you want them to share code, but not worry about a speed/functionality
> tradeoff between two different users of the share code which have conflicting
> goals. And you believe refactoring will achieve this...

I want to not touch "mdev -s" branch. I want to add some lines of code
to _hotplug_ part. If the code of mdev as whole is considered stable
enough, I just proposed to not touch mdev and make another tester
applet. Just that I meant.

>>
>> I meant speed here is not of my primary concern. And you here do not
>> concern of missing events, right?
>
> I don't understand what you mean there.
>

Simple. "mdev -s" doesn't enumerate /sys/devices/*. Some devices

>
> Serial ports have dev entries ...
>

... if modules are loaded (8250*.ko, serial_core.ko). You never see
/dev/ttyS* unless you load these modules. And to load them you either
need to issue modprobe "by hands", or (as I propose) rely on
enumerating /sys/devices/* and $MODALIAS suport in mdev hotplug. The
latter approach I treat more generic, and am trying to push it
upstream.

> ...network interfaces never did.

Except tun/tap/bnep/...

>
> Right now, if you haven't got _either_ a device name _or_ a major/minor to
> match on (neither of which you have if you have in the absence of a device
> node), then there's no way for the current config file to identify the device
> and thus attach behavior to its events.

Wrong. Hotplug events have $SUBSYSTEM. We can match, say, network
devices by using, e.g.:
net/.* - - @netif

> ...you don't need to modify mdev for this. The original hotplug userspace
> infrastructure the kernel guys came up with _was_ a shell script.

Yes. But I'd like standard solution to be used: mdev is good enough,
and with the patch applied match exactly my needs.

> Too late, they already made solar sad when they ...

Another reason and good chance to put mdev under microscope and adjust
its assumptions.

>
> If FIRMWARE support should be in the C code (instead of a wrapper script that
> calls mdev at the end), the MODALIAS support should be too.
>

That is right.

> That said, what's wrong with something like (off the top of my head,
> untested):...

Nothing's wrong. This wrapper should then be thouroughly tested,
documented and placed into ./examples so users can use it. But this
requires deletion of $FIRMWARE code from mdev.c and still changes mdev
behavior. But if we _do_ change it, why not to add a configurable (#if
ENABLE_) code for $MODALIAS?

>
> I.E. is it really _necessary_ to add this sort of thing to mdev?  Or can't you
> just have a hotplug shell script that falls _back_ to mdev once it's figured
> out it isn't doing something else?  (This doesn't affect the mdev -s path at
> all, this is just the script getting called as the hotplug event and calling
> mdev as necessary.)
>

See above.

> Simplicity, not purity.  And it's not a sacred cow, I'd just like to make sure
> there isn't a _better_ alternative.

A better alternative is IMHO a _solid_ hotplug helper capable of
matching against environment variables (for they are the primary
source of the event info). Then mdev can be used as simple, uniform
and centralized device management tool.

Regards,
--
Vladimir