On Feb 27, 2008, at 11:19 PM, Hollis Blanchard wrote: > On Wed, 2008-02-27 at 22:20 +0100, Alexander Graf wrote: >> On Feb 27, 2008, at 9:22 PM, Hollis Blanchard wrote: >>> >>> 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?" > > That's a strange assertion, considering that Debian (and thus Ubuntu) > doesn't have it. >
It's called "device-tree-compiler" there as 'dtc' was already taken. If I say "most" distributions, I mean "most" ;-). I don't know about ROCK Linux or the like, but they are a lot more flexible to taking new packages anyway. >>> 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. > > I'm aware that we *could* use an upstream version of libfdt, if > everybody packaged and distributed it. However, they don't, I'm not > going to create and maintain those packages, and apparently you're not > volunteering either. So what "upsteam" could we use if we wanted to? Whatever upstream 'dtc' has? I thought there was a git tree of dtc? So there has to be _someone_ maintaining it? http://www.jdl.com/git_repos/?p=dtc.git And as one can see quite easily, there are changes to the source. > > >>>> 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. > > Is it? If so, I think I've made my decision clear... Ignore me then :-). I only want to help, as usually it's the more code the more work. >> 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. > > Have you actually looked at the code in question, or just saw that it > has "lib" in the name? I basically just thought that if two projects use the same source, it might be worth considering to share that as keeping copies in sync is harder than it looks. > It's 1600 lines of C. In contrast, zlib, which is used in a large > number > of projects, and despite that is often statically linked, is 8500. Uhm. Yes? Nobody said anything against linking it statically. Am I missing something? This is all about reducing the amount of work necessary to keep everything going in the end. If you think copying is the way to go, nobody will oppose. We are only expressing our opinion on this, but you will be the one keeping libfdt up to date anyway (if that's even necessary, I don't know). ------------------------------------------------------------------------- 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
