<div dir="ltr">Hi All,<div>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.</div><div><br></div><div>Firstly, as Alex mentioned</div><div>
If, on the other hand, you have a well designed, unified block dev API, you</div>can select your block device based on some some heuristic to decide which<br>media to boot from. <br><br>Why is this better? You don't need two implementations of alternate_cbfs,<br>
which are extra code size, extra code, and generally look ugly and complicate<br>the code.<div><br></div><div>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.  </div>
<div><br></div><div>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?</div>
<div> </div><div>Also, I would like to ask Ron, he said:</div><div><span style="font-family:arial,sans-serif;font-size:13px">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. </span><br>
</div><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">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? </span><span style="font-family:arial,sans-serif;font-size:13px">  </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Regards,</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Naman</span></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 14, 2014 at 8:48 PM, ron minnich <span dir="ltr"><<a href="mailto:rminnich@gmail.com" target="_blank">rminnich@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Fri, Mar 14, 2014 at 8:14 AM, Patrick Georgi <span dir="ltr"><<a href="mailto:patrick@georgi-clan.de" target="_blank">patrick@georgi-clan.de</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am Freitag, den 14.03.2014, 08:07 -0700 schrieb ron minnich:<br>
<div>> There's not much point in fighting the tide here. The idea of linux-as-bios<br>
> was nice, but we have come to the point where linux-as-bios requires a<br>
> small firmware kernel just to load it.<br>
</div>Which could just as well be UEFI.<br><br></blockquote><div><br></div></div><div>we've walked this argument many times. </div><div><br></div><div>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.</div>

<div><br></div><div>Other than that, it's a fine starting point.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>ron </div></font></span></div><br></div></div>
<br>--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="http://www.coreboot.org/mailman/listinfo/coreboot" target="_blank">http://www.coreboot.org/mailman/listinfo/coreboot</a><br></blockquote></div><br></div>