This is the mail archive of the ecos-patches@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: V2 flash - clean up device driver interface


> 4) I have removed the config field from the cyg_flash_dev structure.
>    There seemed to be no good reason for having both a config field
>    and a priv field, so where appropriate I have merged the two.

Well to me they served different purposes. priv is internal to the
device and opaque to everything else. config is used by the hardware
specific driver to configure the hardware independant part of the
driver. I wanted to make this more generic but also uniform. The
current legacy drivers use a number of methods to configure the
drivers, eg setting #defines and then including, or by setting various
things in CDL which get written into the pkgconf header file. Some
drivers would not use the config structure, but i expected more
complex ones, eg synth or ones that could use CFI to be configured
this way. Your AMD driver took a totally different approach which i
was not expecting.... I so no problem with mixing priv and config
together, but it seemed cleaner to me to have them seperate.

> 6) the CYG_FLASH_DRIVER() macro no longer allocates space for the priv
>    structure. That made little sense to me, with some drivers you
>    ended up allocating zero-byte arrays.

Its was opaque to the hardware specific driver, but it needs to
allocate it since one is required per instantiation of the
device. Making it part of CYG_FLASH_DRIVER keeps it simple for the
programmer of the hardware specific driver to make sure it is actually
allocated.

I was also being a bit paranoid about ensuring that anything that
could be needed by erase or program ended up in RAM. This means there
are less booby traps for the writer of flash devices. You seem to be
taking the opposite approach and try to ensure that as much as
possible can go in ROM and the coder has to be a little more carefull
about what they access while the ROM is unreadable.

        Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]