search

au-ts / sddf

A collection of interfaces, libraries and tools for writing device drivers for seL4 that allow accessing devices securely and with low overhead.
Other
17 stars 14 forks source link

Abstract away board and toolchain details #216

Open wom-bat opened 2 weeks ago

wom-bat commented 2 weeks ago

Put the common bits in a makefile snippet.

wom-bat commented 2 weeks ago

Is this a good idea?

Ivan-Velickovic commented 2 weeks ago

I don't think it's worse like this but I'm not sure if it's an improvement either.

Having the toolchain extracted makes more sense than the boards I think.

There is a bit of duplication with the boards in each example but it's really simple, just for the device classes.

Kswin01 commented 2 weeks ago

I think that it is a good improvement imo. Especially when we change names of devices to their proper names (like meson eth changing to dwmac4.20), or have devices with peripherals of completely different names (like the star64 with snps-uart, dwmac5.1 eth), just having a central config for that specific board will be easier for users.

But that's more from the perspective of LionsOS, where the tooling will eventually deal with all of this. After discussing with Ivan, maybe the board abstractions don't necessarily belong in the sDDF.

wom-bat commented 2 weeks ago

But that's more from the perspective of LionsOS, where the tooling will eventually deal with all of this. After discussing with Ivan, maybe the board abstractions don't necessarily belong in the sDDF.

I was mostly thinking about this for LionsOS, but would like to have the same mechanism everywhere, and this seemed the right place to start. I'm also thinking, that maybe it should be in a separate configuration/build system tree. Except I hate multiplying the number of submodules we need.

Ivan-Velickovic commented 2 weeks ago

I guess I don't really know what problem we're trying to solve? Why is the current approach inadequate?

Ivan-Velickovic commented 2 weeks ago

I guess I don't really know what problem we're trying to solve? Why is the current approach inadequate?

What I mean by this is that the simpler approach seems fine for sDDF example systems and the abstraction is probably better left solely to LionsOS.

wom-bat commented 2 weeks ago

I guess I don't really know what problem we're trying to solve? Why is the current approach inadequate?

What I mean by this is that the simpler approach seems fine for sDDF example systems and the abstraction is probably better left solely to LionsOS.

I'm not sure the current approach is scalable to many many boards. Merely including a board description file, rather than repeating a huge if-then-else chain means: