Hi !
To Michael:
Don't be confused, Natanael provided an alternative version to achieve
the initial device file system setup (which isn't bad, but may have it's
cons for some people on small resource constrained systems of the
embedded world). So I left it out for clarity ... but still may be
implemented / used as an alternative method for setup.
To Natanael:
On 12.03.2015 10:14, Natanael Copa wrote:
- The third method (scanning sys file system) is the operation of "mdev
-s" (initial population of device file system, don't mix with "mdev" w/o
parameters), in addition some user take this as semi automatic device
management (embedded world)
I disagree here. mdev -s solves a different problem.
No.
there are 2 different problems.
1) handle hotplug events.
>
There are only 2 methods for this problem:
A) using 1 fork per event (eg /sbin/mdev
in /proc/sys/kernel/hotplug). this is simple but slow.
This is "mdev" (without any parameters).
B) reading hotplug events via netlink using a long lived daemon.
(like udev does)
Currently not in mdev, but shall be an alternative mechanism in my
implementation, so you may chose and use the mechanism you like.
2) do cold plugging. at boot you need configure the devices kernel
already know about.
This is the operation of "mdev -s"
B) solve problem 1 mentioned above (set up a hotplug handler)
and then trigger the hotplug events. Now you don't need scan the
sysfs at all.
But still there are people in the embedded world, who like (or are
forced) to use semi automatic device handling, that is calling something
like "mdev -s" to scan sys file system for new devices.
My approach is to give them all the possibility to device management
withe mechanism they like, without maintaining different device
management systems and duplicating the code.
Three different mechanisms, with three different front end's, and one
shared back end.
... the only thing I see is a difference in initial device system
population. You provided a different method to trigger the coldplug
events (and yes, I understand that approach), but that one will only
work when you either use the kernel hotplug helper mechanism, or the
netlink approach. You drop out those who can't / doesn't want to use either.
I left that out in the "short" summary for Michael, but didn't forget
your hint. May be we can have an additional alternative for the setup
part, implementing event triggering (still we do the sys file system
scan, but with different handling then) ... or you do it in scripting,
setup your hotplug handler or netlink listener and then run a script to
trigger the plug events (nice idea otherwise, I like it, but won't
unnecessary drop people on the other end).
What I currently do is:
- for problem 1 (dealing with hotplug events) I use method A.
- for problem 2 (set up devices at boot) I use method A because my
hotplug handler is slow due to many forks.
What I would like to do is switch to method B for both problem 1 and
method B for problem 2 too. However, I want the long lived daemon
consume less memory and i want be able to use the mdev.conf syntax for
configuring the devices.
No problem, my approach shall give the possibility to do it the way you
like, without blocking the others. Still you need to do the following
steps on system startup:
- initial creation of the device file system (out of scope of mdev)
- prepare your system for hotplug events, either kernel method or
netlink (if you go that way)
- trigger initial device file system population (cold plug)
(may be done in two ways, yours or the old "mdev -s")
- So how can we have all three methods without duplication of code, plus
how can we speed up the kernel hotplug method?
IMHO, there are not 3 methods so the rest of discussion is useless.
You are going to force others to do it the way you like and everything
other is of no interest?
I'm trying to give most people the possibility to do it the way they
like, your way inclusive! ... without blocking other methods (or may be
external implementations with reusage of conf / handling back end).
... as other functions in BB, unwanted functionalities may be opted out
in build config.
... so this would mean for you: Include the back end and the netlink
into your Busybox, do the usual device file system creation, activate
the netlink handler (shall auto start the fifo watcher), then trigger
cold plug events (undiscussed if done with script or added to binary).
Anything wrong with this?
--
Harald
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
