[lkml]   [2006]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-07-02 00:34    [W:0.169 / U:1.128 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site