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 [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]
