RTEMS Muilti-I/O lib is missing

[Christian Mauderer]

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.

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

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

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

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

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

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

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

Best regards

Christian

> 
> chris
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

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