Date: Fri, 21 Nov 2025 01:54:29 +0100
From: Samuel Thibault <samuel.thibault@gnu.org>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Michael Banck <mbanck@gmx.net>, Alexander Lakhin <exclusion@gmail.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: GNU/Hurd portability patches
Message-ID: <aR-4ReXSfSl_YCfe@end>
Mail-Followup-To: Samuel Thibault <samuel.thibault@gnu.org>,
	Thomas Munro <thomas.munro@gmail.com>,
	Michael Banck <mbanck@gmx.net>,
	Alexander Lakhin <exclusion@gmail.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>,
	pgsql-hackers@lists.postgresql.org
References: <e2bf13d1-f152-4d1d-acbe-a8c4c41611fd@gmail.com>
 <CA+hUKGKo6rToAxyObEnOnOiT3QEJuJFVkVNqikw0wVFHag=3Fg@mail.gmail.com>
 <fa85e679-9d13-43ae-8882-3f50c709f446@gmail.com>
 <CA+hUKGLvrBt9bkjiHb8VOTGOsKfL6W0ik1+h0M1E5TSy1=QmJg@mail.gmail.com>
 <69125dd5.170a0220.d19df.23dcSMTPIN_ADDED_BROKEN@mx.google.com>
 <CA+hUKGKAUa7ybQ9=6ap2uh-TmHtH8wFL-DTeeh-swprg+Rf=+w@mail.gmail.com>
 <aRuwX88mdP8tfuvi@end>
 <CA+hUKGKD0EOviHPG_W5gBZ+xiRFktvn=tBebrSBf8oQDecKnwA@mail.gmail.com>
 <aR5Ic421-i4V1SPb@end>
 <CA+hUKGKYoATxDq5Gp+JxG=X2=Zk=h=ZZ3+AwHmXBE559JJChmw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CA+hUKGKYoATxDq5Gp+JxG=X2=Zk=h=ZZ3+AwHmXBE559JJChmw@mail.gmail.com>
Organization: I am not organized
Archived-At: <https://www.postgresql.org/message-id/aR-4ReXSfSl_YCfe%40end>
Precedence: bulk

Hello,

Thomas Munro, le jeu. 20 nov. 2025 17:20:57 +1300, a ecrit:
> On Thu, Nov 20, 2025 at 11:45 AM Samuel Thibault
> <samuel.thibault@gnu.org> wrote:
> > Thomas Munro, le mar. 18 nov. 2025 18:32:38 +1300, a ecrit:
> > > Does that also imply that preadv() has to loop over the vectors
> > > sending tons of messages and waiting for replies?
> >
> > Currently glibc's preadv performs copies.
> 
> Even without O_DIRECT (= potential scatter/gather DMA to/from user
> space), the kernel/server still seems like a better place to put a
> scatter/gather-with-memcpy() loop,

I'm not saying the current behavior is optimized :)

> > > (And then to get more and more pie-in-the-sky: (1) O_DIRECT is highly
> > > desirable for zero-copy DMA to/from a user space buffer pool,
> >
> > We don't currently have that defined.
> 
> . o O { Is anyone trying to put ext4 or xfs into a Hurd server? }

The idea would be to leverage the FreeBSD implementation through the
rump layer.

> > > (2) starting more than one I/O with a single context switch and likewise
> > > for consuming replies,
> >
> > That would be possible by introducing in gnumach a multi-message variant
> > of the mach_msg() system call.
> 
> . o O { If I were designing a new mach_msgs() I'd also be tempted to
> try to make it so that the messages don't have have to be copied in
> during the system call, but instead can be accessed directly by the
> receiver,

That's already what happens: for out-of-line data, mach maps-in/out the
data pages through the RPC.

Samuel