Too big to post,
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.5-rc1-klibc1.patch.bz2
or
bk://kernel.bkbits.net/jgarzik/klibc-2.5
IIRC, this is: my update of Bryan O'Sullivan's update of Greg KH's
update of my merge of hpa's and viro's hacking :)
WRT overall klibc merge: when it can do md RAID autorun, it's
mergeable. And didn't somebody write a tiny mdctl program...
Jeff
Jeff Garzik <[email protected]> wrote:
>
> Too big to post,
>
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.5-rc1-klibc1.patch.bz2
> or
> bk://kernel.bkbits.net/jgarzik/klibc-2.5
>
> IIRC, this is: my update of Bryan O'Sullivan's update of Greg KH's
> update of my merge of hpa's and viro's hacking :)
>
> WRT overall klibc merge: when it can do md RAID autorun, it's
> mergeable. And didn't somebody write a tiny mdctl program...
It's so long since klibc was discussed (ie: more than five minutes ago)
that I forget the reasons why it should be delivered via the kernel tree.
Remind me please?
On Tue, Mar 16, 2004 at 12:52:29AM -0800, Andrew Morton wrote:
> Jeff Garzik <[email protected]> wrote:
> >
> > Too big to post,
> >
> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.5-rc1-klibc1.patch.bz2
> > or
> > bk://kernel.bkbits.net/jgarzik/klibc-2.5
> >
> > IIRC, this is: my update of Bryan O'Sullivan's update of Greg KH's
> > update of my merge of hpa's and viro's hacking :)
> >
> > WRT overall klibc merge: when it can do md RAID autorun, it's
> > mergeable. And didn't somebody write a tiny mdctl program...
>
> It's so long since klibc was discussed (ie: more than five minutes ago)
> that I forget the reasons why it should be delivered via the kernel tree.
>
> Remind me please?
We need a way to build the userspace programs that get put into
initramfs that will be needed to boot the kernel.
That help?
thanks,
greg k-h
Andrew Morton wrote:
> Jeff Garzik <[email protected]> wrote:
>
>>Too big to post,
>>
>> http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.5-rc1-klibc1.patch.bz2
>> or
>> bk://kernel.bkbits.net/jgarzik/klibc-2.5
>>
>> IIRC, this is: my update of Bryan O'Sullivan's update of Greg KH's
>> update of my merge of hpa's and viro's hacking :)
>>
>> WRT overall klibc merge: when it can do md RAID autorun, it's
>> mergeable. And didn't somebody write a tiny mdctl program...
>
>
> It's so long since klibc was discussed (ie: more than five minutes ago)
> that I forget the reasons why it should be delivered via the kernel tree.
>
> Remind me please?
Several reasons. The big one in my mind is, it will be delivering
pieces without which the kernel will not boot, so you really really want
to keep that software in sync with the latest kernel... at least until
all the details are worked out. Otherwise version skew will as we
remove code from the kernel and move it to userspace will be painful --
users would be rebuilding their external klibc trees just about every
day, as code was moved from kernel to early-userspace.
Jeff
Greg KH <[email protected]> wrote:
>
> On Tue, Mar 16, 2004 at 12:52:29AM -0800, Andrew Morton wrote:
> >
> > It's so long since klibc was discussed (ie: more than five minutes ago)
> > that I forget the reasons why it should be delivered via the kernel tree.
> >
> > Remind me please?
>
> We need a way to build the userspace programs that get put into
> initramfs that will be needed to boot the kernel.
>
> That help?
My grey cells thank you.
Does klibc have a bk home anywhere, so I can start sucking it in?
Andrew Morton wrote:
> Greg KH <[email protected]> wrote:
>
>>On Tue, Mar 16, 2004 at 12:52:29AM -0800, Andrew Morton wrote:
>>
>>>It's so long since klibc was discussed (ie: more than five minutes ago)
>>>that I forget the reasons why it should be delivered via the kernel tree.
>>>
>>>Remind me please?
>>
>>We need a way to build the userspace programs that get put into
>>initramfs that will be needed to boot the kernel.
>>
>>That help?
>
>
> My grey cells thank you.
>
> Does klibc have a bk home anywhere, so I can start sucking it in?
>
>
There is the one I subtlely posted in my original email :)
bk://kernel.bkbits.net/jgarzik/klibc-2.5
Bryan O'Sullivan and Greg KH at varying times in the past had BK trees,
but I didn't know of any up-to-date one.
Note that it isn't my intention to become klibc maintainer... just in
case anybody started getting ideas... :)
Jeff
On Tue, Mar 16, 2004 at 02:16:09PM -0500, Jeff Garzik wrote:
>
> Bryan O'Sullivan and Greg KH at varying times in the past had BK trees,
> but I didn't know of any up-to-date one.
I think Bryan was trying to keep his bk tree up to date with the klibc
cvs tree, but don't know how well that went.
> Note that it isn't my intention to become klibc maintainer... just in
> case anybody started getting ideas... :)
I thought hpa was the klibc maintainer, you're just offering a patch to
add it to the build :)
thanks,
greg k-h
Greg KH wrote:
> On Tue, Mar 16, 2004 at 02:16:09PM -0500, Jeff Garzik wrote:
>
>>Bryan O'Sullivan and Greg KH at varying times in the past had BK trees,
>>but I didn't know of any up-to-date one.
>
>
> I think Bryan was trying to keep his bk tree up to date with the klibc
> cvs tree, but don't know how well that went.
The latest I found from bos was 2.6.0-test9, not terribly ancient but
still required some hand-fixing of merge conflicts.
>>Note that it isn't my intention to become klibc maintainer... just in
>>case anybody started getting ideas... :)
>
>
> I thought hpa was the klibc maintainer, you're just offering a patch to
> add it to the build :)
Right... I meant I am not going to become the maintainer of said
patch/BK tree :)
Jeff
Jeff Garzik <[email protected]> wrote:
>
> >>Note that it isn't my intention to become klibc maintainer... just in
> >>case anybody started getting ideas... :)
> >
> >
> > I thought hpa was the klibc maintainer, you're just offering a patch to
> > add it to the build :)
>
> Right... I meant I am not going to become the maintainer of said
> patch/BK tree :)
It would be rather handy if someone could maintain the definitive tree for
this work for a while, until we linusify it.
I don't have a feeling for its stability/readiness/desirability/anthingelse
at this stage. How mergeable is it?
Andrew Morton wrote:
> Jeff Garzik <[email protected]> wrote:
>
>> >>Note that it isn't my intention to become klibc maintainer... just in
>> >>case anybody started getting ideas... :)
>> >
>> >
>> > I thought hpa was the klibc maintainer, you're just offering a patch to
>> > add it to the build :)
>>
>> Right... I meant I am not going to become the maintainer of said
>> patch/BK tree :)
>
>
> It would be rather handy if someone could maintain the definitive tree for
> this work for a while, until we linusify it.
Last I heard from LT direction was "OK but nothing uses it"
> I don't have a feeling for its stability/readiness/desirability/anthingelse
> at this stage. How mergeable is it?
It still needs some testing before merging, and IMO still needs to
resolve Linus's objection before it moves beyond the "big hunk of code
that doesn't do much" stage.
It's IMO a 2.7 change...
Jeff
On Tue, 2004-03-16 at 11:53, Andrew Morton wrote:
> It would be rather handy if someone could maintain the definitive tree for
> this work for a while, until we linusify it.
I'll spend a bit of time in the next few days bringing it up to date
w.r.t the current kernel and klibc trees.
> I don't have a feeling for its stability/readiness/desirability/anthingelse
> at this stage. How mergeable is it?
Not very. klibc itself works OK, and the in-tree tools that use it work
OK, but they get very few "pick ourselves up off the ground and do a
complete boot" test cycles.
It's definitely 2.7 material.
<b
On Tue, Mar 16, 2004 at 11:53:40AM -0800, Andrew Morton wrote:
> Jeff Garzik <[email protected]> wrote:
> >
> > >>Note that it isn't my intention to become klibc maintainer... just in
> > >>case anybody started getting ideas... :)
> > >
> > >
> > > I thought hpa was the klibc maintainer, you're just offering a patch to
> > > add it to the build :)
> >
> > Right... I meant I am not going to become the maintainer of said
> > patch/BK tree :)
>
> It would be rather handy if someone could maintain the definitive tree for
> this work for a while, until we linusify it.
>
> I don't have a feeling for its stability/readiness/desirability/anthingelse
> at this stage. How mergeable is it?
I need to dig through the build system once more.
Last time I did it, I only managed to get it to the 'working' stage.
Not at the 'good enough' stage.
This minor issue should not delay the inclusion though - just a
note that something needs to be looked at in this area.
Sam