RFD: Rework/extending functionality of mdev

[Laszlo Papp]

On Thu, Mar 12, 2015 at 6:00 PM, Harald Becker <ralda at gmx.de> wrote:
> Hi Laszlo !
>
>> So why don't you write such a binary wrapping busybox then and other
>> things? I think KISS principle still ought to be alive these days.
>> Not to mention, Denys already cannot cope with the maintenance the
>> way that it would be ideal. For instance, some of my IMHO serious
>> bugfixes are uncommented. Putting more and more stuff into busybox
>> would just make the situation worse and more frustrating,
>
>
> The usual way of development is:
>
> (1) Planning the work to do (the step we are discussing here)
>
> (2) Code hacking (what I will do next)
>
> (3) Preliminary Testing (also mine job)
>
> (4) Offer access to those who like (for further testing)
>
> (5) fixing complains
>
> (6) putting into main stream (or accessible by the rest)
>
> Right? So what is your complain?
>
>
>> sorry. I really do not want busybox to follow the systemd way.
>
>
> Who told you, I'm trying to go that way. My intention is to overcome the
> mdev problems, and allow those who like to use the netlink interface. I
> dislike encoding any fixed functionality in a binary, and don't force
> anybody to use possible extensions.
>
> Laurent poked me to more clarity, which would mean to split early
> initialization from mdev operation, with the cave eat of a slight change in
> init scripts (may be one more command or some extra
> command parameter, could be done automatic, but than different
> functionalities in applet - may be more discussion required on that). Beside
> that, it's shall be up to the system maintainer, to chose which device
> management mechanism to use (BB shall provide the tools for that, small
> modular tools, bound together by admin - no big monolithic).
>
>
>> On the positive side of systemd, they at least have far more resource
>> than what Denys can offer, at least in my opinion, so ...
>
>
> You are talking about development resources? Here they are! I'm willing to
> do that job, not asking for someone else doing the work.

It is not only about feature development resources, but also
maintenance. Denys will be the maintainer for new busybox code as far
as I am aware. I have not seen this model changing for a very long
while, sadly.

Once, I tried to ask for changing that model, but I was apparently
just shooting myself in the foot based on the feedback.

It is nice that you are trying to help and I certainly appreciate it,
but why cannot you simply do that job nicely outside busybox where
*you* have to be responsible for that project? It would be an explicit
way of enforcing KISS and not putting more burden on Denys.

He may enjoy maintaining more and more code, but in all honesty with
due respect and appreciation, I do not enjoy when developers do not
get response for their patches and they kind of all depend only on
Denys with regards to upstreaming.

It is also a bit demotivating that we do not get early feedback and
then we realize that our patches are completely reworked by Denys. It
is unfortunate that our work almost goes to /dev/null. I do not feel
appreciated.

This is all happening because of more and more complex stuff to be
maintained by one person. It is not a personal offense against Denys
to be fair. It is a model I very much disagree with in general.

If you can convince the busybox community to split up the
maintainership, perhaps that would be a completely different
discussion to start with, but in all honesty, I do not like these
"monolythic" projects. I still stick by that KISS is a good thing. If
I could, I would personally replace busybox with little custom tools
on my system, but I currently do not have the resource for that.
Therefore, all the complexities and non-kiss that goes in is something
I need to accept.

>
> I'm asking about, which preferences other people have, so I'm able to get
> the right decisions, before I start hacking code ... so what's wrong?

Asking for feedback is good, nothing wrong in there; putting this into
busybox this way is wrong on the other hand IMHO.

>
> --
> Harald
>