lkml.org 
[lkml]   [2006]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [klibc] klibc and what's the next step?
On Sat, Jul 01, 2006 at 05:17:17PM -0700, H. Peter Anvin wrote:
> 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.

Well, I wouldn't be one of those folks. In fact, how big is dash and
some select set of shell utilities? If they aren't that big, it might
make sense to include them all the time so that a simple command-line
option on boot is all that's necessary in order to break into a
pre-kinit interactive shell. That would make the resulting system
more debuggable by definition. Then all we will would have to do is
make sure the distro's use the kernel-supplied kinit solution, instead
of rolling their own non-standard version.

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

\
 
 \ /
  Last update: 2006-07-02 02:42    [W:0.212 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site