libi2c: Claiming driver slot failed

[Joel Sherrill]

On 8/11/2013 7:16 PM, Nick Withers wrote:
> 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...?
I had never actually looked at the i2c driver so didn't realize the register
was implicit in the subsystem initialization call.

In this case, I agree with you that you could configure that the application
needs the i2c driver and the implicit resources be accounted for.

I don't know if this same logic applies to the other standard dynamically
registered drivers.


>> 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?).


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985