On Mon, Apr 23, 2007 at 06:12:19PM -0700, Matt Ranon wrote: > 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.
I hope that means your devices have full source code available under the GPL. Even if they do, kcli will probably encourage other folks to abuse the kernel license. > 2) Getting debug information with user space calls require context > switches and data copies, which changes the real time profile and can mask > bugs. Probably no worse than whatever I/O interface you're likely to use with this. Reminds me of a particular "world-famous filesystem developer" who eventually figured out that his serial console was the cause of most of the filesystem latency glitches he was hitting. > 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. Please familiarize yourself with initramfs and klibc. You can attach an arbitrary minimal filesystem to the kernel image. You don't need a special compiler, flash, etc., and the kernel build system will build the filesystem image (a cpio archive) for you. > 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. Moving stuff to userspace usually has negative overhead because it's pageable, easier to maintain, and easier to debug. > 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. :) I once spent a few weeks getting OpenSSH serving multiple clients on vxWorks and I'm happy I'll never have to touch a kernel without userspace again. I think there probably is a place for some basic debugging and introspection, including dumping address ranges, looking up symbols and the like, but a debugger is different than a command interpreter. -- Mathematics is the supreme nostalgia of our time. - 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/