[oe] image.bbclass IMAGE_DEVICE_TABLES issues

[Frans Meulenbroeks]

2010/6/19 Khem Raj <raj.khem at gmail.com>:
> On Wed, Jun 16, 2010 at 5:27 AM, Frans Meulenbroeks
> <fransmeulenbroeks at gmail.com> wrote:
>> Hi,
>>
>> I am having an issue or two with image.bbclass and especially the
>> devtable section.
>>
>> It concers the following part:
>>
>> # Get a list of files containing tables of devices to be created.
>> # * IMAGE_DEVICE_TABLE is the old name to an absolute path to a device
>> table file
>> # * IMAGE_DEVICE_TABLES is a new name for a file, or list of files, searched
>> #   for in the BBPATH
>> # If neither are specified then the default name of
>> files/device_table-minimal.txt
>> # is searched for in the BBPATH (same as the old version.)
>> #
>> def get_devtable_list(d):
>>    import bb
>>    devtable = bb.data.getVar('IMAGE_DEVICE_TABLE', d, 1)
>>    if devtable != None:
>>        return devtable
>>    devtables = bb.data.getVar('IMAGE_DEVICE_TABLES', d, 1)
>>    if devtables == None:
>>        devtables = 'files/device_table-minimal.txt'
>>    return " ".join([ bb.which(bb.data.getVar('BBPATH', d, 1), devtable)
>>                      for devtable in devtables.split() ])
>>
>> The issues I have are the following:
>> 1. if the file is not there an empty list is returned and used without
>> any error being given.
>> In case of the default name that is probably ok, but if there is an
>> explicit IMAGE_DEVICE_TABLE or IMAGE_DEVICE_TABLES given and the file
>> is not there I would qualify the situation as an error.
>> Guess it would be very convenient to have an error message in that case.
>
> add a bbnote or somesuch after line 126 in image.bbclass after check
> the existence of $devtable

Thanks for the hint, but I am not sure my pythonese is good enough to
implement this.
Also I'd say that if the default table is chosen in the code and that
table is not present, it does not constitute an error.

>
>> 2. According to the comment for IMAGE_DEVICE_TABLES (and for the
>> default name) the file is searched for in BBPATH. For me BBPATH points
>> to an overlay dir with below it recipes/myimage/myimage.bb
>> The code does join the names but (at least with my limited python
>> knowledge) does not look into subdirs. This is experimentally
>> verified.
>
> it looks in BBPATH/<the path given by you>/<table given by you>.txt

I know. And if I do not give a subdir they will (at least in my setup)
live in the same dir as the recipes/classes/conf etc folders.
It does not seem to be a proper place (but I am not too keen on
hardcoding a path in a recipe).
>
>> I feel it is more appropriate to have the device table near the bb
>> file (e.g. in recipes/myimage/mydevicetable.txt)
>
> devtable is a machine property not image property.

Then I'd say there should be a machine specific dir for this stuff.
Actually I feel that device table could be image specific. E.g.
different images for the same hardware could contain a different
device table. E.g. I do not want to make the console available on the
production version, but I do want it on the development version. Or if
I want to hide devices that are not to be used in a specific image.
>
>> currently I have to either specify a path in IMAGE_DEVICE_TABLES
>> (which I don't like because it makes the recipe dependent of the
>> actual place in the tree, so it is not robust to moving it), or have
>> the device table on the level of recipes (which I do not like either
>> as it is not near the recipe).
>
> its relative to BBPATH I don't see any relation between bb file and
> device table

The image refers to the table. Typically all files referred to in a
recipe reside in the recipe dir (e.g. an .inc file) or in subdirs
(e.g. patches).
Having the device table in the same dir seems only consistent to me
(and also makes it easier to move the recipe around).
>
>> My suggestion would be to look in the dir of the recipe or in ${WORKDIR}
>>
>> What do people think about this?
>> I'm not really a python wiz, so if someone can contribute a patch that
>> would be greatly appreciated.
>>
>> Frans
>>

Have fun! Frans