In D57545#1319810, @tuexen wrote:

I can take care of UDPLite and SCTP in a separate commit.

This has been tested in our systems that have both storage and non-storage cards and it works.
If I don't get feedback soon, I'll push this.

Finally! This picky, grumpy driver maintainer is happy. Thanks for both your patience and your rolling my feedback to make this better.
I could get extra picky about slicing this up into smaller bits, but I think Adrian or I is good-to-go to commit it. If there's a backout,
we'll slice it more finely.

Some tweaks found while auditing the result.

with jhb's suggestions, this is all him, I wonder if I should do co-authored-by: jhb, or set him to the author and add stolen-shamelessly-by: imp

per jhb

OK. I like jhb's approach.

Last one

Gemini made good readablity suggestions to my overly-verbose prose.

draft cross repo policy.

Add new file

So I think that all the editorial changes have been made. I'll wait to commit this until at least after the core 13 -> 14 handoff next week.

two minor nits. Use your judgement on resolving them. The the sbuf thing is too hard, then what's there is fine for the error case.

One last suggestion on the sqe size. I just realized we read the size from (ctrlr->cdata.sqes >> 4) & 0xf; and it's really a shift vale. we should leverage that and just shoft this number - 6 since our default SQE size is 64.

In D57483#1317295, @asomers wrote:

It occurs to me that this might be a good use case for an out-of-tree kernel driver written in Rust. It's easy to test, it's small, and it's not wanted within the tree.

update, per review
Take a stab at what is a BSD license

In D57483#1316912, @asomers wrote:

In D57483#1316905, @imp wrote:

I'll ignore the trend we've had towards retiring older-format support generally...

If you have a better idea for how to read such disks, I'm all ears. Out-of-tree kernel modules are tough to maintain. But maybe a cuse device or something? It's a possibility.

I'll ignore the trend we've had towards retiring older-format support generally...

fix format and ia32 build issues.

In D57462#1316719, @vexeduxr wrote:

Wouldn't the ia32 loader need this too?

also take a stab at ia32, no clue if it works or compiles

In D57462#1316706, @imp wrote:

In D57462#1316594, @kib wrote:

IMO the fix is to put the page table pages into staging, and get the pointer to top-level page table page from the staging area. After that, we can fill page tables.

Since we allocate the tables, we won't have a collision. Putting it in staging is trickier. Having it right after the stack works well since we replace the stack soon after we start. It's what I did for LinuxBoot and it works well there. We don't have to manage it in the modules area, etc after boot.

In D57462#1316719, @vexeduxr wrote:

Wouldn't the ia32 loader need this too?

Move printf into main code
Add commented out PageFree since we could free the memory
if boot services was still running. It might be better to
use malloc here to get the memory to get the memory map
since we could free it after boot services stops running.
The EFI loader allocates a big array of pages before starting
for routine allocations while we run.

So I'll see if I can move where we print the staging value..

In D57462#1316594, @kib wrote:

Hm, so the problem might be, instead, that extending the stage area overwrites the allocation for the page tables?

gleb's stlye thing

In D57391#1315057, @kib wrote:

Going forward, we would
like to promote the use of a single space, as it allows alignment to
survive line prefixing (such as in diffs).

I do not agree. 'We' qualifier is too broad there. BSD has the history of using the 'tab', as I understand, going back to real Bell labs Research Unix.

In D57340#1314898, @ziaee wrote:

I think the best way would be to put everything in internal/software-license.adoc or articles/license-guide/_index.adoc, and then clusteradm would use html redirect if someone tries to navigate to the other one. Then we would only have two possible documents (style.9 and the policy) to answer questions on, interpret, or maintain.

In D57340#1314896, @ziaee wrote:

Thank you so much, this is sorely needed. I would be more comfortable if we reduce the documentation proliferation by having only two places for policy (web and src) and using redirects. This is a lot better but still requires years of heroism to maintain.

I'd be tempted to double the tolerance to 1 minute. Some drives with write caching enable won't flush everything to medium so maybe the prior SB is still on the medium. We don't seem to send a BIO_FLUSH down, but this is from code inspection and maybe I missed something. One could speculate that further writes were lost, but while 30s is a long time to the drive, a few seconds might not be so you may find files on these drives past 30s by a little bit and 1 minute seems like a sensible limit to account for it.

I like this. I haven't delved into the fine details though, but it looks like adrian is, so my acceptance is conditional on making him happy.

Some final nits to simplify things a bit. Also, if you can find the size of the sqe from the identify and/or the capabilities stuff, that would be better than a quirk. Have you investigated it.

nits

Doh! Of course. Thanks!

Ah! This explains the other issue I had in a review I saw before this.

boot0cfg ${NANO_BOOT0CFG} ${NANO_WORLDDIR}/${NANO_BOOTLOADER} doesn't look right. The only bare arg to boot0cfg is the disk, right?
The other one looks good though.

C had finally outpaced the generic catch-all function... eopnotsupp, or similar, has been around since at least v4 (the first C version we have).

nodev()
{
        u.u_error = ENODEV;
}

I know this is for one of the kernel sanitizers and not strictly forced by new C behavior, but still...