On Fri, Apr 14, 2023, 3:00 PM Gedare Bloom <ged...@rtems.org> wrote: > On Tue, Mar 28, 2023 at 4:27 AM Karel Gardas <karel@functional.vision> > wrote: > > > > > > Folks, > > > > I'm using FreeBSD's libefi on my hacked multiboot2 based amd64 BSP which > > I'd like to push for review (at least). > > > > Now, I'd like to prepare libefi for import but I'm still in doubts if to > > do that in: > > > > - as intact form as possible, import even files which will not be used > > in foreseeable future or even ever > > > It looks like a lot to import wholesale. usually within RTEMS itself > we have been selective and prefer to avoid bringing in dead > code/files. >
I think this is a pretty solid guide to follow. Unless you find yourself importing all but a handful anyway. Or there is a clear near term path to needing it. Avoid dead code but don't make it harder to maintain in the future. I like a file named ORIGIN which identifies the source info/hash. > > > - as minimalistic as possible. Include only files really needed by > > RTEMS. Where making compilation issues #ifdef __rtems__ as usual. > > > This would be preferred I think, in rtems.git at least. > Hopefully you can just follow the rules that we use for libbsd. > > > What exactly I need to import is: > > > > https://github.com/freebsd/freebsd-src/tree/main/stand/efi/include > > https://github.com/freebsd/freebsd-src/tree/main/stand/efi/libefi > > > > In 'include' I'd like to omit risc/arm/arm64 platform specific > > subdirectories for now. > > > > Anyway, plan is to put both those directories into > > bsps/shared/freebsd/stand/efi to mimic perfectly location in FBSD tree > > and to have them ready to be reusable later for arm64 and risc-v BSPs > > consumption. > > > I think it makes sense. The only issue to me is that usually the > bootloader stuff is in start/ directory. You might put any > rtems-flavored interfaces to use the efi services into shared/start > perhaps. > Agreed on location. Keeping the FreeBSD source as intact as possible even if it's a subset is critical. Leave architecture specific code under the top shared/.../efi since that's what they did. Maintain source transparency back to the original code. When in doubt, ask yourself: when I revisit this in 5 years to try to update it, will I know what happened? And answer that question with whatever makes life easier for future Karel. :) --joel > > > > > Thanks! > > Karel > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
