[OE-core] [PATCH] lib/oeqa: allow multiple layers to provide their own TEST_TARGET class
Use a python module "folder" rather than a single module within
layers to ensure multiple layers can define a TEST_TARGET class.
Current implementation using controllers.py module will only allow
a single layer to define test targets.
Add a controllers folder as well as a TestTargetLoader class whose
job is to load the given TEST_TARGET class from any number of
python modules within the oeqa/controllers/ directory of any
layer.
The only condition will be that layers will need to ensure
the TEST_TARGET class name they provide is unique otherwise there
is no guarantee which class is instantiated. a bb.warn is used
to alude to this if it happens.
Signed-off-by: Sipke Vriend
---
meta/lib/oeqa/controllers/__init__.py |3 ++
meta/lib/oeqa/controllers/testtargetloader.py | 69 +
meta/lib/oeqa/targetcontrol.py| 13 ++---
3 files changed, 79 insertions(+), 6 deletions(-)
create mode 100644 meta/lib/oeqa/controllers/__init__.py
create mode 100644 meta/lib/oeqa/controllers/testtargetloader.py
diff --git a/meta/lib/oeqa/controllers/__init__.py
b/meta/lib/oeqa/controllers/__init__.py
new file mode 100644
index 000..8eda927
--- /dev/null
+++ b/meta/lib/oeqa/controllers/__init__.py
@@ -0,0 +1,3 @@
+# Enable other layers to have modules in the same named directory
+from pkgutil import extend_path
+__path__ = extend_path(__path__, __name__)
diff --git a/meta/lib/oeqa/controllers/testtargetloader.py
b/meta/lib/oeqa/controllers/testtargetloader.py
new file mode 100644
index 000..019bbfd
--- /dev/null
+++ b/meta/lib/oeqa/controllers/testtargetloader.py
@@ -0,0 +1,69 @@
+import types
+import bb
+
+# This class is responsible for loading a test target controller
+class TestTargetLoader:
+
+# Search oeqa.controllers module directory for and return a controller
+# corresponding to the given target name.
+# AttributeError raised if not found.
+# ImportError raised if a provided module can not be imported.
+def get_controller_module(self, target, bbpath):
+controllerslist = self.get_controller_modulenames(bbpath)
+bb.note("Available controller modules: %s" % str(controllerslist))
+controller = self.load_controller_from_name(target, controllerslist)
+return controller
+
+# Return a list of all python modules in lib/oeqa/controllers for each
+# layer in bbpath
+def get_controller_modulenames(self, bbpath):
+
+controllerslist = []
+
+def add_controller_list(path):
+if not os.path.exists(os.path.join(path, '__init__.py')):
+bb.fatal('Controllers directory %s exists but is missing
__init__.py' % path)
+files = sorted([f for f in os.listdir(path) if f.endswith('.py')
and not f.startswith('_')])
+for f in files:
+module = 'oeqa.controllers.' + f[:-3]
+if module not in controllerslist:
+controllerslist.append(module)
+else:
+bb.warn("Duplicate controller module found for %s, only
one added. Layers should create unique controller module names" % module)
+
+for p in bbpath:
+controllerpath = os.path.join(p, 'lib', 'oeqa', 'controllers')
+bb.debug(2, 'Searching for target controllers in %s' %
controllerpath)
+if os.path.exists(controllerpath):
+add_controller_list(controllerpath)
+return controllerslist
+
+# Search for and return a controller from given target name and
+# set of module names.
+# Raise AttributeError if not found.
+# Raise ImportError if a provided module can not be imported
+def load_controller_from_name(self, target, modulenames):
+for name in modulenames:
+obj = self.load_controller_from_module(target, name)
+if obj:
+return obj
+raise AttributeError("Unable to load {0} from available modules:
{1}".format(target, str(modulenames)))
+
+# Search for and return a controller or None from given module name
+def load_controller_from_module(self, target, modulename):
+obj = None
+# import module, allowing it to raise import exception
+module = __import__(modulename, globals(), locals(), [target])
+# look for target class in the module, catching any exceptions as it
+# is valid that a module may not have the target class.
+try:
+obj = getattr(module, target)
+if obj:
+from oeqa.targetcontrol import BaseTarget
+if (not isinstance(obj, (type, types.ClassType))):
+bb.warn("Target {0} found, but not of type
Class".format(target))
+if( not issubclass(obj, BaseTarget)):
+bb.warn("Target {0
[OE-core] [PATCH v2] lib/oeqa: sshcontrol: Allow alternate port for SSHControl
Add an optional parameter to SSHControl so the user can specify and alternate port to the default (22). Signed-off-by: Sipke Vriend --- meta/lib/oeqa/utils/sshcontrol.py |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/lib/oeqa/utils/sshcontrol.py b/meta/lib/oeqa/utils/sshcontrol.py index 3e53ec3..8913250 100644 --- a/meta/lib/oeqa/utils/sshcontrol.py +++ b/meta/lib/oeqa/utils/sshcontrol.py @@ -13,7 +13,7 @@ import select class SSHControl(object): -def __init__(self, ip=None, timeout=300, logfile=None): +def __init__(self, ip=None, timeout=300, logfile=None, port=None): self.ip = ip self.timeout = timeout self._starttime = None @@ -26,6 +26,8 @@ class SSHControl(object): '-o', 'LogLevel=ERROR' ] self.ssh = ['ssh', '-l', 'root'] + self.ssh_options +if port: +self.ssh = self.ssh + ['-p', str(port)] def log(self, msg): if self.logfile: -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lib/oeqa: allow a layer to provide it's own TEST_TARGET class
Hi Stefan,
On 23/01/2014 6:27 PM, Stanacar, StefanX wrote:
> Hi Sipke,
>
> On Thu, 2014-01-23 at 14:48 +1000, Sipke Vriend wrote:
>> Hi Stefan,
>>
>> I have started using this patch in master to extend test targets to our
>> bsp layer, and it works well. Thanks.
>> Will the extension of a controllers.py file work for multiple bsp layers
>> in a single build/conf/bblayers.conf?
>> I did a quick test and think that the first controller.py found is the
>> only one "extended". If this is true then the current implementation
>> could get a false negative for a given TEST_TARGET, if more than one
>> layer implements controllers.py.
>
> Good catch!
> You are right, only the first one found is imported (and that probably
> has to do with how imports are made and the order of layers - lib/ is
> added to pythonpath for all layers AFAIK)
>
>>
>> I tried a minor modification which assumes each testtarget class is in
>> its own file with the name .py (lower case). This extended
>> across multiple layers, assuming no duplication of test target names. I
>> put them in the utils directory for the test, but they could go into a
>> controllers folder as that might make more sense.
>
> Looks good, and yes, a oeqa.controllers package might make more sense.
> Now, the only thing that bothers me is using testtarget's value as the
> filename (as it is now it was supposed to be the class name). Naming
> things is hard...
> Anyway, could you please send it as a patch?
The testtarget value is used for both file name (lower case) and class (camel
case).
This means there would be one class per file in the controllers directory.
Not aware of a way around it, but will look into it. Failing that I'll submit a
patch
with the controllers directory included.
>
> Cheers,
> Stefan
>
>>
>> diff --git a/meta/lib/oeqa/targetcontrol.py b/meta/lib/oeqa/targetcontrol.py
>> index 757f9d3..d7cab7e 100644
>> --- a/meta/lib/oeqa/targetcontrol.py
>> +++ b/meta/lib/oeqa/targetcontrol.py
>> @@ -28,10 +28,11 @@ def get_target_controller(d):
>> except AttributeError:
>> # nope, perhaps a layer defined one
>> try:
>> -module = __import__("oeqa.utils.controllers",
>> globals(), locals(), [testtarget])
>> +modulename = "oeqa.utils.{0}".format(testtarget.lower())
>> +module = __import__(modulename, globals(), locals(),
>> [testtarget])
>> controller = getattr(module, testtarget)
>> except ImportError as e:
>> -bb.fatal("Failed to import oeqa.utils.controllers:\n%s"
>> % traceback.format_exc())
>> +bb.fatal("Failed to import
>> {0}:\n{1}".format(modulename,traceback.format_exc()))
>> except AttributeError:
>> bb.fatal("\"%s\" is not a valid value for TEST_TARGET"
>> % testtarget)
>> return controller(d)
>>
>> Cheers
>> Sipke
>>
>> On 16/01/2014 10:48 PM, Stefan Stanacar wrote:
>>> Allows a layer to define new classes in/lib/oeqa/utils/controllers.py
>>> and completely control or extend deployment of a target. (core currently
>>> has QemuTarget and SimpleRemoteTarget).
>>> The value of TEST_TARGET must be the name of the new class.
>>>
>>> Signed-off-by: Stefan Stanacar
>>> ---
>>> meta/lib/oeqa/targetcontrol.py | 23 +++
>>> meta/lib/oeqa/utils/__init__.py | 3 +++
>>> 2 files changed, 22 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/meta/lib/oeqa/targetcontrol.py b/meta/lib/oeqa/targetcontrol.py
>>> index dee38ec..757f9d3 100644
>>> --- a/meta/lib/oeqa/targetcontrol.py
>>> +++ b/meta/lib/oeqa/targetcontrol.py
>>> @@ -8,18 +8,33 @@ import os
>>> import shutil
>>> import subprocess
>>> import bb
>>> -
>>> +import traceback
>>> from oeqa.utils.sshcontrol import SSHControl
>>> from oeqa.utils.qemurunner import QemuRunner
>>>
>>>
>>> def get_target_controller(d):
>>> -if d.getVar("TEST_TARGET", True) == "qemu":
>>> +testtarget = d.getVar("TEST_TARGET", True)
>>> +# old, simple names
>>> +if testtarget == "qemu":
>>> return QemuTarget(d)
>>> -elif d.getVar("TEST_TARGET", True) == "simpleremote":
>>> +elif testtarget ==
Re: [OE-core] [PATCH] lib/oeqa: allow a layer to provide it's own TEST_TARGET class
Hi Stefan,
I have started using this patch in master to extend test targets to our
bsp layer, and it works well. Thanks.
Will the extension of a controllers.py file work for multiple bsp layers
in a single build/conf/bblayers.conf?
I did a quick test and think that the first controller.py found is the
only one "extended". If this is true then the current implementation
could get a false negative for a given TEST_TARGET, if more than one
layer implements controllers.py.
I tried a minor modification which assumes each testtarget class is in
its own file with the name .py (lower case). This extended
across multiple layers, assuming no duplication of test target names. I
put them in the utils directory for the test, but they could go into a
controllers folder as that might make more sense.
diff --git a/meta/lib/oeqa/targetcontrol.py b/meta/lib/oeqa/targetcontrol.py
index 757f9d3..d7cab7e 100644
--- a/meta/lib/oeqa/targetcontrol.py
+++ b/meta/lib/oeqa/targetcontrol.py
@@ -28,10 +28,11 @@ def get_target_controller(d):
except AttributeError:
# nope, perhaps a layer defined one
try:
-module = __import__("oeqa.utils.controllers",
globals(), locals(), [testtarget])
+modulename = "oeqa.utils.{0}".format(testtarget.lower())
+module = __import__(modulename, globals(), locals(),
[testtarget])
controller = getattr(module, testtarget)
except ImportError as e:
-bb.fatal("Failed to import oeqa.utils.controllers:\n%s"
% traceback.format_exc())
+bb.fatal("Failed to import
{0}:\n{1}".format(modulename,traceback.format_exc()))
except AttributeError:
bb.fatal("\"%s\" is not a valid value for TEST_TARGET"
% testtarget)
return controller(d)
Cheers
Sipke
On 16/01/2014 10:48 PM, Stefan Stanacar wrote:
Allows a layer to define new classes in/lib/oeqa/utils/controllers.py
and completely control or extend deployment of a target. (core currently
has QemuTarget and SimpleRemoteTarget).
The value of TEST_TARGET must be the name of the new class.
Signed-off-by: Stefan Stanacar
---
meta/lib/oeqa/targetcontrol.py | 23 +++
meta/lib/oeqa/utils/__init__.py | 3 +++
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/meta/lib/oeqa/targetcontrol.py b/meta/lib/oeqa/targetcontrol.py
index dee38ec..757f9d3 100644
--- a/meta/lib/oeqa/targetcontrol.py
+++ b/meta/lib/oeqa/targetcontrol.py
@@ -8,18 +8,33 @@ import os
import shutil
import subprocess
import bb
-
+import traceback
from oeqa.utils.sshcontrol import SSHControl
from oeqa.utils.qemurunner import QemuRunner
def get_target_controller(d):
-if d.getVar("TEST_TARGET", True) == "qemu":
+testtarget = d.getVar("TEST_TARGET", True)
+# old, simple names
+if testtarget == "qemu":
return QemuTarget(d)
-elif d.getVar("TEST_TARGET", True) == "simpleremote":
+elif testtarget == "simpleremote":
return SimpleRemoteTarget(d)
else:
-bb.fatal("Please set a valid TEST_TARGET")
+# use the class name
+try:
+# is it a core class defined here?
+controller = getattr(__name__, testtarget)
+except AttributeError:
+# nope, perhaps a layer defined one
+try:
+module = __import__("oeqa.utils.controllers", globals(),
locals(), [testtarget])
+controller = getattr(module, testtarget)
+except ImportError as e:
+bb.fatal("Failed to import oeqa.utils.controllers:\n%s" %
traceback.format_exc())
+except AttributeError:
+bb.fatal("\"%s\" is not a valid value for TEST_TARGET" %
testtarget)
+return controller(d)
class BaseTarget(object):
diff --git a/meta/lib/oeqa/utils/__init__.py b/meta/lib/oeqa/utils/__init__.py
index e69de29..8eda927 100644
--- a/meta/lib/oeqa/utils/__init__.py
+++ b/meta/lib/oeqa/utils/__init__.py
@@ -0,0 +1,3 @@
+# Enable other layers to have modules in the same named directory
+from pkgutil import extend_path
+__path__ = extend_path(__path__, __name__)
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] lib/oeqa: sshcontrol: Allow alternate port for SSHControl
Add an optional parameter to SSHControl so the user can specify and alternate port to the default (22). Signed-off-by: Sipke Vriend --- meta/lib/oeqa/utils/sshcontrol.py |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/lib/oeqa/utils/sshcontrol.py b/meta/lib/oeqa/utils/sshcontrol.py index a0dcf02..7bdf2e7 100644 --- a/meta/lib/oeqa/utils/sshcontrol.py +++ b/meta/lib/oeqa/utils/sshcontrol.py @@ -13,7 +13,7 @@ import select class SSHControl(object): -def __init__(self, ip=None, timeout=300, logfile=None): +def __init__(self, ip=None, timeout=300, logfile=None, port=None): self.ip = ip self.timeout = timeout self._starttime = None @@ -26,6 +26,8 @@ class SSHControl(object): '-o', 'LogLevel=ERROR' ] self.ssh = ['ssh', '-l', 'root'] + self.ssh_options +if port is not None: +self.ssh = self.ssh + ['-p', str(port)] def log(self, msg): if self.logfile: -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC OE-core/meta/lib] BSP Specific Qemurunner
Hi Stefan, On Thursday, 9 January 2014 10:19 PM, Stanacar, StefanX wrote: >On Thu, 2014-01-09 at 00:01 +0000, Sipke Vriend wrote: >> On Wednesday, 8 January 2014 11:53 PM Paul Eggleton wrote: >> > >> >On Wednesday 08 January 2014 13:12:41 Richard Purdie wrote: >> >> On Tue, 2014-01-07 at 22:59 +, Sipke Vriend wrote: >> >> > Hi Richard, >> >> > >> >> > >-Original Message- >> >> > >On Wednesday, 8 January 2014 12:00 AM, Richard Purdie wrote: >> >> > > >> >> > >On Tue, 2014-01-07 at 03:09 +, Sipke Vriend wrote: >> >> > >> Hi, >> >> > >> >> >> > >> This RFC is a proposal to allow BSP layers to setup qemu with their >> >> > >> specific requirements for the testimage oe-core functionality. >> >> > >> The suggested changes will be exercised by the >> >> > >> bitbake -c testimage >> >> > >> command. >> >> > >> Similarly to the oeqa test cases this proposal extends the >> >> > >> meta/lib/oeqa >> >> > >> python modules to allow inclusion of python utility scripts in the >> >> > >> BSP >> >> > >> layers. >> >> > >> Any BSP layer wishing to supply their own qemu setup would need to >> >> > >> create >> >> > >> an appropriate meta-bsplayer/lib/oeqa/utils/starter.py >> >> > >> The effect is that the lib/oeqa/utils/qemurunner will either allow >> >> > >> the >> >> > >> bsp layer provided starter to spawn qemu or if not provided, >> >> > >> spawn qemu via runqemu as currently. >> >> > >> An example bsp layer is available here: >> >> > >> https://github.com/sipke/meta-xilinx/tree/sipke/qemurunner >> >> > >> with all required additions in the meta-xilinx/lib directory. >> >> > >> >> >> > >> This RFC is triggered by and indirectly related to >> >> > >> Bugzilla report "runqemu shouldn't hard-code machine knowledge" >> >> > >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4827 >> >> > > >> >> > >Why would we do this rather than improve runqemu to be extendable from >> >> > >BSP layers? >> >> > >> >> > Proposing as an additional way to launch qemu for oeqa testimage >> >> > functionality, Improving runqemu can and probably should still happen. >> >> > >> >> > To consider: >> >> > * it keeps testimage functionality (for bsp layers specific things) in >> >> > the lib directly (similar to test cases) and as python. >> >> > * testing (via testimage) may have a different requirement to that of >> >> > running runqemu on the command line, so an alternate way to launch qemu >> >> > could be useful. >> >> > * should this approach of extending the oeqa testimage functionality >> >> > into bsp layers be accepted, this could allow also for bsp specific >> >> > hardware setup for testimage functionality in bsp layers. >> >> > >> >> > Primary aim is a solution which allows the bsp layer to control the >> >> > setup of qemu (and eventually hardware) for testimage functionality. >> >> > This >> >> > is a proposal towards that goal. >> >> >> >> I thought Stefan was already also working on something towards this >> >> goal. I'd like to ensure we don't end up with two things doing the same >> >> thing. >> >> >> >> Stefan? >> >> >> >> Agreed. One solution is desired. Happy to coordinate with and assist Stefan, >> either implementing part of a solution (proposed one or another) and/or >> testing whatever Stefan comes up with against our bsp layer. > >I'm sorry for replying so late, this has been a slow week. I'm a bit >confused because last time I checked I wasn't working on something >similar :) (layer-controlled qemu/bsp setup), but I'm happy to help. > No worries, you're not late and sorry for having inadvertently dragged you in it seems :) >I've looked at the patches themselves, and they are okay, but I'm not >sure a layer-specific qemu setup for testimage is what we should do in >the long term. >Now, I can see the pro
Re: [OE-core] [RFC OE-core/meta/lib] BSP Specific Qemurunner
On Wednesday, 8 January 2014 11:53 PM Paul Eggleton wrote: > >On Wednesday 08 January 2014 13:12:41 Richard Purdie wrote: >> On Tue, 2014-01-07 at 22:59 +, Sipke Vriend wrote: >> > Hi Richard, >> > >> > >-Original Message- >> > >On Wednesday, 8 January 2014 12:00 AM, Richard Purdie wrote: >> > > >> > >On Tue, 2014-01-07 at 03:09 +, Sipke Vriend wrote: >> > >> Hi, >> > >> >> > >> This RFC is a proposal to allow BSP layers to setup qemu with their >> > >> specific requirements for the testimage oe-core functionality. >> > >> The suggested changes will be exercised by the >> > >> bitbake -c testimage >> > >> command. >> > >> Similarly to the oeqa test cases this proposal extends the >> > >> meta/lib/oeqa >> > >> python modules to allow inclusion of python utility scripts in the BSP >> > >> layers. >> > >> Any BSP layer wishing to supply their own qemu setup would need to >> > >> create >> > >> an appropriate meta-bsplayer/lib/oeqa/utils/starter.py >> > >> The effect is that the lib/oeqa/utils/qemurunner will either allow the >> > >> bsp layer provided starter to spawn qemu or if not provided, >> > >> spawn qemu via runqemu as currently. >> > >> An example bsp layer is available here: >> > >> https://github.com/sipke/meta-xilinx/tree/sipke/qemurunner >> > >> with all required additions in the meta-xilinx/lib directory. >> > >> >> > >> This RFC is triggered by and indirectly related to >> > >> Bugzilla report "runqemu shouldn't hard-code machine knowledge" >> > >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4827 >> > > >> > >Why would we do this rather than improve runqemu to be extendable from >> > >BSP layers? >> > >> > Proposing as an additional way to launch qemu for oeqa testimage >> > functionality, Improving runqemu can and probably should still happen. >> > >> > To consider: >> > * it keeps testimage functionality (for bsp layers specific things) in >> > the lib directly (similar to test cases) and as python. >> > * testing (via testimage) may have a different requirement to that of >> > running runqemu on the command line, so an alternate way to launch qemu >> > could be useful. >> > * should this approach of extending the oeqa testimage functionality >> > into bsp layers be accepted, this could allow also for bsp specific >> > hardware setup for testimage functionality in bsp layers. >> > >> > Primary aim is a solution which allows the bsp layer to control the >> > setup of qemu (and eventually hardware) for testimage functionality. This >> > is a proposal towards that goal. >> >> I thought Stefan was already also working on something towards this >> goal. I'd like to ensure we don't end up with two things doing the same >> thing. >> >> Stefan? >> Agreed. One solution is desired. Happy to coordinate with and assist Stefan, either implementing part of a solution (proposed one or another) and/or testing whatever Stefan comes up with against our bsp layer. >> To be clear, I would like to see runqemu enhanced so BSP layers can >> extend it, I think that would be useful for everyone. Once we've done >> that, I'd like to revisit the qemu abstraction in testimage and figure >> out what changes it needs. Some may be required, some may not if we fix >> runqemu first, I'm unclear from these commits what those would be >> though. > >FWIW I agree, we need to have the BSP-specific functionality in runqemu and >then what we do with QemuRunner will follow on from that. I think the other Hopefully the BSP-specific parts (config files or scripts) will be in the bsp layer. Is the ETA of this still 1.6-M4? >patches in the series to do with setting user/port should be OK to consider >independently of this, though. > >Cheers, >Paul > >-- > >Paul Eggleton >Intel Open Source Technology Centre > > ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC OE-core/meta/lib] BSP Specific Qemurunner
Hi Richard, > >-Original Message- >On Wednesday, 8 January 2014 12:00 AM, Richard Purdie wrote: > >On Tue, 2014-01-07 at 03:09 +0000, Sipke Vriend wrote: >> Hi, >> >> This RFC is a proposal to allow BSP layers to setup qemu with their specific >> requirements for the testimage oe-core functionality. >> The suggested changes will be exercised by the >> bitbake -c testimage >> command. >> Similarly to the oeqa test cases this proposal extends the meta/lib/oeqa >> python modules to allow inclusion of python utility scripts in the BSP >> layers. >> Any BSP layer wishing to supply their own qemu setup would need to create >> an appropriate meta-bsplayer/lib/oeqa/utils/starter.py >> The effect is that the lib/oeqa/utils/qemurunner will either allow the >> bsp layer provided starter to spawn qemu or if not provided, >> spawn qemu via runqemu as currently. >> An example bsp layer is available here: >> https://github.com/sipke/meta-xilinx/tree/sipke/qemurunner >> with all required additions in the meta-xilinx/lib directory. >> >> This RFC is triggered by and indirectly related to >> Bugzilla report "runqemu shouldn't hard-code machine knowledge" >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4827 > >Why would we do this rather than improve runqemu to be extendable from >BSP layers? > Proposing as an additional way to launch qemu for oeqa testimage functionality, Improving runqemu can and probably should still happen. To consider: * it keeps testimage functionality (for bsp layers specific things) in the lib directly (similar to test cases) and as python. * testing (via testimage) may have a different requirement to that of running runqemu on the command line, so an alternate way to launch qemu could be useful. * should this approach of extending the oeqa testimage functionality into bsp layers be accepted, this could allow also for bsp specific hardware setup for testimage functionality in bsp layers. Primary aim is a solution which allows the bsp layer to control the setup of qemu (and eventually hardware) for testimage functionality. This is a proposal towards that goal. Thanks Sipke >Cheers, > >Richard > > > > > ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC OE-core/meta/lib] BSP Specific Qemurunner
Hi, This RFC is a proposal to allow BSP layers to setup qemu with their specific requirements for the testimage oe-core functionality. The suggested changes will be exercised by the bitbake -c testimage command. Similarly to the oeqa test cases this proposal extends the meta/lib/oeqa python modules to allow inclusion of python utility scripts in the BSP layers. Any BSP layer wishing to supply their own qemu setup would need to create an appropriate meta-bsplayer/lib/oeqa/utils/starter.py The effect is that the lib/oeqa/utils/qemurunner will either allow the bsp layer provided starter to spawn qemu or if not provided, spawn qemu via runqemu as currently. An example bsp layer is available here: https://github.com/sipke/meta-xilinx/tree/sipke/qemurunner with all required additions in the meta-xilinx/lib directory. This RFC is triggered by and indirectly related to Bugzilla report "runqemu shouldn't hard-code machine knowledge" https://bugzilla.yoctoproject.org/show_bug.cgi?id=4827 The following changes since commit cd94dd3d9bba32c3fd55959586128b236d1d4e34: security_flags: more relocation issues (2013-12-18 17:23:55 +) are available in the git repository at: https://github.com/sipke/oe-core/tree/sipke/qemurunner Sipke Vriend (6): meta:lib:oeqa:utils Allow other layers to have utils in same named directory meta:lib:oeqa:utils:sshcontrol Allow a non root user for ssh control meta:lib:oeqa:utils:targetcontrol Allow for a TEST_USER variable meta:lib:oeqa:utils:sshcontrol Allow different port for ssh control meta:lib:oeqa:utils:qemurunner Move runqemu code into method meta:lib:oeqa:utils:qemurunner Add ability to launch qemu from python script meta/lib/oeqa/targetcontrol.py| 11 +++- meta/lib/oeqa/utils/__init__.py |3 + meta/lib/oeqa/utils/qemurunner.py | 121 + meta/lib/oeqa/utils/sshcontrol.py |8 ++- 4 files changed, 115 insertions(+), 28 deletions(-) Cheers Sipke ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-xilinx] linux-dtb.inc
Hi Philip, +Cc openembedded-core. I believe openembedded-core changed from using DTC directly, to using in kernel make to generate DTBs specified in KERNEL_DEVICETREE. http://git.openembedded.org/openembedded-core/commit/?id=72980d5bb465f0640ed451d1ebb9c5d2a210ad0c This regressed meta-xilinx and for now the fix you discuss corrects that, but you are correct in thinking that it may not be an ideal solution. http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/commit/?id=ad5139ef91c7a1f4a32261238426f8661eb57871 This fix is providing the ability for the meta-xilinx user to build both in kernel tree DTS (as per the new oe-core way) and or the existing meta-xilinx recipe space DTSs. I suspect most BSP providers can live with in kernel tree DTSs, but it is useful for meta-xilinx to have the ability to build recipe space DTSs as Xilinx architectures, due to their nature, are configurable (especially for kc705-trd-microblaze and any future microblaze machines added to meta-xilinx). As you correctly noted, the same include file name is used as this is effectively the previous dtb generation script from openembedded-core, minus some duplication. It was intentional to keep the same file name so the 'connection' is seen. Any alternate methods know for building in recipe space DTSs within openembedded-core will be much appreciated. Regards Sipke >-Original Message- >On Thursday, 22 August 2013 8:58 AM Behalf Of Philip Balister wrote: > >OE-core and meta-xilinx both have linux-dtb.inc files, but they are >different. > >https://github.com/Xilinx/meta-xilinx/blob/master/recipes-kernel/linux/ >linux-dtb.inc > >and > >http://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/ >linux/linux-dtb.inc > >Understanding how these work is not something I am good at, but I am >concerned when I see a BSP doing something similar but different to the >core layers. What are the chances we can understand the differences and >see about consolidating the differences in oe-core? > >Philip >___ >meta-xilinx mailing list >meta-xil...@yoctoproject.org >https://lists.yoctoproject.org/listinfo/meta-xilinx > > ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] meta-xilinx moved to meta-xilinx-community
Hi Khem, Meta-xilinx is a layer aimed at providing Xilinx support for Microblaze and Zynq as well as a limited number of BSPs to exercise those architectures. This layer is maintained by Xilinx. Meta-xilinx-community is a layer (previously named meta-xilinx) which has support for the same architectures, but also a number of legacy architectures (such as powerpc) and boards (ml507) which will not be in the meta-xilinx layer. This layer is maintained primarily by Elvis Dowson. Currently there is overlap in architectures and supported boards but over time the meta-xilinx-community has the option of layering on top of meta-xilinx if there is no functional difference, which will reduce this overlap. To date each of the layers has leveraged off the other, and the maintainers are in contact with each other. We hope over time meta-xilinx will be the common base layer for meta-xilinx-community and any other layer supporting for example custom boards running Xilinx hardware. As a maintainer of meta-xilinx I will suggest starting with it, but the choice of layer will depend on your need and it will be worth comparing whether there are advanced features in the meta-xilinx-community layer that you require. Both layers use the same email list: meta-xil...@yoctoproject.org, so that is always a good starting point to ask. Regards Sipke -Original Message- From: Khem Raj [mailto:raj.k...@gmail.com] Sent: Thursday, 30 May 2013 12:22 PM To: Sipke Vriend Cc: Yocto Discussion Mailing List; OpenEmbedded Developer Mailing List; OpenEmbedded Core Mailing List; meta-xilinx Mailing List; Nathan Rossi; David Holsgrove; Mike Matera; John Williams Subject: Re: [yocto] meta-xilinx moved to meta-xilinx-community Sipke On Wed, May 29, 2013 at 5:14 PM, Sipke Vriend wrote: > Hi, > > yoctoproject.org is now hosting meta-xilinx from Xilinx. > http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/ > This repository was previously at www.github.com/Xilinx/meta-xilinx.git, and > will remain there as a mirror. > > This layer contains Xilinx hardware support metadata for Zynq and Microblaze > architecture, currently with bsp layers targeting the evaluation boards > zc702, zedboard and kc705. The layer is under development and further > information is available in README files within the layer. > How does it relate to meta-xilinx-community layer ? eg. http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx-community/tree/conf/machine contains zc702 zc706 and zedboard machines among others. and the new meta-xilinx layer contains bsps for zc702 and zedboard as well. I do not know much about xilinx family of chips. But say if I were to use zeboard which layer would I choose ? and how are development of these two layers related if at all > Regards > Sipke Vriend > > -Original Message- > From: Elvis Dowson [mailto:elvis.dow...@gmail.com] > Sent: Friday, 24 May 2013 1:53 PM > To: Yocto Discussion Mailing List; OpenEmbedded Developer Mailing List; > OpenEmbedded Core Mailing List; meta-xilinx Mailing List > Cc: Sipke Vriend; Nathan Rossi > Subject: meta-xilinx moved to meta-xilinx-community > > Hi, > The existing meta-xilinx repo has moved to meta-xilinx-community > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx-community/ > > This layer will contain community support for the Xilinx platforms, including > legacy boards (ML507) and other soft-processor architectures. > > This paves the way for an officially supported meta-xilinx layer, the details > of which will be officially announced by Xilinx. > > Best regards, > > Elvis Dowson > > > ___ > yocto mailing list > yo...@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
