Re: [ANNOUNCE][PATCH] Kcli - Kernel command line interface.

[Matt Ranon <mranon@javadevices.com>]

> (text reformatted to less than 80 cols.  Please, we'll get along a lot
> better if you don't send 1000-column emails)

Sorry. I am afraid we are from a different background, and so very
poorly versed in these things. My email client does not seem
to have an option to tell it to format in 80 cols. So, hopefully,
using CR, I am achieving the same effect. Let me know if
it doesn't work, and I will have to switch to a different email
client for conversing with the lkml.


> The obvious question is: what's _wrong_ with doing all this in some
> cut-down userspace environment like busybox?  Why is this stuff better?
> 
> Obviously some embedded developers have considered that option and
> have rejected it.  But we do need to be told, at length, why that
> decision was made.

There is nothing _wrong_ with doing it all in a cut-down userspace. It
is a matter of personal preference, culture, and the application. That
is what makes Linux so great, it is all about choice.

We are developing devices that don't have a user space, and we don't
see the point in including one just for debug purposes. We will not be 
offended if Kcli is not included into the kernel mainline, nor if Kcli compels
people to call us stupid (as it already has) just because we are different 
and some people don't understand us. We are firm believers that the 
world, including the Linux kernel world,  would be a nasty place if there 
was only _one_ way to do any given task. Additionally, we  are almost 
certain that there will be others who think like we do, so we are reaching 
out to them. We also feel compelled to give _something_ back to the 
community that has given so much to us, and, for now, this is all we have.

However, our reasons for Kcli are:
1) Our devices ship with no user space, and we want the development
environment to be as close as possible to the final product.
2) Getting debug information with user space calls require context 
switches and data copies, which changes the real time profile and can mask
bugs. 
3) To use user space, we would need cross compiled libc's, special
builds of gcc, root file systems, flash storage to store it all, and all 
sorts of things which make life a lot more complicated than it needs 
to be for us. We are quite capable of producing all these things, but,
we just don't see the point in it. Our way, we just have a gcc capable 
of cross compiling the kernel and it is so simple.
4) For us, it is the opposite argument. We would need to be convinced
that having user space is worth all the overhead. Not just CPU
overhead, but all the overheads.
5) We like it in the kernel, we find it to be warm and fuzzy. Whereas,
user space is a cold, dark, and rainy place, and we just don't want to
go there. :)

We do not claim to have come up with a _better_ way. We have just
created something that we feel would be useful to others.

MRanon.