Re: [kvm-devel] [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
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
Re: [kvm-devel] [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
On Wed, 2008-02-27 at 21:25 +0200, Avi Kivity wrote: > Hollis Blanchard wrote: > > 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. > > > > Is Xen ppc discontinued? I have no plans to continue development; I can't speak for anybody else. > > 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 > > propose it on [EMAIL PROTECTED] , which is where libfdt is > > discussed. > > > > 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. > > It doesn't have to be a package; it can be as simple as a tarball that > people have to make; && sudo make install before compiling kvm, the same > as other prerequisite libraries. Sure. Let's put that tarball inside the qemu directory, and then have it extracted and built automatically when the user types "make". I'm really not clear on what advantage you think will be gained here. > The barrier should be whether we need to carry local changes or not. If > we can use upstream as is, then it should be installed independently. So let me get this straight... you think it's cool to awk kernel source, but not to copy library code that was designed to be copied in the first place? Seriously? Would it be more palatable to you if I ran awk over arch/powerpc/boot/libdft? -- 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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
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 l
Re: [kvm-devel] [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
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. > > 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? > >> 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... > 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? 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. -- 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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
Hollis Blanchard wrote: >> It doesn't have to be a package; it can be as simple as a tarball that >> people have to make; && sudo make install before compiling kvm, the same >> as other prerequisite libraries. >> > > Sure. Let's put that tarball inside the qemu directory, and then have it > extracted and built automatically when the user types "make". > > I'm really not clear on what advantage you think will be gained here. > > If the package never changes in kvm-specific ways, there is no point in including it in kvm. The user can install it once, just like they install the X devel packages (for example) which we don't carry in kvm either. Is it indeed the case that no modifications are needed for kvm? >> The barrier should be whether we need to carry local changes or not. If >> we can use upstream as is, then it should be installed independently. >> > > So let me get this straight... you think it's cool to awk kernel source, > Awking the kernel source is not done for the sheer pleasure of it. It is painful to maintain and I only do it out of necessity. > but not to copy library code that was designed to be copied in the first > place? Seriously? Would it be more palatable to you if I ran awk over > arch/powerpc/boot/libdft? > Including the source in kvm is of course preferable to awk, but less preferable to an external dependency. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
So I forgot to CC all the interested parties on this list (sorry about that I wasn't thinking at the time), but I did start up a conversation on linuxppc-dev on the subject of splitting out libfdt from dtc. Mainly to get the thought of what the dtc folks thought about splitting out libfdt. The outcome of this discussion is the point of libfdt is to be integrated into different projects. I could not make a good argument at all as to why it should be split out (actually I did a terrible job at it :-)). A good analogy was made also as this is "equivalent to splitting libcrypto out of openssl". So the concessious from others in the libfdt community is the it should go in the project. This would be in line with what Hollis has been saying on the list. Now for us we can do one of the following options: 1) Integrate libfdt into our kvm-userspace or qemu (which would then require going upstream qemu folks also agree). 2) Can use wget or something to first grab the dtc source and get libfdt from it. Then place in our make file and build it. As well as point cflags & ldflags to it. (This can be done, though I wanted to avoid going this route) Here is a link to the discussion on linuxppc-dev: http://ozlabs.org/pipermail/linuxppc-dev/2008-February/052262.html On Thu, 2008-02-28 at 10:16 +0200, Avi Kivity wrote: > Hollis Blanchard wrote: > >> It doesn't have to be a package; it can be as simple as a tarball that > >> people have to make; && sudo make install before compiling kvm, the same > >> as other prerequisite libraries. > >> > > > > Sure. Let's put that tarball inside the qemu directory, and then have it > > extracted and built automatically when the user types "make". > > > > I'm really not clear on what advantage you think will be gained here. > > > > > > If the package never changes in kvm-specific ways, there is no point in > including it in kvm. The user can install it once, just like they > install the X devel packages (for example) which we don't carry in kvm > either. > > Is it indeed the case that no modifications are needed for kvm? > > >> The barrier should be whether we need to carry local changes or not. If > >> we can use upstream as is, then it should be installed independently. > >> > > > > So let me get this straight... you think it's cool to awk kernel source, > > > > Awking the kernel source is not done for the sheer pleasure of it. It is > painful to maintain and I only do it out of necessity. > > > but not to copy library code that was designed to be copied in the first > > place? Seriously? Would it be more palatable to you if I ran awk over > > arch/powerpc/boot/libdft? > > > > Including the source in kvm is of course preferable to awk, but less > preferable to an external dependency. > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
Jerone Young wrote: > So I forgot to CC all the interested parties on this list (sorry about > that I wasn't thinking at the time), but I did start up a conversation > on linuxppc-dev on the subject of splitting out libfdt from dtc. Mainly > to get the thought of what the dtc folks thought about splitting out > libfdt. > > The outcome of this discussion is the point of libfdt is to be > integrated into different projects. I could not make a good argument at > all as to why it should be split out (actually I did a terrible job at > it :-)). A good analogy was made also as this is "equivalent to > splitting libcrypto out of openssl". > > So the concessious from others in the libfdt community is the it should > go in the project. This would be in line with what Hollis has been > saying on the list. > > Now for us we can do one of the following options: > 1) Integrate libfdt into our kvm-userspace >or qemu (which would then require going upstream qemu folks also agree). > > 2) Can use wget or something to first grab the dtc source and get libfdt > from it. Then place in our make file and build it. As well as point > cflags & ldflags to it. (This can be done, though I wanted to avoid > going this route) > > We definitely won't make the build so complicated as to depend on wget and Internet connectivity, so we'll just plant the tree in kvm-userspace.git. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
Hollis Blanchard wrote: > That's a strange assertion, considering that Debian (and thus Ubuntu) > doesn't have it. Others do.. https://admin.fedoraproject.org/pkgdb/packages/name/dtc http://packages.gentoo.org/package/sys-apps/dtc http://www.novell.com/products/linuxpackages/opensuse/dtc.html > Have you actually looked at the code in question, or just saw that it > has "lib" in the name? > > 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. That's why today some people are hunting copies and submitting patches to cleanup that mess. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
