Re: [kvm-ppc-devel] [kvm-devel] Top level kvm-userspace directory

Re: [kvm-ppc-devel] [kvm-devel] Top level kvm-userspace directory

[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/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] [kvm-devel] Top level kvm-userspace directory

[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/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] [kvm-devel] Top level kvm-userspace directory

[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/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] [kvm-devel] Top level kvm-userspace

[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/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] [kvm-devel] Top level kvm-userspace

[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/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] [kvm-devel] Top level kvm-userspace directory

[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/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] [kvm-devel] Top level kvm-userspace

[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/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] [kvm-devel] Top level kvm-userspace directory

[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/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] [kvm-devel] Top level kvm-userspace directory

[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/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] [kvm-devel] Top level

[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/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

Re: [kvm-ppc-devel] [kvm-devel] Top level kvm-userspace directory

[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/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel