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:4.376 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site