Re: XenSummit: Empty per-arch files

[Oleksii <oleksii.kurochko@xxxxxxxxx>]

Hello,

On Wed, 2023-06-28 at 15:54 +0200, Juergen Gross wrote:
> On 28.06.23 15:46, Andrew Cooper wrote:
> > On 28/06/2023 2:26 pm, Juergen Gross wrote:
> > > On 28.06.23 13:32, Andrew Cooper wrote:
> > > > Hello,
> > > > 
> > > > This wasn't a formal discussion point at XenSummit, but Oleksii
> > > > pointed
> > > > out that it was still a problem, hence this thread.
> > > > 
> > > > As we take on more architectures, it becomes more and more
> > > > important for
> > > > things to be handled in a mostly-common way.  With that comes
> > > > quite a
> > > > lot of <xen/foo.h> including <asm/foo.h>, and the arch one
> > > > being a stub
> > > > in simple cases.
> > > > 
> > > > It would be nice to get rid of the stub files; they're
> > > > irritating to
> > > > deal with, both when refactoring and simply for the file bloat
> > > > they
> > > > create.
> > > > 
> > > > There are two options which come to mind.
> > > > 
> > > > 1) Use __has_include().  This would be ideal, but would require
> > > > us
> > > > bumping the minimum GCC version to 4.9.2 as a prerequisite. 
> > > > I'm not
> > > > aware of any way to emulate the necessary behaviour on older
> > > > toolchains.
> > > > 
> > > > 2) Have a stub "architecture" which is always last on the
> > > > include path.
> > > > This would reduce the number of stub files from one set per
> > > > arch, to
> > > > only one set.
> > > > 
> > > > Anything else that I've missed?
> > > 
> > > What about a make rule creating an empty include file if it is
> > > missing?
> > 
> > Wouldn't that cause a typo'd header file name to spring into
> > existence ?
> > 
> > And it would cause a build to leave the working tree dirty.
> 
> Depends how it is done.
> 
> There could be a file containing the allowed header names to be
> generated.
> 
> And the files wouldn't need to be generated in
> arch/<arch>/include/asm, but
> could be generated in e.g. include/generated/asm which would be used
> after
> the arch include path.
> 
> This would basically be the central stub variant you were mentioning,
> but
> building it dynamically.

I started to analyze how many headers right now are empty, and it looks
not too many for ARM and x86.

For RISC-V, when the building of common code is enabled, the number of
empty headers will be around 4-5. But at the end ( when will be enough
functionality to run dom0 ), the amount of empty headers is 2 (probably
a little bit bigger, I don't remember and don't have access to my
source code )

However, at least between ARM and RISC-V, many headers are the same (
or they can be the same after some refactoring, f.e cache.h ).

So, it would be better to use stubs instead of dynamically generated
empty headers, as it looks like overkill only for a few empty headers.
But who knows what will be in the future, and possible it makes sense
to have a combination of stubs and dynamically created empty headers.

If no one is fine with me, I can implement that as common code will be
enabled for RISC-V soon.

It may be helpful for PPC too soon.

~ Oleksii