Add generated files to the clean list.

love it. And thanks for the different commits... I 100% agree with phab being a pita to setup review chains.

In D26912#600288, @mckusick wrote:

I could see a use for at least three levels of priority: low priority (default) for asynchronous I/O, mid-level priority for synchronous reads, high priority for synchronous writes.

Doh! missed the 'static' here. Removed in a followup commit.

Modulo the blank line thing, this looks good. It's arguably two different commits, but it's so small splitting it further at this stage likely has little benefit.

I think #2 is the best option. I've created https://github.com/freebsd/calendar-data (default branch is presently data, trying to get it fixed to main, but there's also a main branch w/o the removal commit).

Interesting. I have patches to iosched that marks metadata requests and topqueues them, but doesn't try to prioritize in the drive. It doesn't handle writes, though (we don't need them, but it's one of the reasons I've not conmitted)... it gives a modest boost to open latency, but not as much as the async open chuck is working on.

Sorry it took me a day (long story, unrelated to this task), but I have a repo:

Looks great...

I can extract history here too, if you want

I booted this on my emag:
CPU 1: APM eMAG 8180 r3p2 affinity: 0 1
and it seems to fix the issues that I had with cd sometimes detecting, other times not, as well as some weird reliability stuff relating to /etc/rc running at boot reliably.
I also had a weird issue where I'd type 'sudo reboot' and it would echo back 'sudo rebeoot' sometimes.
Not super extensive, but it's definitely not worse and preliminary indications are that it's better (though I'll admit to a smaller sample size with the patch than testing to produce the litany of horrors I've recounted).

Try adding literally any other device or option that will move code around

I have a eMAG 8180 based system

Something else is going on...

I was going to ask why you didn't do this for the err* functions too... Then realized it was probably time for me to knock off for the day if I had that question :)

This is good... only caveat is that MFC code near this stuff might be a pain... A minor inconvenience at best, so this is a LGTM!

Yea, getdev has gotten out of hand... It has all of ATA IDENTIFY, SCSI INQUIRY and MMC data...

Why do we need the changer device for the cd to show up? More details than 'for usb' are needed here to connect the dots one to another for others in a similar situation. 'for usb to work' provides no context and is quite surprising based on my storage and usb experience.

seems legit. There's no includes/spl and module/spl has no .h files in it

I'm out and about today... but I've done this as well and other CAM structures to boot. Let's coordinate.

There is a question about whether we should keep firewire at all, but in the mean time this is good.

Agree with mav on both points. This looks low risk and correct

In D26818#598049, @kib wrote:

In D26818#598018, @imp wrote:

In D26818#597997, @kib wrote:

In fact having gnuc-isms clearly marked is a useful feature.

Everything in this file is a gnu ism... no?

No, I do not view it this way. First, there is enough stuff not related to GNU C extensions. Starting from the compat shims for c89 or even K&R (but some stuff like static assert or array sizing in args, is really for c99), POSIX/XSI/BSD visibility macros, ending in thread-local shims etc that do not require gnu-isms.

One nit on the comments, otherwise it's fine. Fix that and I'm good with what you commit (so I'm accepting it now). I'm a little worried about the DEV_ACPI ifdef, but it's likely fine... I suspect we'll have at least one module not built properly, or built independently of the tree that has issues, but we can look into those when that happens.

I've had good luck running this for 2 or 3 firmware cycles now at Netflix... We're down 3/4 in panics, and at least part of the remaining 1/4 appear to be due to a small mismerge of two files so they were out of sync with the rest of the state machine....

In D26818#597997, @kib wrote:

The bigger part of !GNUC support is in machine/atomic.h.

In D26819#597855, @rpokala wrote:

cdefs: require gcc 4.2

... or later! 😉

seems legit

I think that it would be better to use the nmreq_foreeach_option macro in these locations. It looks like it would expand to the same thing and future proof things a little better...

You're going to need a lot more than 'fix compilation' for these patchs. Why do you need it? It super uglifies the code for no benefit.

oldest is always front of queue, use this observation to make deadline more robust.

Looks good to me. Beats using sbuf since it is more portable

One more nit before upstreaming. Down to 2 defines in the shim.

update with matt's suggestion

There's many races here around frozen queues, and I'll wager it's best to check the race is lost in the sim like this rather than introduce a new lock that would contend.

I don't suppose you have a good test case that triggers the underling issue, do you?

rebase, and some last second refinement.

update atomic.h to fully neutered for STANDALONE version, save for
atomic_add_uint64

Rebase and rework after comments from the OpenZFS upstreaming
to reduce diffs in upstream files. I was able to flesh out
the _STANDALONE support in the spl for FreeBSD instead of
some surgery in upstream files.

In the fullness of time, we may want to be pickier about this, but at the moment I see no benefit from that beyond knowing !=.

In D26723#595721, @freqlabs wrote:

I think this should be in a BUGS section

comitted as r366508