On Tue, May 26, 2026 at 8:44 AM Philippe Mathieu-Daudé <[email protected]>
wrote:

> On 26/5/26 16:39, Warner Losh wrote:
> > On Tue, May 26, 2026 at 1:53 AM Philippe Mathieu-Daudé <
> [email protected]>
> > wrote:
> >
> >> On 24/5/26 18:57, Warner Losh wrote:
> >>> On Sun, Feb 1, 2026 at 7:54 AM Alex Bennée <[email protected]>
> >> wrote:
> >>>
> >>>> Warner Losh <[email protected]> writes:
> >>>>
> >>>>> OK. I've updated bsd-user fork from last year to yesterday. I had one
> >>>> question.
> >>>>>
> >>>>> I see that we've gone from tb_flush() to queue_tb_flush(). Why was
> >> that?
> >>>> And is it a drop in?
> >>>>> FreeBSD's fork has this in the thread creation:
> >>>>>
> >>>>>       /*
> >>>>>        * If this is our first additional thread, we need to ensure we
> >>>>>        * generate code for parallel execution and flush old
> >> translations.
> >>>>>        * Do this now so that the copy gets CF_PARALLEL too.
> >>>>>        */
> >>>>>       if (!(cpu->tcg_cflags & CF_PARALLEL)) {
> >>>>>           cpu->tcg_cflags |= CF_PARALLEL;
> >>>>>           tb_flush(cpu);
> >>>>>       }
> >>>>>
> >>>>> I think the right thing to do is to just change this to
> >>>> queue_tb_flush(cpu), and that compiles. I'd like to get some
> >> confirmation,
> >>>> though.
> >>>>> Did I parse the changes right?
> >>>>
> >>>> Yes, because ultimately we use safe work which:
> >>>>
> >>>>    * Schedules the function @func for execution on the vCPU @cpu
> >>>> asynchronously,
> >>>>    * while all other vCPUs are sleeping.
> >>>>
> >>>
> >>> So I've done this in the latest blitz branch. I encountered one
> gotcha. I
> >>> replaced it in the one place, but that didn't work too well. I finally
> >>> tracked down the issue: I had implemented the change in only one place
> >>> instead of the three required locations. I also had to bring the
> >>> begin_parallel_context() function over from linux-user. I like
> >>> user-internal.h that's in linux user. What is your touchstone for
> >> deciding
> >>> where that code belongs in it? I'd like to do the same in bsd-user once
> >> my
> >>> upstream focus shift to refinement of blitz and maybe my next cool
> thing
> >>> there.
> >>
> >> All common code should go under common-user/ and include/user/.
> >>
> >
> > Great! I look forward to growing this directory.. But I was trying to
> ask a
> > slightly
> > different question: What belongs in user-internal.h? What's the current
> > rubric
> > for linux-user in that regard?
>
> We try to have cross-subsystem APIs exposed in include/. When we need to
> share some structure / method only within a single subsystem, we do not
> expose the prototype via include/ and add a local header.
>
> So linux-user/linux-user-internal.h should only contains things to share
> within linux-user/, and not related to bsd-user.
>

It's slightly related to bsd-user since my intention was to create a
bsd-user/user-internal.h since I liked the design. So I was curious what
linux-user's process for deciding where to put different things since
there's
several include files now. I understand the qemu.h being too wide a net and
wanting to limit what's in there (bsd-user has a decade of refactoring to
catch
up with there). I'm trying to understand the choices linux-user has made to
use
them as a baseline for future bsd-user refactoring. The things that are in
there
now don't seem to have an obvious unifying thread to them. Is this
documented
somewhere, or just in the different commits for the files?

Warner

Reply via email to