Horton
Menu

Re: GNU/Hurd portability patches

Samuel Thibault <samuel.thibault@gnu.org>

View thread
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
Date: 2025-11-21T00:54:29Z
Lists: pgsql-hackers 
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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add minimal sleep to stats isolation test functions.

  2. Include pg_test_timing's full output in the TAP test log.

  3. Make sure IOV_MAX is defined.

  4. Make safeguard against incorrect flags for fsync more portable.