bug-hurd
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]