lkml.org 
[lkml]   [2006]   [Jun]   [30]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 30 Jun 2006 20:11:31 +0200
FromPavel Machek <>
SubjectRe: klibc and what's the next step?
On Tue 2006-06-27 15:12:53, Roman Zippel wrote:
> Hi,> > On Sun, 25 Jun 2006, H. Peter Anvin wrote:> > > The majority of the patches are independent in the sense that they
> > should apply independently, but Makefile/Kbuild files may have to be
> > adjusted to build a partially patched tree.> > I could now repeat all the concerns I already mentioned, why it shouldn't 
> be merged as is (that doesn't mean it shouldn't be merged at all!), but 
> they have been pretty much ignored anyway...> > What I'm more interested in is basically answering the question and where 
> I hope to provoke a bit broader discussion: "What's next?"
> 
> Until recently for most developers klibc was not much more than a cool 
> idea, but now we have the first incarnation and now we have to do a 
> reality check of how it solves our problems. To say it drastically the 
> current patch set as it is does not solve a single real problem yet, it 
> only moves them from the kernel to kinit, which may be the first step but 
> where to?
> 
> So what problems are we going to solve now and how? The amount of 
> discussion so far is not exactly encouraging. If nobody cares, then there 
> don't seem to be any real problems, so why should it be merged at all? Are 
> shiny new features more important than functionality?
> 
> So anyone who likes to see klibc merged, because it will solve some kind 
> of problem for him, please speak up now. Without this information it's 
> hard to judge whether we're going to solve the right problems.
> 
> Peter, it would really help if you describe your own plans, how you want 
> to go forward with it, otherwise it leaves a huge amount of uncertainty 
> and since this is a rather big change, I think it's a real good idea to 
> reduce this uncertainty, so we know what to expect and everyone can better 

I'd like to eventually move swsusp out of kernel, and klibc means I
may be able to do that without affecting users. Being in kinit is good
enough, because I can actually share single source between kinit
version and suspend.sf.net version.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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-06-30 20:15    [from the cache]
©2003-2008