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

["H. Peter Anvin" <hpa@zytor.com>]

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/