On Tue, May 26, 2026 at 9:23 AM Peter Maydell <[email protected]> wrote:
> On Tue, 26 May 2026 at 15:52, Peter Maydell <[email protected]> > wrote: > > Some stuff has snuck back into qemu.h again (e.g. the > > prototype of init_main_thread() could live in user-internals.h > > but was put in the wrong place) > > I just sent a patchset moving a couple of prototypes out of qemu.h. > > > because this kind of "looks like > > a good place to dump random stuff" header is hard to keep clean. > > There's probably a better name than "qemu.h" for it. > > While I was doing it I thought about this part. I think in an > ideal world we would split qemu.h into different parts, e.g. > one header for the TaskState struct definition, one for the > user-access functions and macros, and so on (most of the QEMU > source files including qemu.h don't need everything it is > providing, only one of the three or four groups of APIs). > But doing this requires coordination across linux-user and bsd-user > so they both split the functions/types out of their qemu.h headers > together. That doesn't really seem worth doing to me, at least > not now while you still have a large backlog of bsd-user work > not upstream yet. > Yes. This is absolutely something that I want to do, which is why I asked the question. I'd like to get through the backlog first (or the bulk of the backlog) and then start to move to a common design pattern between linux-user and bsd-user and maybe find ways to refactor. One issue that I know of right now is we compile common-user once for all the builds, so it doesn't depend on TARGET defines, while what we need to do is also have something that compiles per TARGET for some of the sharing that I see as possible and likely desireable (see the recent thunk.c thread). While not worth doing TODAY, I see the light at the end of the tunnel for upstreaming and want to start thinking about it and start studying things so I can start a discussion in the coming months in an intelligent way. Warner
