RTEMS Muilti-I/O lib is missing

[Chris Johns]

On 18/8/19 3:53 am, Joel Sherrill wrote:
> 
> 
> On Fri, Aug 16, 2019, 8:43 PM Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
> 
>     On 17/8/19 7:02 am, Joel Sherrill wrote:
>     > FWIW the repo is git clone git://git.rtems.org/multiio.git
>     <http://git.rtems.org/multiio.git>
>     >
>     > More below
>     >
>     > On Fri, Aug 16, 2019 at 3:20 PM Wendell Silva <silvawp at gmail.com
>     <mailto:silvawp at gmail.com>> wrote:
>     >>
>     >> Well, I'm a non-OAR user with at least one customer 100% satisfied with
>     multi-io lib.
>     >>
>     >> Suppose I'm going to championize it, how do I do to get started?
>     >
>     > I'm glad you are happy with it. I was happy with it on the robotic project
>     > I did with it.
> 
>     This repo could be added to the RSB as a package. It has been converted to
>     rtems_waf however it would be good to have the support changed from the files
>     being in the multiio repo to a submodule referring to the rtems_waf repo.
> 
>     Can the package be built for all BSPs?
> 
>     It would need to be documented. I was considering adding a Packages chapter to
>     the User Manual and it could be a section under that chapter.
> 
> 
> Personally, I think there are only two things of long-term value in it. A few
> shell commands and an interface to access discretes and analogs. 
> 
> If the interface is just considered a shim layer that an application can
> implement, then it is independent of any bsp. A system with multiple IO cards is
> abstracted through this by the system integrator.
> 
> Is it worth being independent then?
> 
> The two drivers in there now are PC-104 so only available to pc386 and possibly
> not even compatible with anything you can buy now. One was based on a single
> chip solution so may be available in later incarnations and for other buses. No
> idea though.
> 
> I don't mind treating it as a small package either. If we want to show how one
> should be done, this is small enough to be an example.

I do not know which is better, a common packages repo or separate repos for each
package. I am tending to lean to a packages repo where we can collect fragment
of code like this.

Chris