[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kvm-ppc
Subject:    Re: [kvm-ppc-devel] [kvm-devel] Top level
From:       Jerone Young <jyoung5 () us ! ibm ! com>
Date:       2008-02-28 20:28:52
Message-ID: 1204230532.12181.40.camel () thinkpad ! austin ! ibm ! com
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]