qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: QEMU System and User targets


From: Peter Maydell
Subject: Re: QEMU System and User targets
Date: Fri, 16 Jul 2021 19:04:50 +0100

On Fri, 16 Jul 2021 at 18:50, Kenneth Adam Miller
<kennethadammiller@gmail.com> wrote:
> There's a lot of files and I don't want to muddy up the discussion with too 
> many details.

If you don't provide details, you get vague answers. Your choice :-)

> And for sure, this is not a problem with the upstream qemu. I'm working on 
> adding a target, and this is just what I'm experiencing. As for my target, it 
> has includes that correspond to finds within sub-directories of qemu 
> components, and I just mean that the include directives are only the file 
> name (no path prefix), but such file can be found only in folders other than 
> the include directory. One example is qemu.h; it is in linux-user. You can 
> get the compilation to find exactly just that file, but it includes other 
> files, and it isn't reasonable to edit anything outside of my own 
> architecture implementation. I'm wondering if perhaps anything that makes an 
> include to linux-user would need to be moved into the user target source set, 
> because currently it is in the shared.

The broad-strokes answer is "your code in target/whatever should generally
not be including files that are neither in include/ nor in target/whatever".
If you find yourself doing that you've probably structured something wrong
(otherwise other targets would also have run into this).

For linux-user/qemu.h in particular, the top level meson.build does
add linux-user/ to the include path, but only for when it is building
files for the linux-user targets. (It makes no sense to include that header
file into code built for system emulation.)

Of the 4 targets that #include "qemu.h" in target/whatever code, 3 of them
(m68k, nios2, arm) do it only for their semihosting .c file, and there
the #include "qemu.h" is inside an #ifdef CONFIG_USER_ONLY. (Semihosting
is a bit of an odd thing which works differently for usermode and
system emulation mode, which is why it needs this linux-user header.)
The 4th is hexagon, and that is a bug in the hexagon code which is only
going unnoticed because hexagon currently supports only the linux-user
target and not system emulation.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]