hi..
the LAST thread in the saga! perhaps not as fun to read as your average Terry Pratchett novel, but hopefully as or more useful ;)
ok, so this thread is about the decision of whether to permit within the EOMA68 spec for the identification EEPROM to be writable.
there are three options:
a) the ID EEPROM must be writable b) the ID EEPROM must not be writable c) the ID EEPROM may be writable, but this should not be relied on by any software
let’s consider each in turn:
a) must be writable
this option raises quality issues for consumer devices where easy access to the EEPROM may be implicated in a variety of device damaging events. from virus propagation to accidental destruction of the device tree due to user- initiated EEPROM write ... this just isn’t a great option for many mass-market devices.
ergo, (a) is not an option.
b) must not be writable
for generic chassis (including, but not limited to, engineering boards) being able to write to the EEPROM is a requirement. so if the EOMA68 standard says that the EEPROM “must not be writable” then none of those boards can ever be certified as EOMA68 compliant.
this will result in specification defying chassis that work with EOMA68 CPU cards, but which aren’t themselves EOMA68 chassis. encouraging such defiance of the standard simply to fulfill completely valid use cases is a great way to lower the value of the standard"
"sure, there’s a standard *wink* *wink* but we all know that not all devices *really* follow it."
that is a horrible precedence to set in the very first revision of the spec.
c) may be writable, but portable software may not rely on this
this is a middle ground which allows devices which would be in violation of the standard in the (b) case to remain compliant, while allowing devices which really are best served by (a) to not only be compliant but also avoid having theoretically portable software not performing correctly on them.
basically, (c) implies that the EEPROM must be treated as not-writable in the general case. any user actions or software that attemps to write to the EEPROM is classified as non-portable and device-specific, and the EOMA68 would provide zero guarantees as to the expected behaviour in such cases.
as this allows for compliant generic chassis *and* mass-market consumer devices, i highly recommend (c)