klibc update
PATCH 1/1 klibc update
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
Quoted 7 lines · Jeff Garzik
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
Quoted 5 lines
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?
Quoted 11 lines · Andrew Morton
Quoted 10 lines · Jeff Garzik
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.5IIRC, 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 :)
Quoted 7 lines
Quoted 2 lines
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
Quoted 6 lines · Greg KH
Quoted 4 lines · Andrew Morton
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.
Quoted 6 lines
Quoted 1 line
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?
Quoted 12 lines · Andrew Morton
Quoted 10 lines · Greg KH
Quoted 4 lines · Andrew Morton
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.
Quoted 8 lines
Quoted 1 line
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
Quoted 3 lines · Jeff Garzik
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.
Quoted 2 lines
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
Quoted 7 lines · Greg KH
Quoted 1 line · Jeff Garzik
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.
Quoted 5 lines
Quoted 1 line
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
Quoted 10 lines · Jeff Garzik
Quoted 7 lines
Quoted 3 lines
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?
Quoted 5 lines · Andrew Morton
Quoted 3 lines · Jeff Garzik
Quoted 3 lines
Quoted 1 line
Note that it isn't my intention to become klibc maintainer... just in case anybody started getting ideas... :)
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
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"
Quoted 2 lines
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
Quoted 2 lines · Andrew Morton
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.
Quoted 2 lines
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
Quoted 9 lines · Andrew Morton
Quoted 8 lines · Jeff Garzik
Quoted 7 lines
Quoted 3 lines
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 :)
Quoted 8 lines
Quoted 2 lines
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
Quoted 10 lines · Andrew Morton
Quoted 8 lines · Jeff Garzik
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.5IIRC, 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 :)
Quoted 7 lines
Quoted 1 line
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