Hi Michael ! On 11.03.2015 22:44, Michael Conrad wrote:
I'm interested in this thread, but there is too much to read. Can you explain your reason in one concise paragraph?
One paragraph is a bit to short, my English sucks, but I try to summarize the intention of my approach in compact steps (a bit more than one screen page of text):
- current kernel hotplug based mdev suffers from parallel start and reading / scanning the conf on each instance
- the known and proven solution to this is using a netlink reader daemon (long lived daemon which stays active all the time)
- there are still people who insist staying on the kernel hotplug feature (for whatever reason, so accept we need hotplug + netlink)
- 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)
- So how can we have all three methods without duplication of code, plus how can we speed up the kernel hotplug method?
- answer is to split the gathering parts from the conf file parser and device operation, plus let the parser / handler accept many events with one invocation (event bursts), plus saving memory when event system is idle (parser process exits when idle for some duration)
- kernel hotplug helper could fire up the fifo and a parser / handler when there is one required, but this check adds extra delay / cost on first / all delivered events
- solution is a minimalistic fifo watcher and parser startup daemon (proven Unix concept for on demand N to 1 inter process communication), the fifo watcher creates and hold the fifo open, but never touches data in the fifo, only startup a parser when required, allows failure management when parser sucks
- now the system maintainer can decide which method to use, unwanted methods may be opted out on BB config, plus easier embedding BB based device management from external programs (include parser, drop methods)
- beside the netlink code, after rework I expect a near 1 : 1 average of binary size compared to current code, but less memory usage on event bursts (only one parser process), plus speed improvement on event bursts (faster system start up when using hotplug)
- other intended functional improvements are for personal preference to get the ability of a one-shot device file system startup (single command to setup all device stuff, still under full control of admin, no hard coded functionality in any binary)
And last: Don't stick on the "mdev -..." names mentioned, look at the intended functionalities, implementation details (names to use) are still under discussion.
Hope that was short enough. -- Harald _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
