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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sat, 28 Apr 2007 12:44:39 -0500
From:	Matt Mackall <mpm@...enic.com>
To:	Matt Ranon <mranon@...adevices.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux maillist <linux-kernel@...r.kernel.org>
Subject: Re: [ANNOUNCE][PATCH] Kcli - Kernel command line interface.

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/