It is not a problem of UINT_MAX, it is a problem to ignore potentially correct reported value.

I think it's much less likely that a SIM will internally map UINT_MAX to a valid target than what has already been demonstrated where it'll map an errant initiator_id to a valid target.

In D23856#524669, @jbeich wrote:

In D23856#524657, @zeising wrote:

This is a bug (or missing feature) in FreeBSD 12 that posix_fallocate() doesn't work with shm_open()?

Missing feature but using posix_fallocate with shm_open is unusual compared to memfd_create.

Should we poke @kevans about merging that change to FreeBSD 12 if possible?

Existing -RELEASE that haven't reached EOL still need to be supported in ports/. Backporting memfd_create would be more useful but maybe more risky.

Example consumer without fallback:

$ alacritty
libEGL warning: DRI2: failed to authenticate
libEGL warning: MESA-LOADER: failed to open swrast (search paths /usr/local/lib/dri)

Approved then! Thank you.

In D23856#524657, @zeising wrote:

This is a bug (or missing feature) in FreeBSD 12 that posix_fallocate() doesn't work with shm_open()?

Fixed!

Would this affect xorg-server as well?
I believe you have to make the UPDATING more verbose, to explain to people more about the change. They might not be aware of libxkbcommon, or which of xf86-input-libinput and xf86-input-keyboard they use. Perhaps you can add part of pkg-message also to updating?

I also wonder if we have the same pattern of shm_open() posix_fallocate() in other places (mesa comes to mind). I haven't looked though.

Can you please explain this to me a bit more, please?
This is a bug (or missing feature) in FreeBSD 12 that posix_fallocate() doesn't work with shm_open()? Should we poke @kevans about merging that change to FreeBSD 12 if possible?
I believe that the code will call os_resize_anonyous_file(), which call posix_fallocate(), even with the call to memfd_create(), if this works on FreeBSD 13, perhaps the patch should be made conditional on that version anyway? Or am I misreading the wayland code?
Apologies for all the question, I'm just a bit confused trying to understand it all.
Thank you for debugging this!

I agree with everything you say we should do. But we are not there yet, and until that time SIMs have to keep some sort of mapping table for CAM to use. From the CAM point now all target IDs of the SCSI domain the HBA is connected to, including the initiator_id are from that mapping table. I am not sure what exactly makes no sense to you in my descrintion of how things are working for FC now and why exactly the same is not applicable to SAS to add this dirty hack?

Ping? I will commit the revised patch if there is no objection.

Looks good so far, just two more commas to add.

We would have to sweep the handbook for more such examples to either add more such notes or change the instructions to be written for /bin/sh.

Initiator ID has no meaning for SAS initiators, your comment about this function scanning targets that it should not within the domain of XPORT_SAS doesn't make sense to me. Numerical bus ID's don't even make sense within SAS topology, and at some point we need to fix all of this to use port UUIDs as the definitive identifier. We also need to fix the entire SIM API and model so that the buses are truly self-announcing and self-identifying, not this crummy hybrid we have of still pretending that the SAS transport is sequentially scanned like parallel SCSI is. But until that happens, what Andriy is proposing is a seat belt for XPORT_SAS initiator SIMs so that they don't shoot themselves in the foot due to the poor API that we've provided.

I have no objections, but it would be good to request review from some port committers.

The patch will make XPT_SCAN_TGT/XPT_SCAN_BUS to scan target they should not.

LGTM

• Slightly adjust commit message and code comment

The patch only impacts XPT_SCAN_TGT/XPT_SCAN_BUS operations that don't apply to target SIMs. Again, I see no reason not to proceed.

This change is required to add a working GENERIC-NODEBUG kernel.

I have tested this on my 12-STABLE kabylake system under sway. Previously xfce4-terminal would fault on startup, with this patch xfce4-terminal now works as expected. Thanks!

wlroots is not a direct consumer of mesa-dri. OpenGL/EGL/Vulkan/etc simply don't work without drivers as even software renderer is part of mesa-dri. This affects all mesa-libs consumers that don't have a fallback. No other port adds mesa-dri to RUN_DEPENDS.

As I have told, SAS may also work as target, we just miss respective SIM. And the code skipping the initiaror_id during scan allows to not scan own target, if we ever have non-FC targets. What is so difficult in fixing few SAS SIMs to report initiator_id out of the range of valid initiator role targets?

use <note> as suggested

in case new people come along

Yep, that's the case here - my co-op student ended up modifying the host's own /etc/fstab
I'll take a look at <note> examples.

This commit only affects the behavior of XPT_SCAN_TGT/XPT_SCAN_BUS and has no bearing on the behavior of target SIMs. It also is specific to XPORT_SAS, and has no effect on XPORT_FC. I see no reason for it not to proceed.

Anyone who's still using tcsh after all these years might recognize that export is a Bourne shell thing - but it's absolutely vital that it's documented in case new people come along.

I still have to read check_labels() carefully, but overall I think this is ok.

Looks OK in generaly but see inline comments. I've never used ccache with ports and unlikely to do so in future.

Delete old patches from wxPython30

I think it is a wrong way to go. While specific initiator ID value has sense only on parallel SCSI and loop mode FC and is obsolete these days, the idea of having some id reserved for the local HBA itself makes a lot of sense for FC now, when isp(4) driver can operate both initiator and target role same time, and the initiator id is used to represent target role periphs, while other ids are used rot initiator role. Such concepts looks totally valid to me. Even though we do not have SAS target driver (I dreamed about it for years), I don't think we should make it impossible instead of trivially fixing few drivers.

rebase

This is good enough for now. Long term the transport needs to move to auto discovery instead of active scanning.

• minor update to comments

Looks good!

Committed as part of rP527260