Messages in this thread | | | Date | Sat, 01 Jul 2006 15:31:32 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [klibc] klibc and what's the next step? |
| |
Linus Torvalds wrote: > > On Sat, 1 Jul 2006, Theodore Tso wrote: >> This is going to be a problem given that people are hell-bent at >> chucking functionality out of the kernel into userspace. > > Btw, I'm not necessarily one of those people. > > There _are_ some things that can be better done in user space, but on the > other hand, other things really are better off in the kernel. > > 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. >
Indeed. The stuff that have been moved to userspace in the first cut of klibc are stuff which can largely be tested independently, usually just from the normal command line. This is incredibly powerful, but it is not -- and shouldn't be -- universally applied just because it can; it should be applied if and when it makes sense.
> For example, the old pcmcia layer in user space was crap, crap, crap, and > at least I fount it was MUCH harder to debug than the all-in-kernel code.
I have my own share of debugging shared kernel space/user space applications, mainly autofs, and if done properly, it can be quite sane. If done *improperly*, it's a nightmare. Personally, I find that if one can:
- Run something as a separate component in userspace, and/or - Can leverage strace(1) to get more insight
then one can usually get a lot of debugging help. Otherwise, probably not.
-hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |