[coreboot] GSoC-2014 Project for Coreboot

[Naman Govil]

Hi All,
Sorry if I am a bit OT to this thread, due to my limited knowledge about
coreboot CBFS at this stage, but I would like add few points.

Firstly, as Alex mentioned
If, on the other hand, you have a well designed, unified block dev API, you
can select your block device based on some some heuristic to decide which
media to boot from.

Why is this better? You don't need two implementations of alternate_cbfs,
which are extra code size, extra code, and generally look ugly and
complicate
the code.

This was the motivation behind the goal that we had initially set for this
particular project, a simple coreboot-specific blockdev API that will allow
the block device to interface with the host.

Then as Aaron pointed out the issues with CBFS API: like the inability to
free resources and internal cache, would'nt it be a good idea to actually
implement a new API that could resolve these issues?

Also, I would like to ask Ron, he said:
I think we need to step back from the small problems just a bit (i.e.
generic block device interface) and think about generic device interfaces.
It's doable: see Unix. We don't have as broad a range of devices as Unix
had to contend with (no paper tape). And we've got tons of different
examples to draw from.

I agree with the long term goal, but from the point of view of a project in
GSoC, is'nt it better for me to implement the block device API first, and
then in the course of time think about the generic device interface?

Regards,
Naman


On Fri, Mar 14, 2014 at 8:48 PM, ron minnich <rminnich at gmail.com> wrote:

>
>
>
> On Fri, Mar 14, 2014 at 8:14 AM, Patrick Georgi <patrick at georgi-clan.de>wrote:
>
>> Am Freitag, den 14.03.2014, 08:07 -0700 schrieb ron minnich:
>> > There's not much point in fighting the tide here. The idea of
>> linux-as-bios
>> > was nice, but we have come to the point where linux-as-bios requires a
>> > small firmware kernel just to load it.
>> Which could just as well be UEFI.
>>
>>
> we've walked this argument many times.
>
> I have a real problem with UEFI, namely, that the code is badly designed,
> and badly implemented, and badly written. I can't stand to look at it. It's
> the sort of thing that literally gives me a headache.
>
> Other than that, it's a fine starting point.
>
> ron
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140314/313a771d/attachment-0001.html>