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 <chr...@rtems.org >> <mailto:chr...@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 <silv...@gmail.com >> <mailto:silv...@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. I assume the main problem with lot's of repos is that it's slightly confusing to find anything? 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. What would be the advantages of one collection repo? PS: Maybe we should have created the maintainer playgrounds more as 'user/<name>', 'user-<name>' or 'private/<name>' or similar. Best regards Christian _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
