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: Kenneth Adam Miller
Subject: Re: QEMU System and User targets
Date: Fri, 16 Jul 2021 13:20:41 -0500

Right, that's what I was thinking, that I shouldn't be building that for the system target. That's why I started out with the question that I did, because I was thinking that it probably hard codes it to user emulation. Currently though, understanding qemu internals is not so clear to me as I'm just becoming familiar with the code base.

On Fri, Jul 16, 2021 at 1:05 PM Peter Maydell <peter.maydell@linaro.org> wrote:
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]