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. 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. > > > 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. 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. > 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. 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. ------------------------------------------------------------------------- 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
