Added device_open_new and device_open_new_request and reused the old MiG
ID for xxx_device_set_status which has not been in used in the past
decade.
Note that device_open_new is gated on defining
DEVICE_ENABLE_DEVICE_OPEN_NEW because otherwise some hurd servers
wouldn't compile anymore unless patc
On Tue, Apr 25, 2023 at 4:11 PM Samuel Thibault
wrote:
> Flavio Cruz, le mar. 25 avril 2023 00:07:46 -0400, a ecrit:
> > On Mon, Apr 17, 2023 at 11:49:46AM +0200, Samuel Thibault wrote:
> > > Is this really needed? Since rpc_time_value_t will already be 64bit on
> > > 64bit platforms.
> > >
> > >
Applied, thanks!
Flavio Cruz, le lun. 24 avril 2023 23:53:52 -0400, a ecrit:
> This brings us a bit closer to having all types' msgt_size representable
> with a single byte. We will be able to avoid mach_msg_type_long_t
> entirely for x86_64 since mach_msg_type_t can represent long types using
> a
Flavio Cruz, le mar. 25 avril 2023 00:07:46 -0400, a ecrit:
> On Mon, Apr 17, 2023 at 11:49:46AM +0200, Samuel Thibault wrote:
> > Is this really needed? Since rpc_time_value_t will already be 64bit on
> > 64bit platforms.
> >
> > (I don't hope to bring 64bit time to 32bit Hurd)
>
> time_value64_
Sergey Bugaev, le mar. 25 avril 2023 13:25:02 +0300, a ecrit:
> @@ -733,6 +734,10 @@ boolean_t thread_invoke(
>
> counter(c_thread_invoke_hits++);
> (void) spl0();
> +#ifdef __x86_64__
> + wrmsr(MSR_REG_FSBASE, new_thread->pcb->iss.fsbase);
On Tue, Apr 25, 2023 at 12:02 PM Sergey Bugaev wrote:
> subcode is the address of the fault, and 128 just so happens to be
> 0x80, and %fs:0x80 is of course tcb->reply_port. So it looks like
> fs_base was not restored to its proper value when context-switching to
> the thread, and gets instead set
Hello,
I have done some debugging and I think I know what's going on, and it
looks related to this very patch. The device_read_inband () call
actually succeeds, and glibc tries to echo the same thing back (that's
how devstream works, arguably maybe it shouldn't, but whatever); and
when it tries to
