RTEMS Muilti-I/O lib is missing

[Chris Johns]

On 20/8/19 5:12 am, Christian Mauderer wrote:
> On 19/08/2019 00:35, Chris Johns wrote:
>> 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
> 
> Hello Chris,
> 
> I had some bad experience with collection repos in the past (private and
> at work). They tend to become big and contain a lot of unrelated stuff.
> Even if you only want a small part, you always have to clone everything.
> And some packages might grow with time and then it's hard to split the
> repo up.

This makes sense and I am concerned this could happen.

> I assume the main problem with lot's of repos is that it's slightly
> confusing to find anything? 

It can but I hope no matter which path is taken we have some documentation that
helps a user.

My main concerns are:

1. Creating a repo, build system and test set up for small pieces of code can be
an obstacle to the code being placed in the open.

2. We need to have a way to test each repo, building and even running tests. The
RSB's 3rd party packages support is a good start and when combined into a
package set for a BSP it should be easy to build with a single command.

3. Testing?

4. The release should capture the repos.

5. Cluttering the cgit repo interface where our main focus repos get lost is a
sea of other repos.

> If that's the only reason maybe it would be
> better to add a prefix or put packages into a sub-folder. Something like
> 'rtems-packages/multiio' in this case.

This could work. I see cgit has a `project-list` option but I would need to
check in detail if it fits doing this.

> What would be the advantages of one collection repo?

Simpler management and shared overheads, ie build system, testing, releasing etc.

> PS: Maybe we should have created the maintainer playgrounds more as
> 'user/<name>', 'user-<name>' or 'private/<name>' or similar.

Anyone with commit access has a personal playground now.

chris