RTEMS Muilti-I/O lib is missing

Tue Aug 20 07:05:45 UTC 2019

On 20/8/19 4:51 pm, Christian Mauderer wrote:
> On 20/08/2019 00:32, Chris Johns wrote:
>> 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.
> 
> Your rtems_waf is a great starting point for reducing that effort (at
> least for the build system). But you are right that this can be a big
> hurdle.

It helps. I wonder if a step by step tutorial would help?

>> 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?
>>
> 
> 2 and 3 are both mainly about testing. I agree that this is really
> relevant. But is that really simpler with one repo than with multiple
> ones? If one repo contains multiple libraries, they need a way to build
> and test too.

Agreed.

>> 4. The release should capture the repos.
> 
> As long as we don't have scripts to do releases it's right that this is
> a huge extra effort for each repo. Good point.

But we do .. https://git.rtems.org/rtems-release/ ?

If the package is in the RSB I can get it to collect the source if we reference
the repo as a tarball, which is what we are now doing.

>> 5. Cluttering the cgit repo interface where our main focus repos get lost is a
>> sea of other repos.
> 
> That's why I suggested a prefix or sub-folder.
> 

Yes.

>>> 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.
> 
> Wouldn't it just work exactly like the sub-folders for everyone with
> commit access?

If it does this is a solution but I would need to check.

>>> What would be the advantages of one collection repo?
>>
>> Simpler management and shared overheads, ie build system, testing, releasing etc.
> 
> OK. All valid and good points. Some of them are definitively more
> relevant than my point of "the repo could get cluttered". But if one
> repo is created, we should be careful to have a look at new stuff and
> maybe re-discuss a separate repo for stuff that might get bigger.

I am happy with separate repos if there is a wider agreement on this so the
maintenance work is understood and shared :)

> By the way: Where do we draw the line whether something goes into the
> RTEMS core repo (like I2C or SPI) and when in some package repo (like
> the multiio discussed here)?

I think a package (repo) is a great to startinf point for an API  to field test.
I feel once we get something that is important to RTEMS as a more formal
interface it can be moved there and the repo can be archived.

>>> 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.
> 
> Yes right. And I don't want to question that. That was just a hint that
> it maybe would be good to migrate the playgrounds to some prefix on the
> long term. It's no urgent matter and I don't want to start that right
> now. It's just something that we should keep in mind in case we have an
> opportunity like a reorganization or similar. The reason is the same as
> mentioned above: It could make cgit (or similar lists) simpler to read
> if the playgrounds are grouped.

I like the subdir idea and it if works maybe we can have a playground. I just
need some time to look into it.

Chris