> Using the name of the device file makes the definitions inside the XML file
> redundant. I'm actually not sure whether those are actually used somewhere.
Yes. It can be removed.
There was a half-hearted attempt to "verify" the device data, but it's rather
> One possibility would be to store the naming schema inside the device file.
> What do you think?
Not too fond of using XML beyond the device files.
Counter offer: Lets put a `platform.py` with a bunch of (stateless) callbacks
invoked by the library builder in the folder with the device files.
It would contain:
1. a function that splits the device identifier string into a target dictionary
and returns that.
The library builder itererates over all `platform.py` in the folders and
executes that first callback.
All further hooks are used from that file then.
2. a function mapping the target dictionary onto a device file.
The device file naming scheme is then local to only the folder and can
therefore transparently hide differences in the target dictionary.
3. a function adding platform dependent Jinja2 filters.
I believe that these three function will allow the build system to be
completely ignorant of the content of the target dictionary.
Only the driver templates will have to understand what the target dictionary
Regarding `driver.xml`: It's functions disguised as data. That's horrible. The
library builder has the right idea.
Let's use a `driver.py` that's called with a copy of the entire (!)
substitution dictionary and it can modify it as it wishes.
It can filter it, add and remove data, or create and entirely new substitution
Adding the templates is then "just" another action that depends on the
Also we would provide functions that add parameters (using the mechanism in
The reason why I want to pass the entire device file data into the driver is
that restricting cross-peripheral data like DMA to only inside the driver nodes
leads to data duplicatation one way or the other. Let's keep it generic.
> Btw. according to the device files xpcc supports 573 different targets at the
> moment :)
Not all combinations are valid though, some simply don't exist.
The ORing is a one way mapping.
>> Could we have a base schema and then "specialize" that for the architectures?
> That is possible, but a bit difficult. Inheritance is supported on tag level,
> but not on schema level. With that most of the schema has to be rewritten for
Would that mean that each platform has it's own schema (in the device file
folder?), with duplicate common code?
If we generated these platform schemas from a common schema which is inserted
with platform specific schema, that would force the schemas not to diverge.
This generation step is not part of lbuild (doesn't even have to use Jinja2),
and the schemas are checked into the repo.
> PS: (...)/platform/devices/avr/at90646_647_1286_1287-usb.xml looks broken
> with flash, ram and eeprom being defined multiple times with different values
> without any selector.
That looks like it would have been caught with a schema ;-P
xpcc-dev mailing list