I've had to deal with this issue quite a lot in the past it can be really annoying having to maintain separate repositories where we have to 'pin' a version to the main repo. We don't really have a choice here however I would suggest we do a mix of the two.
1. Any source/permissive files be kept within the RTEMS repository. 2. Binary blobs get ejected to a separate repository lets say 'rtems-fdt'. 3. Source files with strict licensing gets the boot, too -- though we can discuss how much we care about this. How it would work is simple. During configure if the required FDT files exist that's great we look for the two binaries we need and build them all as part of the normal building process. If they are not found print a notice to the user to get the 'rtems-fdt' repository and point to it with a --rtems-fdt-path= This is where it gets annoying because there are several steps to get the right file. Generally we have to: 1. Read a file stored within RTEMS that says what version of the FDT repository to checkout. 2. As part of configure this file needs to be loaded and the 'rtems-fdt' repository checked to see if it's at the right revision. 3. If it as not at the right revision then the user will have to fix this manually and re-run configure. 4. Some BSPs may not even have the FDT files until you purchase a board. Do we have any of these cases? Now we have a situation where we have no revision *or* files and no way to test this code or ensure it even works. Regardless for case #4 it's going to be a user issue to get the FDT files and our issue to suck these in. It makes sense to do it this way for RTEMS as I don't see a reason to "punish" the BSPs where everything is free and open it would be great to have these 'just work' and it is less maintenance for us longterm. Amar. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel