Merge two if's.

Sorry, I do not understand the change.
The compilation of both in_rss.c and rss_config.c is gated by the RSS option, and this seems to not change for the whole time these files existed.

Man page update: explain that knotes for closed fds are not copied.

In D52045#1213312, @markj wrote:

This should really have some regression tests. Even some simple ones which exercise the f_copy routine for various filters, and verify that knotes for O_CLOFORK fds are handled properly, would be much better than nothing.

libuvmem(3)

In D27220#1213316, @markj wrote:

In D27220#1213306, @kib wrote:

In D27220#1213262, @markj wrote:

Looks ok to me. Perhaps this should be a private library instead?

IMO it is generally useful API. Also, I do provide symbol versioning, which does not make sense for a private library: the intent is to keep stable interfaces.

Well, now the kernel's internal interface must be kept stable as well. I don't object, but I'm worried it'll be easy for someone modifying vmem to forget about this.

Makefile formatting

In D27220#1213262, @markj wrote:

Looks ok to me. Perhaps this should be a private library instead?

Some editing to the comment.

FYI D52608 and D52628

So where are we WRT this change? If this not going to be finished soon, may be Mark' change should go in to be cherry-picked for 15.0.

Wrap the first stage of the fork pass into the original pass over source fd table.

In D27220#1212853, @bnovkov wrote:

In D27220#1212532, @kib wrote:

In D27220#1212528, @bnovkov wrote:

Hi, is there a concrete reason why this revision never landed or has it just slipped through the cracks?

I would really like to use libuvmem for one of my ongoing bhyve projects and would like to see this land, let me know if there a way I could help with that.

The intent of the libuvmem port was to use vmem allocator for bhyve to handle physical address space. That stalled, and I do not see a reason to add unused library to base.

Is there a revision with the stalled patches somewhere? I'd be interested in taking a look.

Changes due to the latest comments.

VMEM_LIST_LOCK()

Use standard way to reference libc src dir.
Silence compiler warning in _bt_fill() about flags.

Remove undefined symbols from the version script. The library should be buildable, at least.

Rebase. Use FreeBSD 16.0 symbol version for the new lib.

In D27220#1212528, @bnovkov wrote:

Hi, is there a concrete reason why this revision never landed or has it just slipped through the cracks?

I would really like to use libuvmem for one of my ongoing bhyve projects and would like to see this land, let me know if there a way I could help with that.

Man page editing

Single instruction to clear a register is basically free on modern architectures. All it does it marks the register as having zero (sometimes not writing actual zero) and eliminating dependencies on previous register value. On the other hand, adding more code means that we consume more space in the icache, there are more instructions to parse etc.

In D53026#1211786, @des wrote:

@mjg @kib do you agree that there is no reason why the userland implementation of realpath() would succeed after the syscall failed, except in the case of a race?

I intend to commit this early next week.

Bug fixes after Peter' testing.

You might hide the workaround under some sort of ifdef gcc. It would be tricky, though, since this needs to happen inside the macro.

Ask kargl@ for explicit feedback and approval of the patch.

Rename the option to 'unixbypass'.
Add documentation.

Might be bzero() whole *kvo on each iteration?

In D52983#1210802, @markj wrote:

This should be documented in mount_nullfs.8. The implementation looks ok to me.

Rebase. Document KQUEUE_CPONFORK

Might be s/compiler/gcc/

In D52939#1209577, @rlibby wrote:

There are other options for how to spell the internal macros. I'm open to something else that might be more clear. Something in particular I considered is just providing

#define _RB_OP_RVAL(elm, op, dir)	((__typeof(elm))		\
					((__uintptr_t)(elm) op (dir)))
#define	_RB_OP(elm, op, dir)	((elm) = _RB_OP_RVAL((elm), op, (dir)))
#define	_RB_OPUP(elm, field, op, dir)	_RB_OP(_RB_UP((elm), field), op, (dir))

and not _RB_{OR,XOR,ORUP,XORUP} and then having the rb code look like e.g.

			_RB_OPUP(parent, field, ^, elmdir);

instead of _RB_XORUP(parent, field, elmdir).

In D51623#1209355, @jhibbits wrote:

In D51623#1209045, @kib wrote:

It seems that you always build 4-level intermediate page table. Wouldn't it blow up if the source kernel is running in LA57 mode? [Kernel always expect LA48 on start nonetheless]

You're right. I'll need to force it down to LA48 when entering the new page table. I'll have to check on this, as I'm not familiar with configuring LA57 mode.

It seems that you always build 4-level intermediate page table. Wouldn't it blow up if the source kernel is running in LA57 mode? [Kernel always expect LA48 on start nonetheless]

Fix acq/rel description for RMW.

Yes indeed what you noted is a bug in the description of acq/rel for atomics that perform more than one memory access, basically all RWM atomics. I think just fixing that would be enough.

Thanks.