On 27/02/2020 18:14, Amar Takhar wrote: > On 2020-02-27 08:45 +0100, Christian Mauderer wrote: >> >> It's just another problem that I noted sometimes on the mailing list >> with RTEMS and libbsd: Sometimes libbsd doesn't compile with some odd >> error messages like unresolved symbols. Most of the time the problem is >> that libbsd has been updated by the user but RTEMS hasn't. Having >> defined versions in a master repository could help the average user to >> see which version should be used together. On the other hand someone >> would have to keep it up to date and I'm not sure whether all >> maintainers would be happy about another necessary maintainance task. >> Therefore it's not yet a well thought through idea. > > The only good way to handle this is to have it all in 1 giant repository we > work > with. Every other solution is a pain no matter how well thought out it is. > I > personally lean more on the service side of things that it should be *our* > problem to maintain this and for users it should just work.> > The easiest way to handle this is to have the minimum version required in the > commit message. Eg, when pushing to libbsd have: > > Minimum RTEMS: <hash> > > After that it's up to the user to ensure to keep up-to-date. The first thing > most developers do is check the log.
Sounds like a nice suggestion. But it needs quite a lot of discipline for the developers. So most likely a lot of errors will happen. Beneath that it's not far from what we do now: Suggest to use commits from the same date. But maybe we should move that discussion. It's not FDT related anymore so no one will find it in this toppic. And I think for Chris the pressing matter is FDT just now because it blocks the release. > > Regardless of what we choose none of it will work if the user is not updating > their repository or checking online for changes. Having it in the commit > message also helps for build automation. I've used git tags for this in the > past but hardly anyone uses or checks those which is too bad. > > >> If you are a new user and see "for this BSP use the FDT from X" but you >> want to use some other BSP and someone tells you "for that BSP the FDT >> isn't in X but at Y" it maybe isn't really that clear. Therefore - if we >> introduce some handling - I would be in favor of only one location and >> not a mix of two or three. Otherwise the situation is only slightly >> better than now. > > Having a section in the documentation to manage this is fine I think. It's > either going to say: > > 1. The FDT source is in rtems-fdt.git > 2. The FDT source is already in RTEMS you don't need to do anything. > 3. You need to purchase a board and place the files <here> > 4. Covers all: If you want to roll your own place the files <here> -- same > place as #3 maybe. > > An easier way to make a decision would be to see what we're looking at right > now. How many would be in-tree and how many external? > The BSP groups that use bsps/shared/start/bsp-fdt.c are: - riscv/riscv - arm/imx - arm/beagle - arm/raspberrypi - arm/altera-cyclone-v - powerpc/qoriq For beagle and raspberry it should be definitely the FreeBSD FDT. For imx: I'm currently working on imx6 support in the imx BSP and that one will use a FreeBSD derived one too. Not sure about the original imx7 support in that BSP. For the other BSPs I don't have any idea which FDT has been used during development. Best regards Christian > > Amar. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel