RTEMS Muilti-I/O lib is missing

Tue Aug 20 07:18:23 UTC 2019

On 20/08/2019 09:05, Chris Johns wrote:
> 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/ ?

Although I have to confess that I don't really know a lot of details of
the release process, I know that you do a lot of great and valuable work
for each release. From your arguments it sounded like it would be
simpler for the release if there is only one repo. So I assumed that
there are some manual steps for each repo that are not in scripts.

> 
> 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 :)

Maintenance work include the points above (testing, integrating the
repos into the build infrastructure, manual steps for release) and most
likely creating the repo, the github mirror and all hooks? Do we have a
list what is necessary for each repo?

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

OK.

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

Like I said: Nothing that I wanted to start right now. Just planting the
seed for the idea in case an opportunity arises some when in the future.

Best regards

Christian

> Chris
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.