[PATCH] qemu-native: depend on unfs-server-native

[PATCH] qemu-native: depend on unfs-server-native

[Jason Wessel]

The user mode NFS server does not get built by default when you are
using a purely command line driven development environment without SDK
tools.  In order to accommodate simple test configurations and have
all the tools built for the minimal validation with qemu-native,
simply add the dependency to unfs-server-native.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
 meta/conf/machine/include/qemu.inc |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc
index 421a149..742b629 100644
--- a/meta/conf/machine/include/qemu.inc
+++ b/meta/conf/machine/include/qemu.inc
@@ -14,4 +14,4 @@ RDEPENDS_kernel-base = ""
 # Use a common kernel recipe for all QEMU machines
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 
-EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
+EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native unfs-server-native"
-- 
1.6.6.2

Re: [PATCH] qemu-native: depend on unfs-server-native

[Koen Kooi]

Op 2 mei 2012, om 16:23 heeft Jason Wessel het volgende geschreven:

> The user mode NFS server does not get built by default when you are
> using a purely command line driven development environment without SDK
> tools.  In order to accommodate simple test configurations and have
> all the tools built for the minimal validation with qemu-native,
> simply add the dependency to unfs-server-native.

So all images I build for e.g. qemux86 now have an nfs-server? Can we please move settings like that to the specific images?

Re: [PATCH] qemu-native: depend on unfs-server-native

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]

On Wed, May 02, 2012 at 04:29:54PM +0200, Koen Kooi wrote:
> 
> Op 2 mei 2012, om 16:23 heeft Jason Wessel het volgende geschreven:
> 
> > The user mode NFS server does not get built by default when you are
> > using a purely command line driven development environment without SDK
> > tools.  In order to accommodate simple test configurations and have
> > all the tools built for the minimal validation with qemu-native,
> > simply add the dependency to unfs-server-native.
> 
> So all images I build for e.g. qemux86 now have an nfs-server? Can we please move settings like that to the specific images?

with qemu-native qemu-helper-native if possible :)

Cheers,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [PATCH] qemu-native: depend on unfs-server-native

[Jason Wessel]

On 05/02/2012 09:29 AM, Koen Kooi wrote:
> Op 2 mei 2012, om 16:23 heeft Jason Wessel het volgende geschreven:
>
>> The user mode NFS server does not get built by default when you are
>> using a purely command line driven development environment without SDK
>> tools.  In order to accommodate simple test configurations and have
>> all the tools built for the minimal validation with qemu-native,
>> simply add the dependency to unfs-server-native.
> So all images I build for e.g. qemux86 now have an nfs-server? Can we please move settings like that to the specific images?
>

This is part of the simulation environment.  Not all of the run qemu functionality works correctly without this.

Jason.

Re: [PATCH] qemu-native: depend on unfs-server-native

[Koen Kooi]

Op 2 mei 2012, om 16:33 heeft Jason Wessel het volgende geschreven:

> On 05/02/2012 09:29 AM, Koen Kooi wrote:
>> Op 2 mei 2012, om 16:23 heeft Jason Wessel het volgende geschreven:
>> 
>>> The user mode NFS server does not get built by default when you are
>>> using a purely command line driven development environment without SDK
>>> tools.  In order to accommodate simple test configurations and have
>>> all the tools built for the minimal validation with qemu-native,
>>> simply add the dependency to unfs-server-native.
>> So all images I build for e.g. qemux86 now have an nfs-server? Can we please move settings like that to the specific images?
>> 
> 
> This is part of the simulation environment.  Not all of the run qemu functionality works correctly without this.

I repeat:  Can we please move settings like that to the specific images?

I don't need nor want nfs servers in the images I build for qemu. And they work just fine without it.

Re: [PATCH] qemu-native: depend on unfs-server-native

[Jason Wessel]

On 05/02/2012 09:44 AM, Koen Kooi wrote:
> Op 2 mei 2012, om 16:33 heeft Jason Wessel het volgende geschreven:
>
>> On 05/02/2012 09:29 AM, Koen Kooi wrote:
>>> Op 2 mei 2012, om 16:23 heeft Jason Wessel het volgende geschreven:
>>>
>>>> The user mode NFS server does not get built by default when you are
>>>> using a purely command line driven development environment without SDK
>>>> tools.  In order to accommodate simple test configurations and have
>>>> all the tools built for the minimal validation with qemu-native,
>>>> simply add the dependency to unfs-server-native.
>>> So all images I build for e.g. qemux86 now have an nfs-server? Can we please move settings like that to the specific images?
>>>
>> This is part of the simulation environment.  Not all of the run qemu functionality works correctly without this.
> I repeat:  Can we please move settings like that to the specific images?
>
> I don't need nor want nfs servers in the images I build for qemu. And they work just fine without it.

Are you advocating that you really want to make the system harder to use where somethings just do not work out of the box for no obvious reason?   I realize that for your particular use case everything works fine, or you would be submitting patches to fix it.

The qemux86 appears to be a very generic BSP aimed at having an easy to use simulation environment.  If you build a minimal image it would seem that it should work for all the the runqemu boot methods out of the box with no additional steps.

If your BSP has no simulator, you will not be building QEMU and in theory, this is not an issue.

Example of what happens today:

1) . ../oe-init-build-env
2) bitbake core-image-minimal
3) runqemu-extract-sdk tmp/deploy/images/core-image-minimal-qemux86.tar.bz2 nfs
4) runqemu qemux86 nographic `pwd`/nfs
--- And now the error ---
Error: Unable to find rpc.mountd binary in /opt/poky/scratch/build/tmp/sysroots/x86_64-linux/usr/sbin/
--------------------------------


If you are in absolute disagreement with this patch, please suggest a way to accomplish the same thing with the same number of steps or fewer.  Arguably, I'd like to even go a step further and reduce this to 3 steps where the runqemu can auto extract the NFS root on demand if it is not already there.

It seems that the runqemu could also be modified to allow you to choose slirp networking such that no root access is needed at all for invoking the simulation.  All such changes are aimed at simplistic generic use of the generated images.

Cheers,
Jason.

Re: [PATCH] qemu-native: depend on unfs-server-native

[Koen Kooi]

Op 2 mei 2012, om 23:37 heeft Jason Wessel het volgende geschreven:

> On 05/02/2012 09:44 AM, Koen Kooi wrote:
>> Op 2 mei 2012, om 16:33 heeft Jason Wessel het volgende geschreven:
>> 
>>> On 05/02/2012 09:29 AM, Koen Kooi wrote:
>>>> Op 2 mei 2012, om 16:23 heeft Jason Wessel het volgende geschreven:
>>>> 
>>>>> The user mode NFS server does not get built by default when you are
>>>>> using a purely command line driven development environment without SDK
>>>>> tools.  In order to accommodate simple test configurations and have
>>>>> all the tools built for the minimal validation with qemu-native,
>>>>> simply add the dependency to unfs-server-native.
>>>> So all images I build for e.g. qemux86 now have an nfs-server? Can we please move settings like that to the specific images?
>>>> 
>>> This is part of the simulation environment.  Not all of the run qemu functionality works correctly without this.
>> I repeat:  Can we please move settings like that to the specific images?
>> 
>> I don't need nor want nfs servers in the images I build for qemu. And they work just fine without it.
> 
> Are you advocating that you really want to make the system harder to use where somethings just do not work out of the box for no obvious reason?

I'm advocating doing it the right way, if you want to throw a hissy fit over that, so be it.

>  I realize that for your particular use case everything works fine, or you would be submitting patches to fix it.
> 
> The qemux86 appears to be a very generic BSP aimed at having an easy to use simulation environment.  If you build a minimal image it would seem that it should work for all the the runqemu boot methods out of the box with no additional steps.

So add the dependencies to run the images to the images themselves.

> If your BSP has no simulator, you will not be building QEMU and in theory, this is not an issue.
> 
> Example of what happens today:
> 
> 1) . ../oe-init-build-env
> 2) bitbake core-image-minimal
> 3) runqemu-extract-sdk tmp/deploy/images/core-image-minimal-qemux86.tar.bz2 nfs
> 4) runqemu qemux86 nographic `pwd`/nfs
> --- And now the error ---
> Error: Unable to find rpc.mountd binary in /opt/poky/scratch/build/tmp/sysroots/x86_64-linux/usr/sbin/
> --------------------------------
> 
> 
> If you are in absolute disagreement with this patch,

I am.

> please suggest a way to accomplish the same thing with the same number of steps or fewer.

Move the IMAGE_DEPENDS to the images themselves.

Re: [PATCH] qemu-native: depend on unfs-server-native

[Phil Blundell]

On Wed, 2012-05-02 at 16:44 +0200, Koen Kooi wrote:
> Op 2 mei 2012, om 16:33 heeft Jason Wessel het volgende geschreven:
> 
> > On 05/02/2012 09:29 AM, Koen Kooi wrote:
> >> Op 2 mei 2012, om 16:23 heeft Jason Wessel het volgende geschreven:
> >> 
> >>> The user mode NFS server does not get built by default when you are
> >>> using a purely command line driven development environment without SDK
> >>> tools.  In order to accommodate simple test configurations and have
> >>> all the tools built for the minimal validation with qemu-native,
> >>> simply add the dependency to unfs-server-native.
> >> So all images I build for e.g. qemux86 now have an nfs-server? Can we please move settings like that to the specific images?
> >> 
> > 
> > This is part of the simulation environment.  Not all of the run qemu functionality works correctly without this.
> 
> I repeat:  Can we please move settings like that to the specific images?
> 
> I don't need nor want nfs servers in the images I build for qemu. And they work just fine without it.

Surely unfs-server-native isn't going to go in the images, is it?  The
name rather suggests that it is a host-side tool.

The subject line for this patch is misleading, by the way.  Saying
"qemu-native:" at the beginning makes it sound as though you are
changing something about the qemu-native package, which turns out to not
be the case as far as I can tell.

p.

Re: [PATCH] qemu-native: depend on unfs-server-native

[Mark Hatle]

On 5/2/12 4:49 PM, Phil Blundell wrote:
> On Wed, 2012-05-02 at 16:44 +0200, Koen Kooi wrote:
>> Op 2 mei 2012, om 16:33 heeft Jason Wessel het volgende geschreven:
>>
>>> On 05/02/2012 09:29 AM, Koen Kooi wrote:
>>>> Op 2 mei 2012, om 16:23 heeft Jason Wessel het volgende geschreven:
>>>>
>>>>> The user mode NFS server does not get built by default when you are
>>>>> using a purely command line driven development environment without SDK
>>>>> tools.  In order to accommodate simple test configurations and have
>>>>> all the tools built for the minimal validation with qemu-native,
>>>>> simply add the dependency to unfs-server-native.
>>>> So all images I build for e.g. qemux86 now have an nfs-server? Can we please move settings like that to the specific images?
>>>>
>>>
>>> This is part of the simulation environment.  Not all of the run qemu functionality works correctly without this.
>>
>> I repeat:  Can we please move settings like that to the specific images?
>>
>> I don't need nor want nfs servers in the images I build for qemu. And they work just fine without it.
>
> Surely unfs-server-native isn't going to go in the images, is it?  The
> name rather suggests that it is a host-side tool.

 From looking at the proposed patch, the unfs-server-native is a -build- (image) 
dependency, but it's not ending up in the final image.

> The subject line for this patch is misleading, by the way.  Saying
> "qemu-native:" at the beginning makes it sound as though you are
> changing something about the qemu-native package, which turns out to not
> be the case as far as I can tell.

I think the summary line is a bit misleading for people familiar with OE-core 
short logs.

As I see it:

qemu.inc: Machines including qemu support should have the unfs server available

--Mark

> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH] qemu-native: depend on unfs-server-native

[Jason Wessel]

On 05/02/2012 04:49 PM, Phil Blundell wrote:
> On Wed, 2012-05-02 at 16:44 +0200, Koen Kooi wrote:
>> Op 2 mei 2012, om 16:33 heeft Jason Wessel het volgende geschreven:
>>
>>> On 05/02/2012 09:29 AM, Koen Kooi wrote:
>>>> Op 2 mei 2012, om 16:23 heeft Jason Wessel het volgende geschreven:
>>>>
>>>>> The user mode NFS server does not get built by default when you are
>>>>> using a purely command line driven development environment without SDK
>>>>> tools.  In order to accommodate simple test configurations and have
>>>>> all the tools built for the minimal validation with qemu-native,
>>>>> simply add the dependency to unfs-server-native.
>>>> So all images I build for e.g. qemux86 now have an nfs-server? Can we please move settings like that to the specific images?
>>>>
>>>
>>> This is part of the simulation environment.  Not all of the run qemu functionality works correctly without this.
>>
>> I repeat:  Can we please move settings like that to the specific images?
>>
>> I don't need nor want nfs servers in the images I build for qemu. And they work just fine without it.
> 
> Surely unfs-server-native isn't going to go in the images, is it?  The
> name rather suggests that it is a host-side tool.
> 
> The subject line for this patch is misleading, by the way.  Saying
> "qemu-native:" at the beginning makes it sound as though you are
> changing something about the qemu-native package, which turns out to not
> be the case as far as I can tell.
> 

There is nothing that is actually added to the target side image.  It is just a host tool. 

It was suggested to me that a better title for the patch is:

   qemu.inc: Ensure qemu compatible machines have the usermode nfs server available to them


Jason.

Re: [PATCH] qemu-native: depend on unfs-server-native

[Khem Raj]

On Wed, May 2, 2012 at 7:23 AM, Jason Wessel <jason.wessel@windriver.com> wrote:
> The user mode NFS server does not get built by default when you are
> using a purely command line driven development environment without SDK
> tools.  In order to accommodate simple test configurations and have
> all the tools built for the minimal validation with qemu-native,
> simply add the dependency to unfs-server-native.
>
> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
> ---
>  meta/conf/machine/include/qemu.inc |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc
> index 421a149..742b629 100644
> --- a/meta/conf/machine/include/qemu.inc
> +++ b/meta/conf/machine/include/qemu.inc
> @@ -14,4 +14,4 @@ RDEPENDS_kernel-base = ""
>  # Use a common kernel recipe for all QEMU machines
>  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
>
> -EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
> +EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native unfs-server-native"
> --

how about replacing  EXTRA_IMAGEDEPENDS with
MACHINE_ESSENTIAL_EXTRA_RDEPENDS here ?

> 1.6.6.2
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH] qemu-native: depend on unfs-server-native

[Koen Kooi]

Op 3 mei 2012, om 09:32 heeft Khem Raj het volgende geschreven:

> On Wed, May 2, 2012 at 7:23 AM, Jason Wessel <jason.wessel@windriver.com> wrote:
>> The user mode NFS server does not get built by default when you are
>> using a purely command line driven development environment without SDK
>> tools.  In order to accommodate simple test configurations and have
>> all the tools built for the minimal validation with qemu-native,
>> simply add the dependency to unfs-server-native.
>> 
>> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
>> ---
>>  meta/conf/machine/include/qemu.inc |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>> 
>> diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc
>> index 421a149..742b629 100644
>> --- a/meta/conf/machine/include/qemu.inc
>> +++ b/meta/conf/machine/include/qemu.inc
>> @@ -14,4 +14,4 @@ RDEPENDS_kernel-base = ""
>>  # Use a common kernel recipe for all QEMU machines
>>  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
>> 
>> -EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
>> +EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native unfs-server-native"
>> --
> 
> how about replacing  EXTRA_IMAGEDEPENDS with
> MACHINE_ESSENTIAL_EXTRA_RDEPENDS here ?

RDEPENDS end up in the image, IMAGEDEPENDS are needed to build the image. Do I need qemu-native, helper-native and unfs to build the image? No I don't. Would I need it if I decide to run the runqemu scripts, yes. Do these extra dependencies cause pain? Yes, since it requires installing tons of extra things on a headless buildserver (mesa, sdl) to just build an image.

If I wanted to be an ass I would suggest moving qemu-native, qemu-helper-native and unfs-server-native to the HOB, but I won't do that.

So I'll stick with my original suggestion: move those dependencies to the images you want to run on nfs for qemu, don't pollute the global EXTRA_IMAGEDEPENDS with it.

Re: [PATCH] qemu-native: depend on unfs-server-native

[Richard Purdie]

On Thu, 2012-05-03 at 09:43 +0200, Koen Kooi wrote:
> Op 3 mei 2012, om 09:32 heeft Khem Raj het volgende geschreven:
> 
> > On Wed, May 2, 2012 at 7:23 AM, Jason Wessel <jason.wessel@windriver.com> wrote:
> >> The user mode NFS server does not get built by default when you are
> >> using a purely command line driven development environment without SDK
> >> tools.  In order to accommodate simple test configurations and have
> >> all the tools built for the minimal validation with qemu-native,
> >> simply add the dependency to unfs-server-native.
> >> 
> >> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
> >> ---
> >>  meta/conf/machine/include/qemu.inc |    2 +-
> >>  1 files changed, 1 insertions(+), 1 deletions(-)
> >> 
> >> diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc
> >> index 421a149..742b629 100644
> >> --- a/meta/conf/machine/include/qemu.inc
> >> +++ b/meta/conf/machine/include/qemu.inc
> >> @@ -14,4 +14,4 @@ RDEPENDS_kernel-base = ""
> >>  # Use a common kernel recipe for all QEMU machines
> >>  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
> >> 
> >> -EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
> >> +EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native unfs-server-native"
> >> --
> > 
> > how about replacing  EXTRA_IMAGEDEPENDS with
> > MACHINE_ESSENTIAL_EXTRA_RDEPENDS here ?
>
> RDEPENDS end up in the image, IMAGEDEPENDS are needed to build the
> image. Do I need qemu-native, helper-native and unfs to build the
> image? No I don't. Would I need it if I decide to run the runqemu
> scripts, yes. Do these extra dependencies cause pain? Yes, since it
> requires installing tons of extra things on a headless buildserver
> (mesa, sdl) to just build an image.
>
> If I wanted to be an ass I would suggest moving qemu-native,
> qemu-helper-native and unfs-server-native to the HOB, but I won't do
> that.
>
> So I'll stick with my original suggestion: move those dependencies to
> the images you want to run on nfs for qemu, don't pollute the global
> EXTRA_IMAGEDEPENDS with it.

If I wanted to be an ass here I'd just add them to the image class
conditional on qemu. This would be a little pointless and needlessly
complicate things though.

The point of these is to trigger them to build whenever a qemu image is
built. This makes a lot of sense in some use cases, it also does not
make sense in some other cases and it is not possible for the system to
mind read and tell the difference.

I'd suggest we change this to something like:

QEMUIMAGEDEPENDS ??= "qemu-native qemu-helper-native unfs-server-native"
EXTRA_IMAGEDEPENDS += "${QEMUIMAGEDEPENDS}"

and then people can set QEMUIMAGEDEPENDS = "" if they want.

Cheers,

Richard

Re: [PATCH] qemu-native: depend on unfs-server-native

[Koen Kooi]

Op 3 mei 2012, om 10:47 heeft Richard Purdie het volgende geschreven:

> On Thu, 2012-05-03 at 09:43 +0200, Koen Kooi wrote:
>> Op 3 mei 2012, om 09:32 heeft Khem Raj het volgende geschreven:
>> 
>>> On Wed, May 2, 2012 at 7:23 AM, Jason Wessel <jason.wessel@windriver.com> wrote:
>>>> The user mode NFS server does not get built by default when you are
>>>> using a purely command line driven development environment without SDK
>>>> tools.  In order to accommodate simple test configurations and have
>>>> all the tools built for the minimal validation with qemu-native,
>>>> simply add the dependency to unfs-server-native.
>>>> 
>>>> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
>>>> ---
>>>> meta/conf/machine/include/qemu.inc |    2 +-
>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>> 
>>>> diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc
>>>> index 421a149..742b629 100644
>>>> --- a/meta/conf/machine/include/qemu.inc
>>>> +++ b/meta/conf/machine/include/qemu.inc
>>>> @@ -14,4 +14,4 @@ RDEPENDS_kernel-base = ""
>>>> # Use a common kernel recipe for all QEMU machines
>>>> PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
>>>> 
>>>> -EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
>>>> +EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native unfs-server-native"
>>>> --
>>> 
>>> how about replacing  EXTRA_IMAGEDEPENDS with
>>> MACHINE_ESSENTIAL_EXTRA_RDEPENDS here ?
>> 
>> RDEPENDS end up in the image, IMAGEDEPENDS are needed to build the
>> image. Do I need qemu-native, helper-native and unfs to build the
>> image? No I don't. Would I need it if I decide to run the runqemu
>> scripts, yes. Do these extra dependencies cause pain? Yes, since it
>> requires installing tons of extra things on a headless buildserver
>> (mesa, sdl) to just build an image.
>> 
>> If I wanted to be an ass I would suggest moving qemu-native,
>> qemu-helper-native and unfs-server-native to the HOB, but I won't do
>> that.
>> 
>> So I'll stick with my original suggestion: move those dependencies to
>> the images you want to run on nfs for qemu, don't pollute the global
>> EXTRA_IMAGEDEPENDS with it.
> 
> If I wanted to be an ass here I'd just add them to the image class
> conditional on qemu. This would be a little pointless and needlessly
> complicate things though.
> 
> The point of these is to trigger them to build whenever a qemu image is
> built. This makes a lot of sense in some use cases, it also does not
> make sense in some other cases and it is not possible for the system to
> mind read and tell the difference.

What about having the runqemu* scripts call bitbake to build the -native helpers when they are missing? 

regards,

Koen

Re: [PATCH] qemu-native: depend on unfs-server-native

[Jason Wessel]

On 05/03/2012 05:39 AM, Koen Kooi wrote:
> 
> Op 3 mei 2012, om 10:47 heeft Richard Purdie het volgende geschreven:
> 
>>
>> The point of these is to trigger them to build whenever a qemu image is
>> built. This makes a lot of sense in some use cases, it also does not
>> make sense in some other cases and it is not possible for the system to
>> mind read and tell the difference.
> 
> What about having the runqemu* scripts call bitbake to build the -native helpers when they are missing? 
> 

Clearly this works from the usability angle of keeping a minimal number of steps, but there are two side effects because it is implemented as a "if helper binary exists ; then bitbake ...".  

1) Everything you need to get started was not really there after completing the build
2) If the qemu helpers are updated they will not get rebuilt when you run your typical rebuild
    *** NOTE I realize that this probably does not happen too often, but it is a possibility

I would certainly not want bitbake to run each time you invoke runqemu to check if it is updated because that unnecessarily delays the start of the simulator.  It would seem to me the best approach is to use Richard's idea so as to allow folks to not build the helpers if someone really doesn't want them, as well as have runqemu auto build the helpers if they are not there so as to keep the use cases simple.

Respectfully,
Jason.

Re: [PATCH] qemu-native: depend on unfs-server-native

[Richard Purdie]

On Thu, 2012-05-03 at 12:39 +0200, Koen Kooi wrote:
> Op 3 mei 2012, om 10:47 heeft Richard Purdie het volgende geschreven:
> 
> > On Thu, 2012-05-03 at 09:43 +0200, Koen Kooi wrote:
> >> Op 3 mei 2012, om 09:32 heeft Khem Raj het volgende geschreven:
> >> 
> >>> On Wed, May 2, 2012 at 7:23 AM, Jason Wessel <jason.wessel@windriver.com> wrote:
> >>>> The user mode NFS server does not get built by default when you are
> >>>> using a purely command line driven development environment without SDK
> >>>> tools.  In order to accommodate simple test configurations and have
> >>>> all the tools built for the minimal validation with qemu-native,
> >>>> simply add the dependency to unfs-server-native.
> >>>> 
> >>>> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
> >>>> ---
> >>>> meta/conf/machine/include/qemu.inc |    2 +-
> >>>> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>>> 
> >>>> diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc
> >>>> index 421a149..742b629 100644
> >>>> --- a/meta/conf/machine/include/qemu.inc
> >>>> +++ b/meta/conf/machine/include/qemu.inc
> >>>> @@ -14,4 +14,4 @@ RDEPENDS_kernel-base = ""
> >>>> # Use a common kernel recipe for all QEMU machines
> >>>> PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
> >>>> 
> >>>> -EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
> >>>> +EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native unfs-server-native"
> >>>> --
> >>> 
> >>> how about replacing  EXTRA_IMAGEDEPENDS with
> >>> MACHINE_ESSENTIAL_EXTRA_RDEPENDS here ?
> >> 
> >> RDEPENDS end up in the image, IMAGEDEPENDS are needed to build the
> >> image. Do I need qemu-native, helper-native and unfs to build the
> >> image? No I don't. Would I need it if I decide to run the runqemu
> >> scripts, yes. Do these extra dependencies cause pain? Yes, since it
> >> requires installing tons of extra things on a headless buildserver
> >> (mesa, sdl) to just build an image.
> >> 
> >> If I wanted to be an ass I would suggest moving qemu-native,
> >> qemu-helper-native and unfs-server-native to the HOB, but I won't do
> >> that.
> >> 
> >> So I'll stick with my original suggestion: move those dependencies to
> >> the images you want to run on nfs for qemu, don't pollute the global
> >> EXTRA_IMAGEDEPENDS with it.
> > 
> > If I wanted to be an ass here I'd just add them to the image class
> > conditional on qemu. This would be a little pointless and needlessly
> > complicate things though.
> > 
> > The point of these is to trigger them to build whenever a qemu image is
> > built. This makes a lot of sense in some use cases, it also does not
> > make sense in some other cases and it is not possible for the system to
> > mind read and tell the difference.
> 
> What about having the runqemu* scripts call bitbake to build the
> -native helpers when they are missing? 

The whole point with the qemu emulated machines is that you build them
and they work for new users easily and efficiently. I don't think
calling bitbake to build them and force the user into another wait is a
good usability model to be promoting.

I'm also slightly bemused that in previous discussions you've implied
build time is less relevant then functionality yet here you're taking
the opposite stance :).

Cheers,

Richard

Re: [PATCH] qemu-native: depend on unfs-server-native

[Koen Kooi]

Op 3 mei 2012, om 13:24 heeft Richard Purdie het volgende geschreven:

> On Thu, 2012-05-03 at 12:39 +0200, Koen Kooi wrote:
>> Op 3 mei 2012, om 10:47 heeft Richard Purdie het volgende geschreven:
>> 
>>> On Thu, 2012-05-03 at 09:43 +0200, Koen Kooi wrote:
>>>> Op 3 mei 2012, om 09:32 heeft Khem Raj het volgende geschreven:
>>>> 
>>>>> On Wed, May 2, 2012 at 7:23 AM, Jason Wessel <jason.wessel@windriver.com> wrote:
>>>>>> The user mode NFS server does not get built by default when you are
>>>>>> using a purely command line driven development environment without SDK
>>>>>> tools.  In order to accommodate simple test configurations and have
>>>>>> all the tools built for the minimal validation with qemu-native,
>>>>>> simply add the dependency to unfs-server-native.
>>>>>> 
>>>>>> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
>>>>>> ---
>>>>>> meta/conf/machine/include/qemu.inc |    2 +-
>>>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>> 
>>>>>> diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc
>>>>>> index 421a149..742b629 100644
>>>>>> --- a/meta/conf/machine/include/qemu.inc
>>>>>> +++ b/meta/conf/machine/include/qemu.inc
>>>>>> @@ -14,4 +14,4 @@ RDEPENDS_kernel-base = ""
>>>>>> # Use a common kernel recipe for all QEMU machines
>>>>>> PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
>>>>>> 
>>>>>> -EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
>>>>>> +EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native unfs-server-native"
>>>>>> --
>>>>> 
>>>>> how about replacing  EXTRA_IMAGEDEPENDS with
>>>>> MACHINE_ESSENTIAL_EXTRA_RDEPENDS here ?
>>>> 
>>>> RDEPENDS end up in the image, IMAGEDEPENDS are needed to build the
>>>> image. Do I need qemu-native, helper-native and unfs to build the
>>>> image? No I don't. Would I need it if I decide to run the runqemu
>>>> scripts, yes. Do these extra dependencies cause pain? Yes, since it
>>>> requires installing tons of extra things on a headless buildserver
>>>> (mesa, sdl) to just build an image.
>>>> 
>>>> If I wanted to be an ass I would suggest moving qemu-native,
>>>> qemu-helper-native and unfs-server-native to the HOB, but I won't do
>>>> that.
>>>> 
>>>> So I'll stick with my original suggestion: move those dependencies to
>>>> the images you want to run on nfs for qemu, don't pollute the global
>>>> EXTRA_IMAGEDEPENDS with it.
>>> 
>>> If I wanted to be an ass here I'd just add them to the image class
>>> conditional on qemu. This would be a little pointless and needlessly
>>> complicate things though.
>>> 
>>> The point of these is to trigger them to build whenever a qemu image is
>>> built. This makes a lot of sense in some use cases, it also does not
>>> make sense in some other cases and it is not possible for the system to
>>> mind read and tell the difference.
>> 
>> What about having the runqemu* scripts call bitbake to build the
>> -native helpers when they are missing? 
> 
> The whole point with the qemu emulated machines is that you build them
> and they work for new users easily and efficiently. I don't think
> calling bitbake to build them and force the user into another wait is a
> good usability model to be promoting.

OE-core should set the right example and teaching people that a global IMAGE_DEPENDS is OK is not the right example. Especially when it actually causes breakage, see below.
If people insist that IMAGE_DEPENDS is the one and only way to provide the runqemu experience then at least put a big comment in the file saying why it's done and why people shouldn't be copy/pasting it into their layers.
And an indiciation where the line is drawn would be nice as well, I can imagine that someone wants to add amazon EC2 support to runqemu and sends a patch to add the EC2 tools to IMAGE_DEPENDS.

> I'm also slightly bemused that in previous discussions you've implied
> build time is less relevant then functionality yet here you're taking
> the opposite stance :).

I get build *failures* for the qemu machines because I don't have mesa and sdl installed on the autobuilder. But you are right, I do think build time is less relevant than functionality.

Re: [PATCH] qemu-native: depend on unfs-server-native

[Richard Purdie]

On Thu, 2012-05-03 at 13:39 +0200, Koen Kooi wrote:
> Op 3 mei 2012, om 13:24 heeft Richard Purdie het volgende geschreven:
> > The whole point with the qemu emulated machines is that you build them
> > and they work for new users easily and efficiently. I don't think
> > calling bitbake to build them and force the user into another wait is a
> > good usability model to be promoting.
> 
> OE-core should set the right example and teaching people that a global
> IMAGE_DEPENDS is OK is not the right example. Especially when it
> actually causes breakage, see below.
> If people insist that IMAGE_DEPENDS is the one and only way to provide
> the runqemu experience then at least put a big comment in the file
> saying why it's done and why people shouldn't be copy/pasting it into
> their layers.
> And an indiciation where the line is drawn would be nice as well, I
> can imagine that someone wants to add amazon EC2 support to runqemu
> and sends a patch to add the EC2 tools to IMAGE_DEPENDS.

I'm happy to see a comment. The line is quite clear, the documentation
associated with the qemu images, the quick start guide and other manuals
assume we build qemu-native and friends and for usability this is a
clear win. The manuals do not document EC2 and it is not something we
expect a new user to need to do easily. Running an extra "bitbake xxx"
or including an extra configuration file would be perfectly reasonable
for those usage scenarios.

> > I'm also slightly bemused that in previous discussions you've implied
> > build time is less relevant then functionality yet here you're taking
> > the opposite stance :).
> 
> I get build *failures* for the qemu machines because I don't have mesa
> and sdl installed on the autobuilder. But you are right, I do think
> build time is less relevant than functionality.

We should also consider setting up PACKAGECONFIG options in the qemu
recipe for these things so you can specify to build qemu-native without
sdl/gl easily. I appreciate that is going to be pretty nasty
implementation wise but I think it would help and in fact if someone
files the bug I'll mark it as a P1 for 1.3 since that does help
usability a lot.

Cheers,

Richard

Re: [PATCH] qemu-native: depend on unfs-server-native

[Koen Kooi]

Op 3 mei 2012, om 13:51 heeft Richard Purdie het volgende geschreven:

> On Thu, 2012-05-03 at 13:39 +0200, Koen Kooi wrote:
>> Op 3 mei 2012, om 13:24 heeft Richard Purdie het volgende geschreven:
>>> The whole point with the qemu emulated machines is that you build them
>>> and they work for new users easily and efficiently. I don't think
>>> calling bitbake to build them and force the user into another wait is a
>>> good usability model to be promoting.
>> 
>> OE-core should set the right example and teaching people that a global
>> IMAGE_DEPENDS is OK is not the right example. Especially when it
>> actually causes breakage, see below.
>> If people insist that IMAGE_DEPENDS is the one and only way to provide
>> the runqemu experience then at least put a big comment in the file
>> saying why it's done and why people shouldn't be copy/pasting it into
>> their layers.
>> And an indiciation where the line is drawn would be nice as well, I
>> can imagine that someone wants to add amazon EC2 support to runqemu
>> and sends a patch to add the EC2 tools to IMAGE_DEPENDS.
> 
> I'm happy to see a comment. The line is quite clear, the documentation
> associated with the qemu images, the quick start guide and other manuals
> assume we build qemu-native and friends and for usability this is a
> clear win. The manuals do not document EC2 and it is not something we
> expect a new user to need to do easily. Running an extra "bitbake xxx"
> or including an extra configuration file would be perfectly reasonable
> for those usage scenarios.
> 
>>> I'm also slightly bemused that in previous discussions you've implied
>>> build time is less relevant then functionality yet here you're taking
>>> the opposite stance :).
>> 
>> I get build *failures* for the qemu machines because I don't have mesa
>> and sdl installed on the autobuilder. But you are right, I do think
>> build time is less relevant than functionality.
> 
> We should also consider setting up PACKAGECONFIG options in the qemu
> recipe for these things so you can specify to build qemu-native without
> sdl/gl easily. I appreciate that is going to be pretty nasty
> implementation wise but I think it would help and in fact if someone
> files the bug I'll mark it as a P1 for 1.3 since that does help
> usability a lot.

#2402 and it's already going the WONTFIX way

Re: [PATCH] qemu-native: depend on unfs-server-native

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]

On Fri, May 04, 2012 at 08:13:06AM +0200, Koen Kooi wrote:
> 
> Op 3 mei 2012, om 13:51 heeft Richard Purdie het volgende geschreven:
> 
> > On Thu, 2012-05-03 at 13:39 +0200, Koen Kooi wrote:
> >> Op 3 mei 2012, om 13:24 heeft Richard Purdie het volgende geschreven:
> >>> The whole point with the qemu emulated machines is that you build them
> >>> and they work for new users easily and efficiently. I don't think
> >>> calling bitbake to build them and force the user into another wait is a
> >>> good usability model to be promoting.
> >> 
> >> OE-core should set the right example and teaching people that a global
> >> IMAGE_DEPENDS is OK is not the right example. Especially when it
> >> actually causes breakage, see below.
> >> If people insist that IMAGE_DEPENDS is the one and only way to provide
> >> the runqemu experience then at least put a big comment in the file
> >> saying why it's done and why people shouldn't be copy/pasting it into
> >> their layers.
> >> And an indiciation where the line is drawn would be nice as well, I
> >> can imagine that someone wants to add amazon EC2 support to runqemu
> >> and sends a patch to add the EC2 tools to IMAGE_DEPENDS.
> > 
> > I'm happy to see a comment. The line is quite clear, the documentation
> > associated with the qemu images, the quick start guide and other manuals
> > assume we build qemu-native and friends and for usability this is a
> > clear win. The manuals do not document EC2 and it is not something we
> > expect a new user to need to do easily. Running an extra "bitbake xxx"
> > or including an extra configuration file would be perfectly reasonable
> > for those usage scenarios.
> > 
> >>> I'm also slightly bemused that in previous discussions you've implied
> >>> build time is less relevant then functionality yet here you're taking
> >>> the opposite stance :).
> >> 
> >> I get build *failures* for the qemu machines because I don't have mesa
> >> and sdl installed on the autobuilder. But you are right, I do think
> >> build time is less relevant than functionality.
> > 
> > We should also consider setting up PACKAGECONFIG options in the qemu
> > recipe for these things so you can specify to build qemu-native without
> > sdl/gl easily. I appreciate that is going to be pretty nasty
> > implementation wise but I think it would help and in fact if someone
> > files the bug I'll mark it as a P1 for 1.3 since that does help
> > usability a lot.
> 
> #2402 and it's already going the WONTFIX way

#2407 ?

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [PATCH] qemu-native: depend on unfs-server-native

[Koen Kooi]

Op 4 mei 2012, om 08:32 heeft Martin Jansa het volgende geschreven:

> On Fri, May 04, 2012 at 08:13:06AM +0200, Koen Kooi wrote:
>> 
>> Op 3 mei 2012, om 13:51 heeft Richard Purdie het volgende geschreven:
>> 
>>> On Thu, 2012-05-03 at 13:39 +0200, Koen Kooi wrote:
>>>> Op 3 mei 2012, om 13:24 heeft Richard Purdie het volgende geschreven:
>>>>> The whole point with the qemu emulated machines is that you build them
>>>>> and they work for new users easily and efficiently. I don't think
>>>>> calling bitbake to build them and force the user into another wait is a
>>>>> good usability model to be promoting.
>>>> 
>>>> OE-core should set the right example and teaching people that a global
>>>> IMAGE_DEPENDS is OK is not the right example. Especially when it
>>>> actually causes breakage, see below.
>>>> If people insist that IMAGE_DEPENDS is the one and only way to provide
>>>> the runqemu experience then at least put a big comment in the file
>>>> saying why it's done and why people shouldn't be copy/pasting it into
>>>> their layers.
>>>> And an indiciation where the line is drawn would be nice as well, I
>>>> can imagine that someone wants to add amazon EC2 support to runqemu
>>>> and sends a patch to add the EC2 tools to IMAGE_DEPENDS.
>>> 
>>> I'm happy to see a comment. The line is quite clear, the documentation
>>> associated with the qemu images, the quick start guide and other manuals
>>> assume we build qemu-native and friends and for usability this is a
>>> clear win. The manuals do not document EC2 and it is not something we
>>> expect a new user to need to do easily. Running an extra "bitbake xxx"
>>> or including an extra configuration file would be perfectly reasonable
>>> for those usage scenarios.
>>> 
>>>>> I'm also slightly bemused that in previous discussions you've implied
>>>>> build time is less relevant then functionality yet here you're taking
>>>>> the opposite stance :).
>>>> 
>>>> I get build *failures* for the qemu machines because I don't have mesa
>>>> and sdl installed on the autobuilder. But you are right, I do think
>>>> build time is less relevant than functionality.
>>> 
>>> We should also consider setting up PACKAGECONFIG options in the qemu
>>> recipe for these things so you can specify to build qemu-native without
>>> sdl/gl easily. I appreciate that is going to be pretty nasty
>>> implementation wise but I think it would help and in fact if someone
>>> files the bug I'll mark it as a P1 for 1.3 since that does help
>>> usability a lot.
>> 
>> #2402 and it's already going the WONTFIX way
> 
> #2407 ?

-ENOCOFFEE, sorry

Re: [PATCH] qemu-native: depend on unfs-server-native

[Richard Purdie]

On Fri, 2012-05-04 at 08:50 +0200, Koen Kooi wrote:
> Op 4 mei 2012, om 08:32 heeft Martin Jansa het volgende geschreven:
> 
> > On Fri, May 04, 2012 at 08:13:06AM +0200, Koen Kooi wrote:
> >> 
> >> Op 3 mei 2012, om 13:51 heeft Richard Purdie het volgende geschreven:
> >> 
> >>> On Thu, 2012-05-03 at 13:39 +0200, Koen Kooi wrote:
> >>>> Op 3 mei 2012, om 13:24 heeft Richard Purdie het volgende geschreven:
> >>>>> The whole point with the qemu emulated machines is that you build them
> >>>>> and they work for new users easily and efficiently. I don't think
> >>>>> calling bitbake to build them and force the user into another wait is a
> >>>>> good usability model to be promoting.
> >>>> 
> >>>> OE-core should set the right example and teaching people that a global
> >>>> IMAGE_DEPENDS is OK is not the right example. Especially when it
> >>>> actually causes breakage, see below.
> >>>> If people insist that IMAGE_DEPENDS is the one and only way to provide
> >>>> the runqemu experience then at least put a big comment in the file
> >>>> saying why it's done and why people shouldn't be copy/pasting it into
> >>>> their layers.
> >>>> And an indiciation where the line is drawn would be nice as well, I
> >>>> can imagine that someone wants to add amazon EC2 support to runqemu
> >>>> and sends a patch to add the EC2 tools to IMAGE_DEPENDS.
> >>> 
> >>> I'm happy to see a comment. The line is quite clear, the documentation
> >>> associated with the qemu images, the quick start guide and other manuals
> >>> assume we build qemu-native and friends and for usability this is a
> >>> clear win. The manuals do not document EC2 and it is not something we
> >>> expect a new user to need to do easily. Running an extra "bitbake xxx"
> >>> or including an extra configuration file would be perfectly reasonable
> >>> for those usage scenarios.
> >>> 
> >>>>> I'm also slightly bemused that in previous discussions you've implied
> >>>>> build time is less relevant then functionality yet here you're taking
> >>>>> the opposite stance :).
> >>>> 
> >>>> I get build *failures* for the qemu machines because I don't have mesa
> >>>> and sdl installed on the autobuilder. But you are right, I do think
> >>>> build time is less relevant than functionality.
> >>> 
> >>> We should also consider setting up PACKAGECONFIG options in the qemu
> >>> recipe for these things so you can specify to build qemu-native without
> >>> sdl/gl easily. I appreciate that is going to be pretty nasty
> >>> implementation wise but I think it would help and in fact if someone
> >>> files the bug I'll mark it as a P1 for 1.3 since that does help
> >>> usability a lot.
> >> 
> >> #2402 and it's already going the WONTFIX way
> > 
> > #2407 ?
> 
> -ENOCOFFEE, sorry

I was wondering what remake had to do with this :). I've replied to the
bug, I don't think WONTFIX is appropriate in this case.

Cheers,

Richard