Fix jim's issues.

This has been committed..

This looks good to me as well...

This looks good to my naive eye.

In D17686#378101, @0mp wrote:

Thanks for your reviews!

BTW, @imp & @bcr, should I MFC this one?

The USB_PNP_HOST_INFO part looks good to me.

This will fix the build. I'll look into the unused crc32 and sort out what can/should be common here after this commit.

In D17654#377405, @rgrimes wrote:

In D17654#377395, @imp wrote:

I'll point out that https://github.com/freebsd is under FreeBSD Project control, for the most part. It's a risk, but this code likely has a limited enough time horizon to accept that limitation until someone can create a fcp.freebsd.org redirector.

Eg, it's not important enough to gate this commit for that.

The projects current and official one source of truth is svn, and forcing anyone to have to use git for anything to do with the project is fundementally wrong at this point in time. I probably would of landed, what is it, a pull request?, to make changes to both the FCP process definition documents, and FCP-101 had it been done in svn.

I'll point out that https://github.com/freebsd is under FreeBSD Project control, for the most part. It's a risk, but this code likely has a limited enough time horizon to accept that limitation until someone can create a fcp.freebsd.org redirector.

Generally, this looks good.
If you still have a CardBus laptop, that's a good way to get sharable interrupts, though we do the insanely conservative thing of 'detach/attach' across a suspend to avoid issues like this. The early suspend/resume code for PCI devices was also... somewhat lacking...

I generally like the latest version...
Modulo my one question about divide by zero.

So why the special case for vgapci0?

I'll look more closely at the code, but the first thing that stands out is that this driver lacks a basic man page.

I have no clue what this is trying to fix.
I am aware of a bug that we need to read all the files in the path (which part of this does), but the special case for vgapci0 seems unwarranted and dangerous.
So there's some relevance to this, but I have some concerns.

Turns out I had one of these in one of my tree I hadn't committed. It was substantially similar to yours, it turns out so I just deleted my copy.

I'm no Kirk or Jeff, but both of these fixes look good to my eyes.

The flex man page suggests there's a performance improvement if we use -CF or -Cf as well. -CFr or -Cfr may also be beneficial since it beneficial. The man page warns against increased size, but I doubt the differences that were important when flex was written (1995) are relevant today. If we're looking at performance tuning, we should look here.

Is there any way to know you've got them all?

Love the deduplication of code.
No clue if it will work :)

Seems reasonable to me. The old description looks to not be quite right and this fixes it.

There's no doc freeze. There's no need as the rate of change for the docs is so small, and the ability to undo an oops is significantly easier.

Just commit it. He's had his chance to object. There are no hard locks on the doc tree.

I'd strongly advise adding DESTDIR support for certctl...

Note: I've not reviewed the shell script itself...

My quick eyeball doesn't detect any issues. however, I'll look at the distribute issues.

and s/live/like/ in my last comments :)

Despite my numerous nit-picks, I love this port. It's a little light on the 'why' and a few comments will fix that.

This looks great to me. A tiny bit more memory usage for the strings, but that's small potatoes.

perfect

seems good to me from a content perspective.