Jonathan A. Kollasch <jakllsch@kollasch.net> wrote:

> I'm going to have to comment on this sillyness.
>
> What exactly is the point of this code?

Provide access to memory SPD data, and decode most common/most useful 
fields.

> What is wrong with seeprom(4)?

As pointed out elsewhere, seeprom(4) doesn't seem to exist here, and 
eeprom(4) doesn't seem to bear on this issue.

> Why is this decoding being done in kernel space?

Well, it certainly could be moved to user space.  In fact, most of the 
SPD contents is not decoded at all.  Only a few items are decoded here 
in kernel space, and those would be data of more-or-less univeral 
interest (if you didn't want to know these values, you probably wouldn't 
bother to include the driver).

The entirety of the first 64 bytes of the SPD data is made available via 
a new sysctl hw.spdmem#.spd_data so that the remainder of the SPD data 
can be decoded in user mode.  The actual decoding is left as an exercise 
for the reader.


----------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:   |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul@whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette@juniper.net |
----------------------------------------------------------------------