From: Patrick Ohly <patrick.ohly@intel.com>
To: "Bystricky, Juro" <juro.bystricky@intel.com>
Cc: "openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH v5 09/12] runqemu: also accept -image suffix for rootfs parameter
Date: Fri, 27 Jan 2017 20:22:27 +0100 [thread overview]
Message-ID: <1485544947.20333.119.camel@intel.com> (raw)
In-Reply-To: <6E51916E4A1F32428260031F4C7CD2B6118F7EEC@ORSMSX112.amr.corp.intel.com>
On Fri, 2017-01-27 at 16:54 +0000, Bystricky, Juro wrote:
> Just curious: is this test for "image" in file name really necessary?
> With qemuboot.conf the relevant files are already spelled out.
> I don't see a need to force "compulsory" names for images.
> If I comment out this test, everything works just fine. Am I missing something?
Some of the usages when checking for paths might have become obsolete,
but at least for distinguishing between machine and image base name
parameters it is still relevant:
def check_args(self):
...
elif re.search(r'-image-|-image$', arg):
# Lazy rootfs
self.rootfs = arg
elif arg.startswith('ovmf'):
self.ovmf_bios.append(arg)
else:
# At last, assume is it the MACHINE
if (not unknown_arg) or unknown_arg == arg:
unknown_arg = arg
else:
raise Exception("Can't handle two unknown args: %s %
s" % (unknown_arg, arg))
When removing the "if re.search(r'-image-|-image$', arg)" clause one
gets an error for:
$ runqemu core-image-minimal ext4 qemux86
runqemu - ERROR - Can't handle two unknown args: core-image-minimal qemux86
runqemu - ERROR - Try 'runqemu help' on how to use it
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
next prev parent reply other threads:[~2017-01-27 19:22 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-27 15:30 [PATCH v5 00/12] UEFI + Secure Boot + qemu Patrick Ohly
2017-01-27 15:30 ` [PATCH v5 01/12] acpica: move from meta-oe to OE-core Patrick Ohly
2017-02-17 21:13 ` Richard Purdie
2017-02-18 2:02 ` Khem Raj
2017-02-18 8:03 ` Patrick Ohly
2017-01-27 15:30 ` [PATCH v5 02/12] acpica: work around flex 2.6.2 code generation issue Patrick Ohly
2017-01-27 15:30 ` [PATCH v5 03/12] ovmf: move from meta-luv to OE-core Patrick Ohly
2017-02-17 21:10 ` Richard Purdie
2017-02-18 2:04 ` Khem Raj
2017-02-23 17:47 ` Patrick Ohly
2017-02-23 17:48 ` [PATCH 1/2] acpica: fix compilation with musl Patrick Ohly
2017-02-23 17:48 ` [PATCH 2/2] ovmf: increase path length limit Patrick Ohly
2017-02-24 0:57 ` Patrick Ohly
2017-02-24 0:58 ` [PATCH v2] " Patrick Ohly
2017-02-18 8:05 ` [PATCH v5 03/12] ovmf: move from meta-luv to OE-core Patrick Ohly
2017-01-27 15:30 ` [PATCH v5 04/12] ovmf: explicitly depend on nasm-native Patrick Ohly
2017-01-27 15:30 ` [PATCH v5 05/12] ovmf: deploy firmware in image directory Patrick Ohly
2017-01-27 15:30 ` [PATCH v5 06/12] ovmf_git.bb: enable parallel compilation Patrick Ohly
2017-01-27 15:30 ` [PATCH v5 07/12] ovmf_git.bb: enable Secure Boot Patrick Ohly
2017-01-27 15:30 ` [PATCH v5 08/12] runqemu: fix undefined variable reference in check_arg_path() Patrick Ohly
2017-01-27 15:30 ` [PATCH v5 09/12] runqemu: also accept -image suffix for rootfs parameter Patrick Ohly
2017-01-27 16:54 ` Bystricky, Juro
2017-01-27 19:22 ` Patrick Ohly [this message]
2017-01-30 17:12 ` Bystricky, Juro
2017-01-30 19:10 ` Patrick Ohly
2017-01-27 15:30 ` [PATCH v5 10/12] runqemu: support UEFI with OVMF firmware Patrick Ohly
2017-01-27 15:30 ` [PATCH v5 11/12] ovmf: build image which enrolls standard keys Patrick Ohly
2017-01-27 15:30 ` [PATCH v5 12/12] ovmf: remove BGRT patch Patrick Ohly
2017-01-27 15:53 ` ✗ patchtest: failure for UEFI + Secure Boot + qemu (rev6) Patchwork
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=1485544947.20333.119.camel@intel.com \
--to=patrick.ohly@intel.com \
--cc=juro.bystricky@intel.com \
--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.