gustavonihei commented on pull request #4233: URL: https://github.com/apache/incubator-nuttx/pull/4233#issuecomment-887494626
> > How do you suggest that an application performs the loading and execution of the next application image? > > I would suggest using BOARDIOC_IOCTL. That allows board-specific boarctl() commands. It works exactly like the other BOARDIOC commands but does not clutter the system with garbage BOARDIOC commmands. Imagine where that will go in the long run i we allow everyone to do that? > > The only real difference is that the board-specific IOCTL commands would be defined in a different header file in the board/include or in the arch/include directory. > > boardctl() is a nasty kludge to bypass the standard POSIX interface. It really needs to be avoid as much as possible if you want to claim to be a portable, POSIX system. But, unfortunately, there are things that need to be done that are not covered by any POSIX interfaces. So we created this backdoor. But we can only allow the backdoor to be open a crack or we will be swamped with board-/applicatoin-specific IOCTLs which would be a very bad consequence. > > Creating another BOARDIOC command does make it it has general usability but should never be done for a one-off solution. Right, I can see pros and cons in opting for the generic `BOARDCTL_IOCTL`. Functionality-wise it is no different than creating another BOARDIOC command, after all it goes through the same path. I agree with you that if we indiscriminately keep adding more and more commands the list will someday become a mess. But the benefit of a creating a new command in this scenario is that it might be supported by any platform. So if we have it properly documented and listed as a `BOARDIOC` command eases the standardization across the OS. In this case, `BOARDIOC_LOAD_APPIMAGE` will be used by one bootloader application, but it may easily be reused by others to come. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
