RFD: Rework/extending functionality of mdev

Laszlo Papp lpapp at kde.org
Thu Mar 12 09:45:07 UTC 2015


On Wed, Mar 11, 2015 at 7:02 PM, Harald Becker <ralda at gmx.de> wrote:
> On 11.03.2015 16:21, Laurent Bercot wrote:
>>
>> I don't understand that binary choice... You can work on your own
>> project without forking Busybox. You can use both Busybox and your
>> own project on your systems. Busybox is a set of tools, why should it
>> be THE set of tools ?
>
>
> Sure, I know how to do this, I started creating adapted Busybox versions to
> specific needs for a minimalistic 386SX Board. Around 1995, or so ... wow,
> long time now :)
>
> It is neither a knowledge nor any technical problem, it is preference:
> I want to have *one* statical binary in the minimal system, and being
> able to run a full system setup with this (system) binary (or call it
> tool set). All I need then is the binary, some configs, some scripts
> (and may be special applications). I even go so far, to run a system
> with exactly that one binary only, all other applications functions are
> done with scripting (ash, sed, awk). Sure those are minimalist
> (dedicated systems), but they may be used in a comfortable manner.
>
> I even started a project to create a file system browser (comparable to
> Midnight Commander, with no two pane mode but up to 9 quick switch
> directories), using only BB and scripting. All packed in a (possibly self
> extracting) single shell script. The only requirements to run this, is
> (should be) a working BB (defconfig) environment, usual proc, sys, dev,
> setup and a writable /tmp directory (e.g. on tmpfs). The work for this was
> half way through to first public alpha, then Denys reaction on a slight
> change request was so frustrating that I pushed the project into an
> otherwise unused archive corner, and stopped any further development.
>
>
>> I'm not sure how heavily mdev [-s] relies on libbb and how hard it
>> would be to extract the source and make it into a standalone, easily
>> hackable project, but if you want to test architecture ideas, that's
>> the way to go - copy stuff and tinker with it until you have
>> something satisfying.
>
>
> I always did it this way, and never posted untested stuff, except some
> snippets when one asked for something and I quickly hacked something for
> an answer (with mark set as untested).
>
>
>> ... if not, you still have your harald-mdev, and you can still use it
>> along with Busybox - you'll have two binaries instead of one, but
>> even on whatever tiny noMMU you can work on, you'll be fine.
>
>
> Sure, I could have two, three, four, ten, twenty, hundred, ... programs, but
> my preference is to have *one* statically linked binary for the complete
> system tool set (on minimal systems).

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, sorry. I really do not
want busybox to follow the systemd way. On the positive side of
systemd, they at least have far more resource than what Denys can
offer, at least in my opinion, so ...

> ... Thats the reason why I dislike and don't use your system approach :( ...
> otherwise great work :)
>
>
>> That does not preclude design discussions, which I like, and which
>> can happen here (unless moderators object), and people like Isaac,
>> me, or obviously Denys, wouldn't be so defensive - because it's now
>> about your project, not Busybox; you have the final say, and it's
>> totally fine, because I don't have to use harald-mdev if I don't want
>> to.
>
>
> One of the things I really hate, is to force someone doing something
> (especially in a specific way), only topped by someone else forcing me to do
> something in a specific way :( ...
>
> ... so I always try to do modifications in a way which let others decide
> about usage, expecting not to break existing setups (at least without asking
> ahead if welcome). Slight modifications may happen from modifications (e.g.
> different parameter notion), if unavoidable, but they shall not require
> complete changes in system setup.
>
> --
> Harald
>
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox


More information about the busybox mailing list