Re: [ANNOUNCE][PATCH] Kcli - Kernel command line interface.
- From: Matt Mackall <mpm@xxxxxxxxxxx>
- Date: Sat, 28 Apr 2007 12:44:39 -0500
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- Re: [ANNOUNCE][PATCH] Kcli - Kernel command line interface.
- From: Matt Ranon
- Re: [ANNOUNCE][PATCH] Kcli - Kernel command line interface.
- Prev by Date: Re: 2.6.21 known regressions (v2) (for -stable team)
- Next by Date: [PATCH] [13/22] x86_64: 64bit ACPI wakeup trampoline
- Previous by thread: Re: [ANNOUNCE][PATCH] Kcli - Kernel command line interface.
- Next by thread: Re: SATA SB600 works in 2.6.20.4 but not in 2.6.21-rc5 with irqpoll parameter
- Index(es):
Relevant Pages
|
Loading