Hi, Thanks for the proposal.
On Wed, May 14, 2025 at 07:12:48AM +0000, Sookyung Ahn wrote: > I am writing to propose an enhancement to the `xen-tools` for users who > require only a minimal subset of its functionality, particularly in > safety-critical domains like aerospace. FYI, there's a project call `xen-tools`, at https://github.com/xen-tools/xen-tools/, and having it spell like reminds me of that external project, and not the tools in this repo. > I believe that the addition of a new build-time option, > `ENABLE_MINIMAL_XEN_TOOLS`, will significantly benefit users by allowing them > to build only the essential components needed for their specific > applications. > This approach not only streamlines the toolset but also reduces the potential > for unnecessary complexity in safety-critical environments. > This proposal is based on `dom0less` environment. > > The proposed implementation includes: > - Introducing the `ENABLE_MINIMAL_XEN_TOOLS` configuration flag. > - Modifying the build process to selectively include only the necessary > components based on the configuration. > > This implementation can be effectively applied to the following use cases. > - Minimal APIs for `dom0less` operation. This involves taking existing Xen > functions and shrinking them to minimal needed parts. For example, we can use > static device tree instead of XenStore. > - By retaining `libxencall` and minimum part of `libxencrtl`, the Hypercall > interface can be utilized, enabling support for the Xen ARINC653 Multiple > Module Schedules service. > - Addition of ARINC653 Part1&2 APIs and services (hosted on the domain OS.) > > I would appreciate any feedback or suggestions you may have regarding this > enhancement. > Additionally, I would like to emphasize the importance of community input in > refining this proposal to ensure it meets the needs of all users. I don't quite like this approach. What is "minimal"? Whatever definition we can come up with isn't going to fit other's expectation of a minimal set of tools. Also, the minimum set of tools needed might be 0, if you only need the hypervisor. Also, the implementation is quite invasive, with `CONFIG_MINIMAL_TOOLS` spread through the build system. It also duplicates configurations, with like "SUBDIRS-y += libs" been written twice in tools/Makefile. I feel like a better approach would be to have something like: ./configure --no-default --enable-flask --enable-hotplug ... As for the makefiles, instead of having to invent a config option for every single `SUBDIRS-y` we could have a generic SUBDIRS-$(subdir-default) where subdir_default is 'y' unless we want to select a handful of subdirectory. It might not be necessary to have a config option for everything, you could deal with some of the stray binary with the tool use to make package, like RPM where you select which files to packages (as already suggested), and for other tool just `rm` the few files not needed. Then, there's `libxenctrl`. For this one, it doesn't feel like a good idea to make it selectively smaller. Maybe there's a way to extract the functionality you need into a new lib? We kind of tried in the past to extract piece of it into lib with a stable interface, like libdevicemodel, libcall. So it might be a better approach to remove the need of libxenctrl in your environment. I hope that help. Cheers, -- Anthony PERARD
