In D55912#1280104, @gallatin wrote:

In D55912#1279758, @kib wrote:

Why not simply not allocate the new number for the new ioctl. Rename current ioctl to something like SIOCGI2C_NOBANK. Then, at the ioctl level, do two things:

• for new SIOCGI2C check that reserved bytes in the structure are zero
• for SIOCGI2C_NOBANK, zero bank/page/padding and call into SIOCGI2C

I think I'd rather go the other direction, so as to avoid touching legacy ioctl users from ports. It turns out there are many from the ports sweep.

Eg, we add SIOCGI2CPB (where PB means page/bank) for new code. Drivers like mlx5 which can support page and/or bank access add a fallthru to SIOCGI2CPB to their SIOCGI2C case and zero page & bank for SIOCGI2C. Eg:

	case SIOCGI2C:
	case SIOCGI2CPB:
		ifr = (struct ifreq *)data;

		/*
		 * Copy from the user-space address ifr_data to the
		 * kernel-space address i2c
		 */
		error = copyin(ifr_data_get_ptr(ifr), &i2c, sizeof(i2c));
		if (error)
			break;

		/* Esnure page & bank are zero for legacy SIOCGI2C ioctl */
		if (command == SIOCGI2C) {
			i2c.page = i2c.bank = 0;
		}

LGTM
Phabricator won't let me accept behalf of myself.

@jhb I think I've fixed this now, with a new io_valid field in D56006 being used to mark intpins as being invalid (and forcibly masked) due to having unsupported destinations.

Use io_valid

Use io_valid

Good to get the consistency.

Good to update the manual page.

XENHVM upcall IPI handler

This should be functionally complete with the one minor missed XEN ipi handler code.

In D55999#1280819, @mckusick wrote:

Not clear that soft updates and GEOM will not work at cross purposes with each other..

grammar

correct date

update manual page

Looks good. Not clear that soft updates and GEOM will not work at cross purposes with each other..

This is still in the design stage, so I haven't:

• made the changes needed for editors/emacs
• made the changes needed to most USES=emacs ports

Use == 0 to check flags.

@jrm last time you generated the plist for me, but I don't remember how you got everything picked up correctly. Can you help?

@sunpoet : I'm proposing this update because the issue I ran into in https://github.com/pypa/pipx/issues/1718 is resolved in a newer version of the tool. I don't mind if you take care of the update in ports.
It doesn't look like this port is consumed in-tree, except by sysutils/duplicity .

In D55978#1280739, @ivy wrote:

the described behaviour seems like clearly a bug in pkg. from the pkgbase side, i don't mind this change as a workaround, but i wonder what the correct fix is here; do we want a separate package for 32-bit clang, like clang-lib32? clibs-lib32 is 3MB, which is relatively tiny compared to clang itself, but i think i'd prefer not to have any mandatory dependencies from native packages to compat packages - you should be able to completely ignore compat if you don't want it.

the described behaviour seems like clearly a bug in pkg. from the pkgbase side, i don't mind this change as a workaround, but i wonder what the correct fix is here; do we want a separate package for 32-bit clang, like clang-lib32? clibs-lib32 is 3MB, which is relatively tiny compared to clang itself, but i think i'd prefer not to have any mandatory dependencies from native packages to compat packages - you should be able to completely ignore compat if you don't want it.

After more investigation: The culprit here is libclang_rt.asan-i386.so which is landing in FreeBSD-clang and creating the dependency on 32-bit libraries.

rebase