Re: [coreboot] From wildcat linking to exploring new languages

[Peter Stuge]

      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

From wildcat linking to exploring new languages

[ron minnich]

      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

From wildcat linking to exploring new languages

[Nico Huber]

      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