This looks good to me. It's the right thing to do.
Do we need to expand it more generally (in a different commit) for any time we have to copy data out, or is the I/O path good?

one quick Q. if you know the windows versions, document it in the comment. the code is good to go. If you know, update the comment. If you don't know, that's cool too. either way, I no need to do a round trip through the review. you can just tweak that and commit.

jhb specifically asked me not to do this driver. Please be sure to get sign off from him.

I'd be happier if we copied usbdevs.awk to sdiodevs.awk.
I'll take a closer look next week when I'm back in the office.

I'd be happier if we copied usbdevs.awk to sdiodevs.awk.

These are good changes, though the conf/files and kern.post.mk fragments seem a separate thing...

generally, I'm happy. Once minor nit that you can do or not as you see fit.

I think this looks good, but I've not studied it in enough detail to know for sure.
It might make sense to see if Scott or Ken has a chance to look into this to be sure it's the right solution.

My mistake... 386bsd booted from a file named /386bsd. FreeBSD changed that early on to be /kernel.

Current default was set before 1996, when "/kernel" was the
actual path I guess.

Defaults should match defaults. If we don't know, guess the default FFS.

derp... I missed you did both...

Does MPR need a similar fix?

You might want to take a look at tools/boot/rootgen.sh. It's as shell script I use to generate about 24 or 32 different images to test all the different ways you can boot. It also generates a bunch of different scripts to do the qemu testing that likely could be leveraged to provide more complete qemu coverage testing.

xref fix

another

remove more -n info

+1 on cperciva's spacing nits.

partial review.... more to come

In D19587#419445, @bz wrote:

In D19587#419396, @imp wrote:

OUI spaces aren't for randomly assigning address bits that change from boot to boot. They are for more permanent allocations according to the standards that I read a few years ago. The local administrative space is for things like random assignment of MAC addresses.

(a) the fact that we are still not preserving the "randomly generated" addresses across boot is rather a management problem we still have and not a reason not to use OUI space.

(b) bhyve, despite having a block from FreeBSD allocated, is still using the NetAPP OUI in two places, in exactly the same way this will use it for other interfaces. Same problem as (a) there (though there's actually things in place to pass them in on startup, and so does ifconfig ether exist).

(c) the locally administered space is not for random stuff, it is for a locally *administered* space, some local authority who assigns and manages; I have learnt this the hard way by sys-admins telling me off "no DHCPv4 for you", this LA MAC address was not assigned by us, before. They were actually keeping track of each locally administered address.

(d) What you are thinking of is an "unmanaged, I don't care network" where it doesn't even matter if you have conflicts with official OUI space or not. Been there; made that thinking mistake myself.

(e) Using the FreeBSD OUI, like other companies do, gives us a unique space, allows our users to rely on same EUI-48 if they want even in spaces where locally administered is not a thing and I'd hope that now that we centralise the "computation", we'd actually also grow a management part, as writing a rc snippet to save and restore them isn't that hard, we could even have notifications. That way FreeBSD "cloud" deployments or even just lots of FreeBSD machines running these interfaces and bridging them out (also for jail+vnet for example, which is not so much of a difference from say bhyve or the Fusion running on your OSX) can finally stop the admin headache.

(f) for that we should have long time ago carved out some space; if we carve it out anyway, we can as well use it.

(g) the other standards usages of OUIs (I believe NVME also uses the FreeBSD OUI somewhere; maybe that was in bhyve as well to identify the controller vendor), for config spaces, and others, for fixed, special purpose Ethernet MAC address values, exist and are equally valid; some may conflict, others don't, some could possibly even overlap, I guess, without causing any conflicts.

OUI spaces aren't for randomly assigning address bits that change from boot to boot. They are for more permanent allocations according to the standards that I read a few years ago. The local administrative space is for things like random assignment of MAC addresses.

In D19500#419197, @markj wrote:

In D19500#418483, @imp wrote:

Here's what I had come up with for a glibc compatable header. Feel free to steal any or all of this. Foundation copyright is fine.

I didn't bother to fix the namespace pollution when I did this, but I was never targeting MESA. I did this to save me from hacking a dozen places in nvme-cli. The pollution was fine for the nvme-cli.

For now I'm just trying to create a minimal header that survives an exp-run; we can always add to it.

Doh! How'd I miss that?

maybe a better example than the old arm firmware too? But this is a good change.

Here's what I had come up with for a glibc compatable header. Feel free to steal any or all of this. Foundation copyright is fine.

In D19550#418301, @jhb wrote:

I would maybe split kernel commit from date(1) commit?

In D19507#417538, @greg_unrelenting.technology wrote:

In D19507#417521, @andrew wrote:

Could you use spcr->SerialPort.AccessWidth to find this? It's set to 1 in the copy of the spcr table I have indicating byte access.

The EC2 one also shows byte access (1). Here's the table.

I'm not familiar with the details of UART hardware, but looks like regshift is something else. It's hardcoded to 2 in uart_dev_pl011 and to 0 in uart_dev_ns8250.

generally this looks good.
I'm unsure about some of the times you call printf, but it can't hurt, I guess and might help.
minor style issues that I flagged.

Added license concern, but it shouldn't be a huge deal. haven't looked at the CAM integration yet.... That will come in time.
And in case it isn't clear, I'll drive the License issue inside of core.

btw, I scrolled past the .uu files assuming they were correct.
Do we still need the uudecode dance? Though that would be a different commit

I figured that this was OK, but just checked this am and I noticed this commit.
Just wanted to say that it looks good to me too.
Thanks for driving this home @smh

While I don't know what the hardware will do if these bits aren't cleared, this looks to me to implement the solution described in the commit message.

It compiles now. Fixed a few bugs that have come up in testing,
especially with shortopts.

It's an OK workaround, but the real problem is that we're not properly interlocked elsewhere.

nvmecontrol now compiles

In D19275#412819, @jhb wrote:

I know the linkerset for commands is also ultimately my fault (I used it mfiutil and then mptutil and this looks like it was copied from there), but those should perhaps register in the same way. That is a bit harder because of the tree of lists though.