David,
On 05/22/2018 07:12 AM, David Rusling wrote:
On Tue, 22 May 2018 at 11:52 Peter Robinson <pbrobinson@gmail.com mailto:pbrobinson@gmail.com> wrote:
On Tue, May 22, 2018 at 11:40 AM, David Rusling <david.rusling@linaro.org <mailto:david.rusling@linaro.org>> wrote: > All, > I'm writing a blog on Linaro's reorganisation (sounds fascinating doesn't > it?). I'm more talking about directions than teams etc, it's not a list of > groups / SIGs etc. One area I'd like to highlight is the importance of EBBR > to LEDGE (aka Fog and Networking). Some thoughts / questions: > > [1] do others believe that EBBR is key to Fog / Edge? I'm less convinced > that Device land will see the push (their is a symbiotic link between > gateways and devices, with gateways being the 'point of security' for their > 'slave' devices). I think it's likely useful to fog/edge but not critical, it will depend a lot on the size of the device. In the arm space it'll be either EBBR or SBBR/SBSA, either way standardisation will be good.Well, people misuse the term 'gateway' wildly from tiny bridge devices to grown up things. It will be uneven, but the push will come. Weaker than the data center.
Sure some of these devices will be so server like they should follow the whole SBBR/SBSA. But there will be others that need something lighter. That is where the EBBR should come in. We are trying to make sure it scales down to even $7 boards.
I do think the EBBR is important for this Fog/Edge eco-system but I do not think it will be obvious to everyone that they should pay attention.
The competition for EBBR will be the status quo. Many people see no need to make their HW run multiple OSes. They believe that their custom tweaked OS is the only thing that need ever run.
The same thing is true in the network switch world but the existance of the ONIE project suggests that that world has seen the value of multiple installable OSes.
A robust container eco-system actually decreases the need for EBBR because all the real need for portability is hidden in the containers. A given HW platform just needs the base container host and everything is good.
Luckily there is such a diversity for container hosts systems, the need for EBBR re-emerges so the HW vendor does not need to lock into just one.
> [2] EBBR et al is complex, so moving down the reference platform route makes > sense (to me at least). I know that reference platforms created a lot of > debate in Linaro in LEG, but I think that has settled down now, with > everyone understanding what they are and are not and where the value is. >
I don't know if I agree with the complex part. We are trying to make it easy for HW vendors: Use latest upstream U-boot configured this way and your done. Want to add features? Add these things to your HW.
However for the U-boot/EDK/OS authors we do want a test platform and to show it done well.
As already discussed some in the EBBR calls, QEMU should be "the reference platform". We can configure QEMU to be a very HW resource rich system, a very HW resource constrained system, or any thing in between.
We hope and expect that multiple boards will then buy into this system and be able to show it working. But that is really up to each board's owners / landing team whatever. These are not "reference platforms" but examples of EBBR in the wild. The more the merrier; no one is picking just one real HW platform.
Bill