Re: [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Hollis Blanchard <hollisb@us.ibm.com>]

On Wed, 2008-02-27 at 20:18 +0100, Alexander Graf wrote:
> On Feb 27, 2008, at 7:56 PM, Hollis Blanchard wrote:
> 
> > On Wed, 2008-02-27 at 17:48 +0100, Alexander Graf wrote:
> >> On Feb 27, 2008, at 5:34 PM, Avi Kivity wrote:
> >>
> >>> Hollis Blanchard wrote:
> >>>> It is a centrally co-ordinated effort, but it is not a package a
> >>>> distro
> >>>> would carry. It is code shared by anything that needs to load a
> >>>> PowerPC
> >>>> Linux kernel, for example: the kernel bootwrapper (part of the  
> >>>> Linux
> >>>> source tree), u-boot firmware, Xend, and now qemu.
> >>>>
> >>>> Accordingly, a libfdt.rpm simply doesn't make sense, and the code  
> >>>> is
> >>>> intended to be copied into any codebase that needs it.
> >>>>
> >>>
> >>> A static library  + headers (i.e. libfdt-devel.rpm) could have been
> >>> used, though Linux avoids external dependencies.
> >>
> >> Why don't you try to talk to the other possible users and create a
> >> version of the library, that at least can be packaged, even though  
> >> for
> >> now KVM would be the only user? Maybe others (unlikely Linux, maybe
> >> Xen, probably dtc) would like to have a central library for device
> >> trees too.
> >
> > I think it's obvious that Linux and uboot will never use this. Unless
> > someone steps up to continue PowerPC Xen development, neither will  
> > Xen.
> > So you've now narrowed down the use case to dtc (which is libfdt
> > upstream) and qemu.
> 
> and kvm.

== qemu

> Maybe OpenHackware as well. I don't know if there are more  
> projects that want to build/read device trees, but these are absolute  
> candidates.

Nope, OpenHackware is a real (albeit crappy) Open Firmware
implementation, so it has no need for libfdt.

(Open Firmware uses client->firmware callbacks to transfer data. The
"flat device tree" avoids the need for callbacks by packaging up all the
data into an standardized format. libfdt is a set of convenience
functions to work with that format.)

So again, we the potential users are qemu and dtc.

> > Whose problem are you trying to solve? It doesn't seem to be one that
> > any existing users have. If you want to push it, you should probably
> 
> I am seeing the problems KVM has with qemu migrations and the problems  
> I have maintaining patches for both (KVM and qemu). I would greatly  
> appreciate if those two would not be forking that much. Xen is even  
> worse in that respect. Just read the qemu ML and search for patches  
> from Ian, who desperately tries to get Xen patches upstream to reduce  
> the forking.
> 
> So basically what I am concerned about is that forking is bad for most  
> people. There are cases where forking is the only chance to continue  
> development, but I don't see this is the case here. Currently there is  
> nobody who has a problem. 

There is no need to equate "copy" with "fork". We will not be modifying
this code, so there is no fork.

> But there is no problem in providing a library either, right?
>
> What exactly would improve if you provide a library in the very same  
> source tree you build your program or a different one? Either you  
> build both from source or you get packages for both. In the best case  
> you can even get a package for the library and only have to recompile  
> KVM. Nobody would want to maintain SDL in KVM, just because it uses it.

There is a problem. Who is going to maintain it and integrate it with
every distribution? It's not going to be me, it's apparently not going
to be you, and I imagine it's not going to be Avi.

> > propose it on linuxppc-dev@ozlabs.org , which is where libfdt is
> > discussed.
> 
> I guess I'm the wrong person to do that. I merely suggested that it's  
> not that bad of an idea.
>
> > I'm sure as hell not going to advocate creating a standalone library,
> > push it into every package that supports PowerPC, and then telling  
> > users
> > they must build on a supported version of a supported distribution.
> 
> Again, nothing changes between an external library and an internal  
> one, except for improved maintainability. Nobody was talking about  
> anything distribution specific. Currently no distribution I know of  
> bundles KVM for PPC anyway. And as soon as they do they will include  
> the library.

The internal library has better maintainability because you maintain
complete control.

> This is a question of taste though and I don't want to have this  
> ending as a flame war. So please just ask the other users if they like  
> the idea. As I lack real knowledge of device trees and PPC specifics,  
> I wouldn't make a good moderator.

The one piece of feedback I've gotten is (verbatim): "Unless they have a
really good reason why, I think it's pointless."

I agree, this is a ridiculous thing to be arguing over, and I expected
to spend my day actually being productive. Maybe the problem here is
really the abbreviation "lib" in the name. How about I just call it
"fdt"?

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/