On Mon, Feb 13, 2017 at 5:28 PM, Julius Werner <[email protected]> wrote: > +1 for preferring a single-core concurrency model. This would be much more > likely to be reusable for other platforms, and much simpler to maintain in > the long run (way less platform-specific details to keep track of and figure > out again and again for every new chipset). You CAR problems would become > much more simple... just make sure the scheduler structures get migrated > together with the rest of the globals and it should work fine out of the > box.
FWIW, there's no coherency in CAR. It's per building block of the hardware units -- much like multiple nodes in AMD K* systems. Migrating CAR not necessarily a simple solution, but I'm not convinced we need multiple cores executing with CAR as a backing store. > > On Mon, Feb 13, 2017 at 12:31 PM, ron minnich <[email protected]> wrote: >> >> >> >> On Mon, Feb 13, 2017 at 11:17 AM Nico Huber <[email protected]> wrote: >>> >>> >>> >>> Another idea just popped up: Performing "background" tasks in udelay() >>> / mdelay() implementations ;) >> >> >> that is adurbin's threading model. I really like it. >> >> A lot of times, concurrency will get you just as far as ||ism without the >> nastiness. >> >> But if we're going to make a full up kernel for rom, my suggestion is we >> could start with a real kernel, perhaps linux. We could then rename coreboot >> to, say, LinuxBIOS. >> >> ron >> >> -- >> coreboot mailing list: [email protected] >> https://www.coreboot.org/mailman/listinfo/coreboot > > > > -- > coreboot mailing list: [email protected] > https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
