[PATCH 009/111] DRVMGR: added driver manager to cpukit/libdrvmgr

[Gedare Bloom]

On Thu, Mar 5, 2015 at 5:29 PM, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>
>
> On 3/5/2015 3:44 PM, Gedare Bloom wrote:
>> Continued...
>>
>> A high-level question I have is whether we want to consider this
>> drvmgr as an externally-supported library, or if it is to be part of
>> RTEMS proper. It makes sense to treat it as third-party code if there
>> are other OSs that gaisler uses the same API for, but if this is
>> specifically designed for RTEMS then we may want to take "ownership"
>> of it in RTEMS Project and it makes sense to make the interface
>> changes (namespace, interface design) that I suggest. If it is to be
>> treated as third party code, then the interface changes do not
>> necessarily need to be made, but we do need to ensure there is a
>> visible "upstream" to contribute back to. More suggestions below.
> I am going to answer this from a very selfish standpoint. The SPARC user
> base is important to RTEMS.  The fact that Gaisler distributes tool binaries
> with an RTEMS version has never really caused us problems beyond
> recognizing the version when someone asks a question on the mailing list.
>
> If we treat this as third party code, then Gaisler will be unable to merge
> some number of drivers and other improvements to the LEON and NGMP
> BSPs. This is going to further drive the deviation between community
> RTEMS and Gaisler distributed RTEMS. The community distributed one
> will be harder to use and folks will be more likely to pick the Gaisler one
> due to more drivers.
>
> IMO we need to find a way to merge this code. Any capabilities that can be
> BSP independent, we need to find a way to make that happen.
>
> In talks with Daniel, this backlog has occurred not due to unwillingness to
> merge but due to overload, personnel, and personal issues.  The patch set
> has unfortunately grown in size since the first attempt to get through their
> patch backlog.
>
> I can't speak for Gaisler but my understanding is that they would prefer to
> be largely in sync with the community version and that is my desire as well.
> They want to treat us as upstream like we do gcc, binutils, etc. Sometimes
> we need a patch but it gets merged appropriately upstream as soon as
> possible. When a new upstream release occurs with our fixes, we switch.
Joel, My point was whether we want the drvmgr to be in the "rtems"
public api, or if it should be treated as a take-it-or-leave-it
library. Some of my comments in code review are only relevant from the
point-of-view of making the drvmgr more "rtems"-branded.

Gedare