This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: flash driver organization
- From: "Gary D. Thomas" <gary dot thomas at mind dot be>
- To: Eric Smith <eric-ecd at brouhaha dot com>
- Cc: eCos development <ecos-devel at sources dot redhat dot com>
- Date: 27 Apr 2003 08:22:43 -0600
- Subject: Re: flash driver organization
- References: <34764.64.169.63.74.1051433185.squirrel@ruckus.brouhaha.com>
On Sun, 2003-04-27 at 02:46, Eric Smith wrote:
> Why are some flash drivers composed of code in include/foo.inl files (e.g.,
> amd, atmel, intel 28f), and others as src/foo.c files (e.g., intel
> bootblock, strata)? Which is preferred for new drivers?
>
Partially a matter of history, partly a matter of style. These
different drivers represent a learning curve by multiple contributors.
I'm partial to the ".inl" style, but both work equally well. The
key is, whenever possible, to write drivers that can be abstracted
in a way that allows maximum reuse in the future (when it makes sense).
> I need to cons up support for some SST parts, mainly the SST39VF400A.
> SST30VF800A, and SST39VF160. They use JEDEC-standard commands, the
> same as the AMD 29x parts, but with smaller, uniform sector sizes.
> Is it reasonable to simply add the SST parts to the AMD driver rather
> than creating a new driver? I see that the AMD driver already supports
> some Toshiba and ST parts. (And Fujitsu parts, but those and the AMD
> parts are both made by FASL, so they're identical other than the vendor
> ID.)
If these parts follow the same basic framework, then they
definitely should just be added to the AMD setup.
--
.--------------------------------------------------------.
| Mind: Embedded Linux and eCos Development |
|--------------------------------------------------------|
| Gary Thomas email: gary dot thomas at mind dot be |
| Mind ( http://mind.be ) tel: +1 (970) 229-1963 |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc |
'--------------------------------------------------------'