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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
