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
18 stars 14 forks source link

Refactor Makefiles across the repository #103

Closed wom-bat closed 4 months ago

wom-bat commented 5 months ago

The aim is to have local knowledge of how to build a component confined to that component's Makefiles, rather than having to work it out in a per-project Makefile.

Each component and driver has a componentname.mk snippet designed to be included into a per-project makefile invoked in the build directory.

Thus, the overall Makefile for a project will create the build directory (if it doesn't already exist), add a Makefile into that directory, and invoke make in the build directory. The examples show what I mean.

The Makefile in the build directory just does include componentname.mk for each component it uses, and has a single line invoking the microkit tool that depends on all the elf files that it needs.

Still to do is working out how to have more than one variant (e.g., for the i2c host).

Ivan-Velickovic commented 5 months ago

For consistency we should use MICROKIT_SDK everywhere instead of MK_SDK. We never refer to Microkit as mk or MK so it will be confusing for people.

JE-Archer commented 4 months ago

Nitpicks:

Questions:

Ivan-Velickovic commented 4 months ago

if all the meat of the building is in the fragments, could it be better to have a global Makefile (either in root or in examples/) instead of one per example system (one would still be able to build a specific system by specifying the target)?

The point of the examples is to be isolated so someone can copy and paste and use it as a start for experimentation/new system.

wom-bat commented 4 months ago

Nitpicks:

* between the driver make fragments, the timer drivers define `TIMER_DIR` and `TIMER_OBJ` while the ethernet and I2C drivers don't define the *_OBJ variable;

I wanted to give a variety of styles to show different ways the makefile fragment could work. None of these is better or worse than another.

* the timer and I2C drivers define `TIMER_DIR` and `I2C_DRIVER_DIR`, while the ethernet drivers define `ETHERNET_DRIVER` without the _DIR;

Should all probably be without the DIR. One thing I'm concerned about, and should probably fix, is the possibility that more than one different I2C or timer driver may be in the system at the same time: I should probably give the variables more constrained names, so they don't collide in that case, as were running in a global namespace.

  • the timer driver is referred to in the variables as just timer, while the ethernet and I2C are referred to as *_driver;

  • the ELF files are called timer.elf, eth.elf, uart_driver.elf and i2c_driver.elf—I suggest timer_driver.elf, ethernet_driver.elf`;

Usually I kept the names they already had. The one exception was the network vitualisers that I added 'network_' a a prefix for so they could coexist with the serial virtualisers.

* the .mk files themselves are called `timer.mk`, `uart.mk`, `ethdriver.mk` and `i2c_driver.mk`—I suggest `timer_driver.mk`, `uart_driver.mk`, `ethernet_driver.mk` and `i2c_driver.mk`;

OK. Although the directory they're in makes it clear they're drivers.

* the meson ethernet driver has a Makefile as well as a .mk;

The Makefile pre-existed; I didn't want to delete it in the patch until I know what's using it.

* some driver make fragments have notes about what is required in the system description while others don't;

That needs fixing.

  • the timer drivers get the directory via $(dir $(lastword $(MAKEFILE_LIST))), while the others just hardcode it; Should probably use this mechanism everywhere. It's a GnuMAKE only thing though.

  • driver as abbreviated sometimes as drv, other times as driv. Meant to be drv everywhere, I'll try to search+replace Questions:

  • given we are moving to make fragments to be included by third parties, might it be better to add a prefix to identifiers?

Yes!

* if all the meat of the building is in the fragments, could it be better to have a global Makefile (either in root or in examples/) instead of one per example system (one would still be able to build a specific system by specifying the target)?

No --- the examples are meant to be standalone, and include only the fragments needed.