RFD: Rework/extending functionality of mdev

[Harald Becker]

Hi Denys !

 > mdev rules are complicated already. Adding more cases
> needs adding more code, and requires people to learn
> new "mini-language" for mounting filesystems via mdev.
>
> Think about it. You are succumbing to featuritis.
> ...
> This is how all bloated all-in-one disasters start.
>
> Fight that urge. That's not the Unix way.

Yes! ... my failure to mix those things without giving an explanation. 
Laurent pointed me to the better approach and gave the explanation, the 
idea is to have a one-shot point of device system initialization ... 
that means those device system related operations, and may be depp 
system related virtual file systems (proc, sys, e.g.) ... I even exclude 
things like setting up a tmpfs for /tmp from this, also it could be done 
with no extra cost.

My previous message to Natanael and Isaac shall clarify my approach and 
should have been the starting point of this discussion ... which is as 
told at the early phase of brain storming about doing a rework of the 
Busybox related device management system, eliminating the long standing 
problems, giving some more flexibility, and may be adding some more 
functionality of benefit for those who like them (not blocking others).

Though, RFD means request for discussion, not for hacking code in any 
way, before we reached a point of agreement ... and at least some 
problems of mdev has already been grumbled about, as I remember ... so a 
discussion, giving the chance to do the work to overcome those issues 
... Adding (some) extra functionality is to enhance flexibility (where I 
focused on the parts, I'm most concerned with - peoples preferences are 
different), but only part of the work I like to do.

I tried to stay as close as possible at the current mdev.conf syntax, 
with the intention not to break existing setups ... but would not 
neglect, creating a different syntax parser, if this would be the 
outcome of the discussion. I'm open to the results, but like to get a 
solution for my preferences, too. Can't be that a few people dictate how 
the rest of the worlds systems has to handle things ... the other side 
of what you called "featuritis" (I won't neglect your statement above)!

And one point to state clearly: I do not want to go the way to fork a 
project (that is the worst expected), but I'm at a point, I like / need 
to have Busybox to allow for some additional or modified solutions to 
fit my preferences, as others also have also stated already. I'm 
currently willing and able to do (most of) that work, but if it's not 
welcome, the outcome of the discussion may also be stepping to a 
"MyBusybox" (or however it will be called).

*Again*: I don't want to start a discussion about forking the project, 
it would be the worst possible outcome of my intention ... I like to get 
a tool set based on BB's principles, but giving more flexibility to fit 
more peoples preferences, without breaking things for others (at least 
the majority)! ... this means critical discussion of every belonging 
topic, but not blocking every new approach and functionality with the 
argument of size constraints or "featuritis", due to personal dislikes, 
and then accepting a patch which add several hundred of bytes for 
functionality I expect to be pure nonsense or "featuritis".

I apologize for my hard words. I don't want to hurt you or anybody else, 
but you did several decision in the past, which resulted in immense 
frustration to me (and others). With the consequence of even halting 
development of several BB focused projects ... please consider more 
opening to the discussion, based on topics not on pure criticism or 
personal liking (don't want to initiate lengthy philosophical quarrels 
with no practical outcome).

--
Harald