Re: [klibc] klibc and what's the next step?

From: H. Peter Anvin
Date: Sat Jul 01 2006 - 20:16:15 EST


Theodore Tso wrote:
On Sat, Jul 01, 2006 at 01:08:17PM -0700, Linus Torvalds wrote:
The argument that user space is more debuggable has been shown to be largely a red herring. User space is only more debuggable if it does something independent, and we've seen that user space is _harder_ to debug than kernel space if we have events going back and forth.

Agreed, 100%.

In addition, userspace is debuggable only only if the initramfs has
enough debugging code in their (like a real live working shell,
strace, basic shell commands etc.) Otherwise, it becomes even more
hellish to debug. I wasted a huge amount of time trying to figure out
why the RHEL4 initramfs was incompatible with modern kernels using the
MPT Fusion SCSI driver, because I couldn't make it stop and break out
to a working shell; it had some busybox-like nash thing that wasn't
designed for user interaction, so all I could do was try to make tiny
changes to the initramfs, wait for the !@#@# very long boot cycle, and
watch the initial ramdisk fail to mount the root and crash, and
repeat, for hours on end. RHEL4's userspace root mount system was
***not*** more debuggable, not in the last. Adding printk's into a
kernel and recompiling would have been easier, and far less
frustrating.

Hopefully kinit will be better, but it's definitely not the case that
userpsace is easier to debug.


It isn't automatically easier, but it *can* be.

In your case above, with kinit, I would have added dash and strace (the latter would probably have to be statically linked against glibc; I haven't actually tried building strace under klibc myself) -- or even gdb -- to initramfs, and have /init drop into a shell. From there one can run strace -f on kinit.

One of the criticisms I've gotten for klibc has been why I have included dash and a whole bunch of shell utilities when they're not used by the default kernel build. It certainly hasn't been just to prove a point; as a matter of fact, getting dash to build correctly under Kbuild proved to be surprisingly difficult. However, by making sure that one can *easily* pull together an interactive environment -- even if one didn't have one from the start -- one has more readily access to a debuggable environment.

Similarly, I try very hard to have small, individually testable modules. I haven't taken that even as far as I'd like to have, in the end, but that's on my list of things to do.

-hpa
-
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/