update comment again

update comment per jhb

chase member rename

In D21775#479697, @bdrewery wrote:

Can lua not continue a string on the next line?

Note that the types are the same size on LP64 archs. This breaks the ABI on ILP32.

Of course, totally identical devices (down to serial numbers) can still cause confusion.

My use case for something like this is a USB-serial console server where I might have 16 different USB-serial adapters attached to various USB hubs; I intended to address it by using the serial number in each device.

I'm mostly in favor of the change (smaller kernel size, etc.), but since we are removing driver from GENERIC, it's better if we can provide a mechanism to load the driver on demand, or a binary update can easily brick the system...

looks ok to me

Drop min and make the test >= PATH_MAX. As the sysctl passes the string excluding the NUL req->newlen equal to PATH_MAX is too long.

Correct per @kib

Ah, I probably just grepped in sys/kern. I'll take a look at a patch for nfs_nfsdport.c in a bit - it's not so straightforward.

@kib pointed out on IRC that the original PATH_MAX + 1 is incorrect but arguably innocent and I agree, but think it is worth the change to avoid confusing folks (who find that code) into wondering if PATH_MAX includes space for the NUL or not - that's what prompted me to look at this in the first place.

I wonder if it's worth committing all but actually switching amd64 to KLD_SHARED, then making that change separately.

Just abandon it then I guess?

It may be that the right approach is to just have elfcopy/strip fail on such broken input and we should just drop this patch.

Actually set alignment in output

What do we do with this change?

Previously we checked for only BINUTILS_BOOTSTRAP as a broken option and suggested installing the binutils package. This was originally done for arm64 where we used the in-tree Clang and external binutils package. Extend the warning to suggest instead the full xtoolchain package if we have no in-tree compiler either.

Ouch, command substitution in syscalls.conf

(of course the message is only valid after D20575)

This one actually does have public distfiles and ongoing development (and maybe upstream does not use sys/dir.h any longer), but I think someone would have to take maintainership to restore it.

looks good

We need to figure out how to get all of this upstream as well.

I would suggest describing this plan on freebsd-net@ and freebsd-arch@ mailing lists

And mbuf.9 change along with mbuf.h.

Ugly, but amazing. I would suggest committing the macro change first followed by the refactoring.