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
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
