libi2c: Claiming driver slot failed

[Nick Withers]

First off, I'm sorry... I feel like I'm harping on this and maybe being
argumentative! I also feel that I haven't communicated what I see as the
issue / "non-optimal situation" effectively and that we might not be
totally on the same page, though.

On Fri, 2013-08-09 at 09:58 -0500, Joel Sherrill wrote:
> On 8/9/2013 8:51 AM, Nick Withers wrote:
> > It sounds like that wouldn't fundamentally affect the application / BSP divide though, right?
> No. The BSP provides a set of supported device drivers.
> The application selects which to use.

Not in this case, I believe. The BSP unconditionally attempts to load
the I2C driver dynamically without ensuring a driver slot is reserved
for it.

I don't believe there's any way for an application to enable or disable
this (there no CONFIGURE_APPLICATION_NEEDS_I2C_DRIVER, as we've touched
on), but may have missed something...?

> Some of those are
> installed statically while RTEMS are initialized. Some require
> tasking to be running during their initialization. Those
> are installed dynamically.
> > In this case, for instance, I believe libi2c's loaded dynamically (and hence there's no entry in the static driver table), but that that's really an implementation detail of the BSP and shouldn't really be visible to the app developer. Or perhaps in this case there should be a CONFIGURE_APPLICATION_I2C_DRIVER that could lead to a static driver table entry?
> My understanding is that this driver is part of a framework and
> the framework assumes it is initialized by the init task (e.g. dynamically
> installed).  If that's not correct, then it could be a static driver.
> 
> The CONFIGURE_APPLICATION_XXX_DRiVER constants are for static
> drivers only.

Sorry to be obtuse, but... Why? It seems like the perfect macro for it,
and I don't really see why a driver being loaded statically or
dynamically by a BSP / RTEMS (which I'm perhaps foolishly thinking of as
being an implementation detail) should necessarily present a different
interface to applications.

> In the current CONFIGURE_MAXIMUM_DRIVERS scheme, you have to
> include the number of static drivers which is normally implicitly
> computed.

One doesn't "normally" need to specify it at all, unless the application
itself is installing one dynamically (and yeah, your patch would make
this nicer, possibly nicer still if it were
CONFIGURE_APPLICATION_MAXIMUM_DYNAMIC_DRIVERS...?), right?

> This just makes it so you only specify how many drivers
> you register -- just like tasks you create. You don't explicitly count the
> idle task in your set.

This is exactly the point I'm trying to make, I think. *I'm* not
registering a driver (if I were, yeah, totally fair that I need to make
allowances for it). The BSP is. Outside of my / my application's
control...?

If I had one application-specific dynamic driver I wanted to load, for
example, and (with your patch) set CONFIGURE_MAXIMUM_DYNAMIC_DRIVERS to
1 to match, that'd fail... The I2C driver'd claim it before the
application code's even started. OK, so I set it to 2, instead. What
about another BSP that's got 2 to load itself, then? I need to knock it
up to 3 at least. I could set it arbitrarily higher than I need to to
make such portability easier, but doesn't that somewhat defeat the
purpose?

It seems to me like there's an inversion of the App -> BSP -> RTEMS
abstraction going on here, where the app effectively needs to know
"black-box" details of the BSP, making maintenence and portability more
difficult and error prone than needs be...?

Cheers heaps for your time, I hope I'm not just rambling and whingeing!
It's not a huge issue or anything, but by the same token, doesn't seem
on-the-face-of-it hard to improve / resolve (is the suggestion in
http://www.rtems.org/pipermail/rtems-users/2013-August/011770.html [with
BSP_I2C_DRIVERS rather than BSP_I2C_DEVS, my bad] silly?).
-- 
Nick Withers

Embedded Systems Programmer
Room 2.26, Building 57
Department of Nuclear Physics
Research School of Physics and Engineering
The Australian National University (CRICOS: 00120C)

eMail: nick.withers at anu.edu.au
Phone: +61 2 6125 2091
Mobile: +61 414 397 446