search

ARM-software / ebbr

Embedded Base Boot Requirements Specification
Creative Commons Attribution Share Alike 4.0 International
113 stars 37 forks source link

DT: Mandate forward and backward compatibility #38

Closed agraf closed 4 years ago

agraf commented 6 years ago

We currently do not mandate that a Devicetree stays compatible over the lifetime of the OS or that it is compatible to an upstream OS at all.

Fix that by restricting DT usage to only

device trees.

To indicate that, also explain the /ebbr node that can help people validate whether a DT should and does fulfill the EBBR contract.

Signed-off-by: Alexander Graf agraf@suse.de

glikely commented 4 years ago

I'm closing this one. I don't think we've got any way to enforce or test for forward/backward compatibility at this point in time. Happy to reopen at a later date when we've got a way to test/validate DT stability.

robherring commented 4 years ago

Isn't EBBR about defining the Right Thing To Do? There are lots of things we can't/don't test in EBBR. How do we enforce the dtb is part of the firmware for example?

To put it another way, where else are we documenting forward/backward compatibility? It's not fair to have requirements on things which aren't documented anywhere. We should at least document it, but any DT properties as this defined should be a separate discussion.

There is a way to test this. Make kernelci test kernel n with dtb from kernel n-1 and n+1.

trini commented 4 years ago

I thought kernelci already tested with old dtb files. And of course that only works for the cases where the hardware is in kernelci, which is how all of the cases where intentional and unintentional dtb breakage have happened. We need something more complete than what we have today.

robherring commented 4 years ago

@trini It could be. I've asked for that several times, but don't know if it got implemented. It's also checked by review, which helps, but obviously isn't perfect.

trini commented 4 years ago

@robherring Yes, and review also doesn't help when it acknowledges breakage as being OK.

To put it another way, perhaps we can't mandate forward/backwards compatibility 100% and need to define the subset of stuff that is stable and... maybe that belongs to a different group than EBBR where I imagine those issues are being hashed out still.