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: AT91 serial driver


>>>>> "Andrew" == Andrew Lunn <andrew@lunn.ch> writes:

    Andrew> On Fri, Oct 31, 2003 at 03:31:48PM +0100, Thomas Koeller wrote:
    >> Andrew, Laurent, ?yvind,
    >> 
    >> how are we going to get this resolved? We now have
    >> three patches competing for approval (although I
    >> think that ?yvind's patch is rather similar to
    >> Laurent's). Since Laurent and I both agree that
    >> merging the two different approaches into one driver
    >> is impractical, we are left with a choice of either
    >> deciding in favor of one patch and reject the other,
    >> or to include two separate driver packages into the
    >> repository.
    >> 
    >> Do we need more input to make a decision? In this case
    >> I'd suggest to post to ecos-devel to draw more
    >> attention at this topic. To me the main question seems
    >> to be whether it is more important to reduce system load
    >> or to preserve the semantics of driver operations to
    >> keep them consistent across different platforms. As this
    >> is a very basic question, some developers might want to
    >> comment on it.

    Andrew> My plan was to wait until you guys came to some sort of
    Andrew> consensus as what to do :-)

    Andrew> It seems to me we are heading towards two drivers and so
    Andrew> two packages. Each package should be clearly documented as
    Andrew> to what the advantage and disadvantages are over the other
    Andrew> so it clear to developers when they need to choose which
    Andrew> to use.

I am not familiar with the AT91 either, but another possibility might
be to have the two drivers in separate files within a single package.
There would be configuration options to choose between them and
compile properties associated with those options rather than with the
driver as a whole. That way some stuff like hardware-related #define's
could still be shared, but the actual implementations could remain
separate. Also users could switch between drivers by selecting one of
the options, rather than by unloading/loading entire packages.

    Andrew> Its then a question of which one is made the default
    Andrew> driver. I think Nick and the other maintainers should give
    Andrew> there opinion. They know the eCos philosophy better than i
    Andrew> do.

If one of the drivers is significantly simpler than the other, I would
make that the default. Otherwise I would prefer the one that compiles
to the smallest amount of code, or that uses the smallest amount of
static data.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


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