On Feb 27, 2008, at 9:22 PM, Hollis Blanchard wrote: > 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.
Just while reading this I thought "Hey cool, dtc is packaged in most distributions anyway. So why not modify dtc to provide the library, so we have a common code base and make it a build dependency?" This way no separate project needs to be founded and this is just a simple build dependency. I don't know if it's much work to use the objects provided in dtc instead of creating own ones. I believe it's done faster than winning this argument though. ;-) >>> 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. Cool! No need to provide a copy of it then, as we can use the 'upstream' one. >> 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. If this is in dtc, whoever maintains dtc is. >>> 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 true and is exactly the reason the bioses and qemu are in kvm. If no changes are needed though, it's easier to keep it external imho. >> 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"? I'm sorry. In the end it's more or less your decision anyway. If you plan to make frequent changes to the code (aka fork), include it in kvm. If you are only planning on using code already available without changes (aka copy), please change dtc to make the functionality that exists available to kvm (e.g. a dot a file). This mostly seems to be Avi's opinion as well as far as I understood it. Alex ------------------------------------------------------------------------- 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
