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 [EMAIL PROTECTED] , 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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
