All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [oe-commits] Joshua Lock : netbase: remove redundant assignments
Date: Mon, 27 Feb 2012 12:47:13 +0000	[thread overview]
Message-ID: <1330346833.4593.22.camel@ted> (raw)
In-Reply-To: <20120227123641.GH3859@jama.jama.net>

On Mon, 2012-02-27 at 13:36 +0100, Martin Jansa wrote:
> On Mon, Feb 27, 2012 at 12:13:48PM +0000, Richard Purdie wrote:
> > On Mon, 2012-02-27 at 12:31 +0100, Koen Kooi wrote:
> > > Op 27 feb. 2012, om 11:33 heeft Martin Jansa het volgende geschreven:
> > > 
> > > > On Wed, Feb 22, 2012 at 10:13:09PM +0000, git@git.openembedded.org wrote:
> > > >> Module: openembedded-core.git
> > > >> Branch: master
> > > >> Commit: c3d5800d2850a186f91b5a0db642aa5d1c20156b
> > > >> URL:    http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=c3d5800d2850a186f91b5a0db642aa5d1c20156b
> > > >> 
> > > >> Author: Joshua Lock <josh@linux.intel.com>
> > > >> Date:   Tue Feb 21 17:46:44 2012 -0800
> > > >> 
> > > >> netbase: remove redundant assignments
> > > >> 
> > > >> There's no need to explicitly set PACKAGE_ARCH = MACHINE_ARCH, base.bbclass
> > > >> takes care of setting this value for us based on the interfaces for those
> > > >> machines being an OVERRIDE.
> > > > 
> > > > do_install () {
> > > > ...
> > > >        # Disable network manager on machines that commonly do NFS booting
> > > >        case "${MACHINE}" in
> > > >                "qemuarm" | "qemux86" | "qemux86-64" | "qemumips" | "qemuppc" )
> > > > 
> > > > This causes do_install hash to depend on MACHINE variable for all MACHINEs, 
> > > > so making whole recipe MACHINE_ARCH would be more effective then rebuilding 
> > > > TARGET_ARCH package after every MACHINE switch.
> > > 
> > > That whole bit needs to go into the specific nfs image recipe, not
> > > into the recipe. Unless we decide nfs is the one and only way to boot
> > > qemu machines.
> > 
> > Clearly the qemu machines boot on non-nfs setups just fine and the
> > comment is just a bit stale here.
> > 
> > For qemu we expect the IP address to be stable and consistent so we know
> > where to find it and we don't expect it to disappear. The problem was
> > that if network manager starts poking around the main ethernet
> > interface, anything can go wrong (e.g. random QA test failures if
> > networkmanager decided to change the interface at the wrong moment). We
> > therefore really do know better than network manager when it comes to
> > ethernet connectivity into our qemu images.
> > 
> > There are a few options here:
> > 
> > a) Whitelist the MACHINE variable in hashes apart from the qemu machines
> > 
> > b) Change the code to a do_install_append_qemu* which would mean the
> > hashes become stable.
> 
> I'm fine with this but maybe then return PACKAGE_ARCH setting for them
> as we would be assuming that every machine with such append also have
> own interfaces file in SRC_URI (this is now true better to see it
> explicitly set above do_install_append_qemu* statement IMHO).

Agreed.

> > c) Shove the information into a qemu specific package. 
> > 
> > The trouble with c) before everyone decides its the best is how/when do
> > you include that package. It really needs to be present whenever network
> > manager is present. I don't want to end up with someone installing it
> > from feeds and getting different behaviour as it would be a nightmare to
> > debug.
> 
> Bit of off-topic, but do we really need
> EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
> in meta/conf/machine/include/qemu.inc?
> 
> My guess is that in many cases host running builds isn't the same box
> where someone is using native qemu to test those images. (e.g. in my
> case I'm running builds in minimal chroot, while using distribution qemu
> to test resulting images).

We have a lot of manuals and user expectation that:

bitbake some-image
runqemu some-image

'just works'. That dependency is the only way we can ensure it :/

Cheers,

Richard




  reply	other threads:[~2012-02-27 12:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20120222221309.69BFD10336@opal>
2012-02-27 10:33 ` [oe-commits] Joshua Lock : netbase: remove redundant assignments Martin Jansa
2012-02-27 11:31   ` Koen Kooi
2012-02-27 12:13     ` Richard Purdie
2012-02-27 12:36       ` Martin Jansa
2012-02-27 12:47         ` Richard Purdie [this message]
2012-02-27 13:46           ` Martin Jansa
2012-02-27 13:26       ` Koen Kooi
2012-02-27 13:31         ` Otavio Salvador
2012-02-27 20:19           ` Koen Kooi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1330346833.4593.22.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.