RE: [EXTERNAL] Re: [RFC PATCH 0/2] Propose an minimal xen-tools

["Weber (US), Matthew L" <matthew.l.weber3@xxxxxxxxxx>]

Anthony & Ayan,

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Anthony 
> PERARD
> Sent: Wednesday, May 21, 2025 9:27 AM
> To: Ahn, Sookyung <sookyung.ahn@xxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Weber (US), Matthew L 
> <matthew.l.weber3@xxxxxxxxxx>; Whitehead (US), Joshua C 
> <joshua.c.whitehead@xxxxxxxxxx>; Choi, Anderson <Anderson.Choi@xxxxxxxxxx>; 
> Wood (US), Brian J > <brian.j.wood2@xxxxxxxxxx>; Kim, Haesun 
> <haesun.kim@xxxxxxxxxx>
> Subject: [EXTERNAL] Re: [RFC PATCH 0/2] Propose an minimal xen-tools
>

<snip>
 
> > 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.
> > 

@ayan.kumar.halder@xxxxxxx  what is automotive planning to do for XL tool stack 
in a FuSa 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 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.
>

This is good feedback.  The other route we had looked at is establishing a new 
library that's specifically focused on ARINC653.  The Xen existing ARINC653 
scheduling support has some out of tree tools we're looking to integrate in and 
we're working to finish implementing the standard.  So maybe the basis for this 
new library is more around ARINC653 and not minimizing the existing XL tool 
stack.  (We'd have the XL tools disabled in a dom0less safety certification 
configuration.)

> 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 see, sounds like the possible way forward is for us to make a libxenarinc 
static library that pulls in only what's needed.  Then look at the ./configure 
approach to enabling that library and seeing if we can selectively build solely 
that new library.

Best Regards,
-
Matthew L. Weber
Associate Technical Fellow / LXF ELISA Aerospace WG Chair