> (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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/