Ron,
ron minnich wrote:
I think this could prove to be a very important new direction for coreboot,
I agree.
and I still think it belongs in the tree.
No way.
This is a library of device drivers. It has no place whatsoever as a subdirectory lost somewhere in the already too big coreboot repository.
libsparkhw needs to live in its own repository, and be pulled into coreboot as well as other consumers (e.g. FILO as Nico mentioned) as a submodule.
But putting the submodule under 3rdparty isn't a great fit, because the library is very much from the 1stparty, namely from the coreboot community. So it should be somewhere else, I suggest in lib/[lib]sparkhw.
License-wise, in order to be maximally compatible and reusable together with libpayload I would welcome and support a simplified BSD license.
I haven't ever used Ada, but used lots of Pascal long long ago. Fun!
//Peter
If people feel strongly enough about this then we can do an external repo for now.
Nico, do you want to set up a github repo and we can work out procedures people use to try this out? As you know I'm more interested in Muen as a replacement for the ramstage but this is a good first step.
ron
On 29.08.2015 14:09, Peter Stuge wrote:
ron minnich wrote:
and I still think it belongs in the tree.
No way.
This is a library of device drivers. It has no place whatsoever as a subdirectory lost somewhere in the already too big coreboot repository.
libsparkhw needs to live in its own repository, and be pulled into coreboot as well as other consumers (e.g. FILO as Nico mentioned) as a submodule.
But putting the submodule under 3rdparty isn't a great fit, because the library is very much from the 1stparty, namely from the coreboot community. So it should be somewhere else, I suggest in lib/[lib]sparkhw.
That's exactly what I had in mind. Thanks for your support.
In the end, I don't care as much about a dedicated repo than about the path (i.e. not under 3rdparty).
Nico
-
Nico Huber -
Peter Stuge -
ron minnich