Re: [kvm-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
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. -- 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] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
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. Alex - 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] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
On Tue, 2008-02-26 at 11:24 -0600, Jerone Young wrote: However, why do we need libfdt? Is it not carried by distros, or do you need to make changes? Well it actually isn't distributed with each distro .. sigh .. actually this comes from a tool called dtc, compiles/decompiles a device tree. Even the linux kernel has it's own version of libfdt ... so it's not exactly a central coordinated effort. It's something that kind of gets passed from project to project but never stand alone. So we kind of have to do the same. 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. -- 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] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
On Feb 27, 2008, at 5:59 PM, Avi Kivity wrote: Alexander Graf wrote: 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. [you == the ppc folk] Good idea. I can provide the rpm (and a tarball for non-rpm users) on the sourceforge download site until it is upstreamed into the distros. Most distros now allow external package maintainers, so it shouldn't be too difficult to get it accepted. I can get this in for SUSE. You could make it really easy for me if you put this on the SUSE build service, so I can just take the package from there and put it into the distro. Presumably the library will only rarely change. I hope so ;-). But then again if every user maintained its own version until now, I guess there are not that many changes. - 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] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
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. 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. -- 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] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
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? 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. 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. -- Any sufficiently difficult bug is indistinguishable from a feature. - 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] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
On Mon, 2008-02-25 at 11:00 +0200, Avi Kivity wrote: Jerone Young wrote: The top level directory of kvm-userspace is starting to get a little crowded as we start to bring in more external dependencies. Perhaps we can create a folder tools and move directories: bios extboot vgabios The reason I mention this is soon I will be sending a patch to the list soon that will add libfdt (which is a library to read device trees for ppc) as a dependency for qemu .. and it's another directory at the top level, there will most likely be more libs and tools added in the future. Not sure if tools is the best name .. maybe external_libs .. not sure .. but just a place to put external dependencies for qemu whould be a good thing. I don't really see why we need to keep the top-level directory small. I think it's more of a personal thing. Mainly do it for anyone who is getting into the project for the first time. Once you've been doing it for a while it's no issue.. but first time your trying to figure out what is vgabios and is it related to kvm .. well it's actually more related to qemu (which kvm happens to use)... cases like that .. but really it's not a big deal .. just figured I'd see what folks thought about the idea. However, why do we need libfdt? Is it not carried by distros, or do you need to make changes? Well it actually isn't distributed with each distro .. sigh .. actually this comes from a tool called dtc, compiles/decompiles a device tree. Even the linux kernel has it's own version of libfdt ... so it's not exactly a central coordinated effort. It's something that kind of gets passed from project to project but never stand alone. So we kind of have to do the same. - 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] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies
Jerone Young wrote: The top level directory of kvm-userspace is starting to get a little crowded as we start to bring in more external dependencies. Perhaps we can create a folder tools and move directories: bios extboot vgabios The reason I mention this is soon I will be sending a patch to the list soon that will add libfdt (which is a library to read device trees for ppc) as a dependency for qemu .. and it's another directory at the top level, there will most likely be more libs and tools added in the future. Not sure if tools is the best name .. maybe external_libs .. not sure .. but just a place to put external dependencies for qemu whould be a good thing. I don't really see why we need to keep the top-level directory small. However, why do we need libfdt? Is it not carried by distros, or do you need to make changes? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - 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
