[Arm-netbook] identification EEPROM: vendor-defined pages

[Aaron J. Seigo]

hi ...

3rd email in this saga, which asks the question:

	Should the DIDS spec allow for vendor-defined pages?

In the proposed DIDS layout, page IDs above 32767 are reserved. The opens the 
door for vendor specified pages.

A maker may wish to define and add non-standard pages to their DIDS for (at 
least) one of the two following  reasons:

* the page definition has been proposed to the standard, but is not yet part of 
the DIDS spec. this allows a maker/vendor to ship a device with that 
information without being held up by (or worse: *violating*) the specification.

* it may be device implementation specific data, and by allowing the additional 
pages to be included in the DIDS it allows using a single EEPROM chassis 
design

Benefits include:

* allowing re-use of pre-existing chassis PCB layouts without needing to 
adjust them so as to add additional EEPROMs 

* prevents inappropriate use of mass storage (do we really want to see more 
“magic” partitioning, such as magic offset values, for mass storage devices?)

* conservation (the ecological argument): if there is space on one EEPROM, why 
use two?

With the proposed paged layout, there is zero technical reason why allowing 
make/vendor-defined pages would be a bad thing. The DIDS spec has 10s of 1000s 
of page IDs left to use for standard pages and it comfortably allows for 
vendor pages without making reading/writing of the DIDS any harder or more 
complex. There is zero cost to the EOMA68 standards or the DIDS layout by 
allowing maker/vendor-defined pages. Zero.

The only reason provided so far is a desire to control vendors. As a 
maker/vendor, I find that concept utterly repugnant when there are reliable and 
sensible technology answers.

Specifications should standardize and enable, rather than shackle, adopters.

-- 
Aaron J. Seigo