<div dir="ltr">yeah, david and nico both make very good points. I like the idea of  JSON file, and further we're working on a Go program<div>on the u-root project that would parse said file (trivial in Go to parse JSON, it's one statement and blam! your Go struct is all</div><div>filled in) and then decide what to configure/what to download/how to validate (we have a gpgv command written in Go by</div><div>Eric Grosse) and then how to kexec it.</div><div><br></div><div>I think what we're doing might be useful?</div><div><br></div><div>ron</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 27, 2016 at 6:04 PM David Hendricks <<a href="mailto:david.hendricks@gmail.com">david.hendricks@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Sat, Nov 26, 2016 at 2:46 PM, ron minnich <span dir="ltr" class="gmail_msg"><<a href="mailto:rminnich@gmail.com" class="gmail_msg" target="_blank">rminnich@gmail.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_msg">coreboot today is linuxbios minus the linux. The original intent was always that linux be our lifeboat. The current set of (as you point out) not terrific options is a result of linux growing too big for flash, and flash growing too big for linux, ca. 2002, when we adopted the payload model. The original keyword in the config file was 'linux', not 'payload'. The bootloaders we adopted (etherboot, filo, ...) were never (to me) a very satisfactory replacement for linux. They always came with lots of limitations. <div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">But why linux? Why a full OS? Simple observation, here in my 35th year of working with firmware and bootloaders. </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Every bootloader starts simple, and becomes an OS. Every single one starts with the intent of being small and compact and only supporting some needed subset of file systems/devices/protocols and ends up implementing everything. Because there was an attempt to start out simple, no matter how good the intial design is, that design is overwhelmed by the continuous addition of features, the result being a badly bloated, huge system with no apparent design.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Totally agree with everything Ron said. But as I read Nico's proposal, he is asking how we might specify the thing that is loaded by the bootloader whether the bootloader is a Linux kernel or FILO or Depthcharger or whatever.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">So for the purposes of this, let's presume we have coreboot+linux in ROM. What do you do once your kernel is loaded and you're able to read all the storage devices or get on the network? Do you read each storage device in whatever seemingly random order they were enumerated in and boot the first thing that looks like a kernel? Do you download a kernel using TFTP? And so on.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">One positive aspect of Nico's proposal would be to mitigate the bloat one can reasonably expect to need to support. Say that we have a vendor who wants to support a relatively generic coreboot distro and use Linux as the payload. How many filesystems and networking protocols should they really need to worry about in order to consider their distribution "well-supported?"</div><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div>
</blockquote></div>