RFD: Rework/extending functionality of mdev

[Harald Becker]

On 12.03.2015 18:12, Laszlo Papp wrote:
> 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.

If you talk about development and testing, yes ... but my need is a one 
system one static binary approach ... and I really want to put in that 
extended functionality ... so running it as a separate project would 
mean to fork the Busybox project ... public or private, does not matter 
here ...

... I have an idea, to those preference questions ... may be it is of 
general interest ... could even reduce some development pressure from 
Denys ... may be ... but let me check some details, before I write a 
message in a new thread for this, to see what other think about it ...


> 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.

... and I go the different way, hook up a complete system with a single 
statically linked binary (ohps currently two, Busybox and dropbear) ... 
though, peoples preferences are different ... I try to do not force 
anybody else to do things in a specific way, but I don't want to be 
forced by others ... and I dislike placing that stuff in (a) different 
file(s), except for a very good reason (e.g. minimalist memory usage on 
plug helper, and daemon - but that has to be discussed)

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

Peoples preferences are different, but when blocking every innovation in 
Busybox you force me to do things in your way! ...

... so my possibilities would be: Either forking Busybox project or 
dropping all my development forever ... both not very welcome! :(

And don't ask! It's preference, not technical, or knowledge ...

And why grumbling about a few bytes on one hand, and then throwing in 
other stuff? The netlink functionality has been requested by others to, 
but I see there are people who like to stay at kernel hotplug mechanism, 
or even semi automatic device setup, so why shall we not enable the base 
functionality for all of them, with maximum code sharing, so user may 
decide which function to use or possibly opt out on config? Otherwise I 
do not want to break existing setups, but was poked to clarity, that is 
splitting of functions which do logically not belong into separate 
commands ... no trouble for me to do this, but then we may need to do 
some slight modifications to startup scripts (one or two lines or 
command parameter) ... everything has it's pros & cons ... even writing 
lengthy mails ... which consume the time I could otherwise use for 
development ... :(

--
Harald