
Dear Brian,
in message 200405030705.57724.waite@skycomputers.com you wrote:
First, let me say I don't find the configurator that we are talking about all the helpful to my work, but I think I might have a solution that will reduce the maintainability. So what I was thinking about was using the maintainers
Ummm... Do you really mean what I'm reading here?
If it's not helpful, and reduces maintainability, then what is it good for at all?
file along with a configurator script in the tools directory. The configurator would be all the smarts. It would read the MAINTAINERS file, which has the bits in a well-defined structure, and generate the views with some type of filtering. So you could say "Show me all boards supporting CPU xyz" or "Show me all boards supported by CPU xyz". The obvioous final step of the configurator is "make <configuration>"
What should this be good for?
Normally, the user has a board on his desk, which is labeled as "foo", and all he needs to know is that the board name "foo" will be supported by either "make foo_config; make all" or simply by "MAKEALL foo".
If you are looking for similar boards while porting to some custom hardware, just scanning the CPU types does not help at all. You will need a lot of other parameters like memory map, RAM and flash chip types, bus width, flash sector layout, where to put the environment, which commands shall be supported, etc. etc.
PROS:
- The only new files are specificaly for the configurator and only need be
modified to fix the configurator.
- Only the people interested in the system need to know about it.
- Automatically updated with each supported board.
Assuming somebody adds the relevant entries to the MAINTAINERS file. This is nothing you can rely on.
- Minimal added work for Wolfgang.
- It can be extracted from the tree and maintained on the side until Wolfgang
has the time to review and appove it.
- No one other then the interested parties has to do anything other than add
their board to the MAINTAINERS list to work in u-boot.
- It does not preclude the make <configuration> well known system.
- Many others I am sure :)
CONS:
- More files in the u-boot tree.
Not a real problem.
- The configurator itself becomes somewhat complex.
- Many others I am sure :)
One other: I see zero advantage.
Jon, Wolfgang what are your thoughts on a system like this?
Either I don't understand at all what you have in mind, or we have very, very different goals -- "reducing maintainability" is most definitely not on my wish list ;-)
Best regards,
Wolfgang Denk