EEPROMs

[M. Warner Losh]

Greetings,

I have an embedded arm board that has about 4 different kinds of
EEPROMs on it.  These EEPROMs and flash parts are connected in various
and wonderful ways (spi, i2c, parallel bus, and mabye a custom fpga
thing).  There's also a number of add-in boards that have a few
different eeproms on them as appropriate for the board.  Not all of
these technologies will be in our final product, but I need to develop
drivers to talk to many of them for at least experimental purposes.

There's a desire to have all these eeproms available as real devices
to the system, some of them even GEOM providers (I think that's the
right term).  Some of these drivers may be on multiple busses (the
AT45DB642, for example, lives on either a SPI bus or a parallel bus).
Most of them will be tiny because the 'heavy lifting' for the devices
is done in the upper layer (initiating the i2c transfer, doing the spi
transaction, etc).  Sadly, these devices are all somewhat different in
the niggling little details that make them work, so separate drivers
will likely be needed for at least some of them.

Normally, we'd just create a src/sys/dev directory for each device.
We've done it with all the drivers in the system, except for really
old legacy jobs, usb (since it was ported from an os that doesn't
share quite the same world-view when it comes to drivers (ours is
driver centric, theirs is bus centric),and sound (which has a boatload
of supported drivers, all living under dev/sound subdirectories).

I'm thinking seriously of putting them under dev/eeprom or dev/flash
or something like that, and then creating subdirectories under than to
help the clutter in src/sys/dev.

Before I do such a radical thing, I thought I'd tell people my plans
so they don't freak when it hits the tree.

Comments?

Warner