In D56729#1300523, @guest-seuros wrote:

I think hidwacom is the better name here.

This is Wacom hardware, and it does not speak a generic "remote" protocol. It uses a Wacom-specific, undocumented HID report protocol. I decoded it from USB traffic captured against their Windows driver, and only later found that Linux already handles the same protocol in drivers/hid/wacom_wac.c under the hid-wacom driver.

If this were a published or vendor-neutral remote-control protocol, I would agree that hidremote would be a better name. But in this case, hidremote would make the driver look more generic than it really is.
The important part is not that the device is a remote, but that it is a Wacom HID device using Wacom-specific reports.

Linux also has support for multiple remotes and some additional quirks, but I cannot test those yet since I only have one ExpressKey Remote. I would rather land the tested base driver first and leave the untested multi-remote/quirk handling for future work.

Also, Wacom hardware is not limited to drawing tablets. Wacom EMR digitizers ship embedded in several laptops, including Lenovo ThinkPad X200t/X220t/X230t/Yoga models, and machines from HP, Dell, Asus, and Panasonic. Those are not drawing tablets either, but they still use Wacom-specific constants/protocol details. Samsung use it for their flagship phones and screens.

I will add the hidbus(4) xref.

In D57617#1321866, @pouria wrote:

In D57617#1321864, @ngie wrote:

Were there any RFCs that superseded the one referenced?

No, if it were, it would be mentioned, like this one:
https://datatracker.ietf.org/doc/html/rfc2460 (look for "Obsoleted by" or "Updated by")

In D57617#1321864, @ngie wrote:

Were there any RFCs that superseded the one referenced?

Some other research I just did.

In D56605#1321861, @ngie wrote:

This version of pjdfstest requires a pjdfstest user, which we currently
don't have. The current plan is for the pjdfstest package to create the
user upon installation.

What about just using the tests user in the upstream port?

% id tests
uid=977(tests) gid=977(tests) groups=977(tests)

In D56605#1321860, @ngie wrote:

Dang -- not bad. Are there any known data creation races that need to be managed in the Rust implementation? How much "tire kicking" has the Rust version gotten so far? How about A/B test code coverage from the kernel?

This version of pjdfstest requires a pjdfstest user, which we currently
don't have. The current plan is for the pjdfstest package to create the
user upon installation.

In D56605#1321856, @asomers wrote:

In D56605#1321843, @ngie wrote:

I'm sorry -- y'all are right about the 2 implementations being able to coexist. 15 seconds is really short, but that's done on an in-memory filesystem, whereas our tests are run on physical device/virtual compute (so vSphere, etc) backed devices with a WITNESS/INVARIANTS enabled kernel (runtime is ~10 minutes). I'm not sure what the kernel options were for the 15 second run, but regardless, it would probably be at least an order of magnitude longer than the runtime for the new pjdfstest implementation.

BTW, using an in-memory file system isn't the reason why markj's tests run quickly. The main reason is that rust-based pjdfstest uses shorter sleeps. sh-based pjdfstest hard-codes a bunch of one-second sleeps, but rust-based pjfstest uses a configurable sleep time. For file systems with sub-one-second timestamp granularity, we can really dial down the sleep time. For instance, just now I ran rust-based pjdfstest on a 7200 RPM HDD. It took 300ms for ZFS, and 4.3s for UFS.

@bz, @glebius, @melifaro, etc: can you help confirm that this is change is correct?

In D56605#1321843, @ngie wrote:

I'm sorry -- y'all are right about the 2 implementations being able to coexist. 15 seconds is really short, but that's done on an in-memory filesystem, whereas our tests are run on physical device/virtual compute (so vSphere, etc) backed devices with a WITNESS/INVARIANTS enabled kernel (runtime is ~10 minutes). I'm not sure what the kernel options were for the 15 second run, but regardless, it would probably be at least an order of magnitude longer than the runtime for the new pjdfstest implementation.

In D57650#1321766, @obiwac wrote:

thanks!

I'm sorry -- y'all are right about the 2 implementations being able to coexist. 15 seconds is really short, but that's done on an in-memory filesystem, whereas our tests are run on physical device/virtual compute (so vSphere, etc) backed devices with WITNESS/INVARIANTS enabled (runtime is ~10 minutes).

Made changes as suggested by kib@.

No, I just necromanced into code that was idle for 22 years. The AF_ARP case was copied from if_ethersubr.c when @dfr added if_fwsubr.c in 2004.

added feedback by makc
used make makepatch instead of diff -u
fixed portlint warnings

wait, did this change at some point?

I have patch with pet portclippy.

Upstream changed versioning:
DISTVERSION= 1282
PORTEPOCH= 1
-GH_TAGNAME= 1282

In D57644#1321745, @des wrote:

In D57644#1321744, @ziaee wrote:

Thus the fixes tag, to make sure they MFC (or not) together.

We have exactly zero tooling around the Fixes: tag. Your commit won't show up in my MFC reminders, and it won't show up in yours either unless you also add an MFC after: tag.

thanks!

last remnant of PTS

fix indentation per style(9)

fix refuse_match

In D57644#1321744, @ziaee wrote:

Thus the fixes tag, to make sure they MFC (or not) together.

In D57644#1321727, @des wrote:

-B is still recommended on 15 and 14. I intended to merge the change, but there is no consensus around that yet.

In D57647#1321696, @ziaee wrote:

we should consider finding a standard syntax like a prefix or something when theres a breaking change like Note: or maybe using asciidoctor warning boxes or something?

remove useless QT-Version check from CMakeLists.txt

-B is still recommended on 15 and 14. I intended to merge the change, but there is no consensus around that yet.

FORTIFY_UNSAFE won't be an effective hammer once the default is lifted, because it won't provide the CFLAGS that override our current bsd.sys.mk logic.

I /was/ going to do an exp-run, but I think @netchild has likely already solved all of the problems we'd see with the fortify feature work in ports. Well, one point that we may need to actually address, though: FORTIFY_UNSAFE won't be an effective hammer once the default is lifted, because it won't provide the CFLAGS that override our current bsd.sys.mk logic.

FYI, 2017 is when vgrind was disconnected from the build.