RE: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

2021-04-16 Thread Desimone, Nathaniel L
On Thu, Apr 15, 2021 at 1:29 -0700, ron minnich wrote: >I'd rather not take HOB as a given without considering alternatives. >It's a very 1990s design. Device tree is also a very early 90s design for that matter. If we are talking about clean slate design, how about something actually new and

Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

2021-04-15 Thread ron minnich
actually isn't device tree a 1980s design :-) anyway, as long as we can hit the things I care so much about, self describing alignment independent endian independent names not magic numbers (I mean, you want to put a UUID in there too, fine, but I doubt a human-readable string will kill us on

Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

2021-04-15 Thread ron minnich
On Thu, Apr 15, 2021 at 11:25 AM François Ozog wrote: > > > "packed" at least works otherwise no network protocol would be operating > as expected. > that is a very common misconception. C code for networks existed for decades before packed existed. packed does not exist in plan 9 compilers to

Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

2021-04-15 Thread François Ozog
On Thu, 15 Apr 2021 at 19:42, ron minnich wrote: > HOBS are "bad'. > > several reasons. > 1. They depend on the nature of the C compiler and require use of a keyword > ("packed") known to be an issue. > (i.e. there are alignment and padding requirements that not all > compilers handle the

Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

2021-04-15 Thread ron minnich
HOBS are "bad'. several reasons. 1. They depend on the nature of the C compiler and require use of a keyword ("packed") known to be an issue. (i.e. there are alignment and padding requirements that not all compilers handle the same way for all versions) In fact, interestingly, a recent

Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

2021-04-15 Thread Loïc Minier
I won't be able to make the time in 15mn (I misread the Gcalendar's TZ and thought it was at 1pm my time) , but I'd love to be invited to future meetings; this 7pm CEST time might be problematic for me some weeks where I have other commitments, but I'll do my best to attend :-) On Thu, 15 Apr

Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

2021-04-15 Thread François Ozog
On Thu, 15 Apr 2021 at 17:21, ron minnich wrote: > Loic, it is wonderful to have you here. I think in the OCP OSF call today > (to which you are now invited, if you want; let me know -- same applies to > everyone here who's interested in open compute platform open *system* > firmware standard) >

Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

2021-04-15 Thread Loïc Minier
Hi Ron, Apologies; I clearly hadn't read enough. I just recently joined the OCP-OSF project's mailing-list as I wasn't aware of the effort before, and had only read the welcome web page. I've now read through the Governance, Charter and Transition schedule docs, and also saw the Pilot's draft

Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

2021-04-15 Thread ron minnich
I do wonder if you have read the OSF doc. That was a lot of work over a near 3 year period, and your doc looks like the very early drafts of that doc. I think it would pay to take a look. On Wed, Apr 14, 2021 at 10:52 PM Loïc Minier wrote: > Hi! > > Sorry for the late reply, here's a draft the

Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

2021-04-12 Thread ron minnich
You can see how quickly this gets complicated. It is why we tried to keep the OSF requirements as simple as possible. The requirements, in their most basic form, allow owners of systems to modify firmware, install it, and share it. Open source is not required. But for customers to install

Re: [OCP-OSF] Firmware: Sustainability vs planned obsolescence

2021-04-09 Thread François Ozog
On Thu, 8 Apr 2021 at 19:53, ron minnich wrote: > You can see how quickly this gets complicated. It is why we tried to > keep the OSF requirements as simple as possible. > > The requirements, in their most basic form, allow owners of systems to > modify firmware, install it, and share it. Open