[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Update ipc/ directory to use mach_port_name_t
From: |
Samuel Thibault |
Subject: |
Re: [PATCH] Update ipc/ directory to use mach_port_name_t |
Date: |
Tue, 6 Dec 2022 02:14:21 +0100 |
User-agent: |
NeoMutt/20170609 (1.8.3) |
Flavio Cruz, le lun. 05 déc. 2022 01:31:03 -0500, a ecrit:
> On Wed, Nov 30, 2022 at 10:28:31PM +0100, Samuel Thibault wrote:
> > Flavio Cruz, le mer. 30 nov. 2022 02:14:20 -0500, a ecrit:
> > > Make it explicit where we use port names versus actual ports. For the 64
> > > bit kernel, port names and ports are of different size so this corrects
> > > the syscall arguments and internal structs to have the right size.
> >
> > Also, this makes the code more explicit as to when we have a name that
> > needs to be looked-up, or a port that can be cast.
> >
> > > This patch also uncovered several issues we need to solve to make
> > > GNUMach work well on 64 bits. First, the mach_msg call will receive 4
> > > byte port names while the kernel "thinks" they are 8 bytes, which will
> > > be a problem. Also, when we send a message, the kernel translates the
> > > port names into port pointers in the message copied from user space.
> > > This also won't work on 64 bits. In this patch, I added several TODOs to
> > > fix
> > > the issues later.
> >
> > Just to make sure: have you noticed Luca Dariz' work? (last patch series
> > sent on the list on Tue, 28 Jun 2022 12:10:39 +0200)
>
> I have just checked his patch set. "[PATCH 10/15] x86_64: expand and shrink
> messages in copy{in, out}msg routines" seems to do what is mentioned here as
> TODO since we need to expand the port fields to fit the kernel's pointer
> size. I would be happy to reimplement that but I think it might be better
> for Luca to try to merge that since that thread has seen recent activity
Yes, please, let's avoid doing work twice :)
Samuel