anchao commented on PR #15765: URL: https://github.com/apache/nuttx/pull/15765#issuecomment-2686602047
> I know about the implementation duplication before, libelf and modlib were about the same. However, will we have a need to "re-introduce" modlib, if it gets capability to load modules other than elf format ? Or will we just implement the new module loader into whateverlib and re-create modlib as a wrapper ? > > Because I suspect the original intention of modlib was not at all to duplicate code, it was supposed to be higher in the code hierarchy compared to libelf ? Actually, that's not the case. In the architectural design, the structure of binfmt should be reused to complete the glue code. modlib is just a part of libelf. If we consider the design from the user's perspective, some future loadable types, such as coff, fdpic, flat, misc, script, etc., should be integrated with binfmt rather than with modlib. https://github.com/torvalds/linux/blob/master/fs/binfmt_elf.c https://github.com/torvalds/linux/blob/master/fs/binfmt_elf_fdpic.c https://github.com/torvalds/linux/blob/master/fs/binfmt_flat.c https://github.com/torvalds/linux/blob/master/fs/binfmt_misc.c https://github.com/torvalds/linux/blob/master/fs/binfmt_script.c https://github.com/alexbousso/kernel_2.4.18-14/blob/master/fs/binfmt_coff.c This is where they belong: https://github.com/apache/nuttx/tree/master/binfmt -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
