Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Jerone Young]

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.



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

Re: Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Avi Kivity]

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/vse0120000070mrt/direct/01/

Re: Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Jerone Young]

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/vse0120000070mrt/direct/01/

Re: Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Avi Kivity]

Jerone Young wrote:

  

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

Maybe a README.dev can help the first-timers.  I'm concerned about the 
old-timers' tab key.

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

Okay.

-- 
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/vse0120000070mrt/direct/01/

Re: Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Hollis Blanchard]

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/vse0120000070mrt/direct/01/

Re: Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Avi Kivity]

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/vse0120000070mrt/direct/01/

Re: Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Alexander Graf]

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/vse0120000070mrt/direct/01/

Re: Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Avi Kivity]

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.

Presumably the library will only rarely change.

-- 
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/vse0120000070mrt/direct/01/

Re: Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Alexander Graf]

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/vse0120000070mrt/direct/01/

Re: Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Hollis Blanchard]

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 linuxppc-dev@ozlabs.org , 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/vse0120000070mrt/direct/01/

Re: Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Alexander Graf]

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 linuxppc-dev@ozlabs.org , 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/

Re: [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Hollis Blanchard]

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 linuxppc-dev@ozlabs.org , 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


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

Re: [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Alexander Graf]

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 linuxppc-dev@ozlabs.org , 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/

Re: [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Hollis Blanchard]

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/vse0120000070mrt/direct/01/

Re: [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Alexander Graf]

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/

Re: [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Luca Barbato]

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/vse0120000070mrt/direct/01/

Re: Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Avi Kivity]

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 linuxppc-dev@ozlabs.org , 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/vse0120000070mrt/direct/01/

Re: [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Hollis Blanchard]

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 linuxppc-dev@ozlabs.org , 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/vse0120000070mrt/direct/01/

Re: [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Avi Kivity]

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/vse0120000070mrt/direct/01/

Re: [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Jerone Young]

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/vse0120000070mrt/direct/01/

Re: [kvm-ppc-devel] Top level kvm-userspace directory getting crowded ... need new dir for qemu dependencies

[Avi Kivity]

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/vse0120000070mrt/direct/01/