ministat graph for time savings.

Instead of padding the buffer, assert that they always fit as the specification requires
sector size to be one of 512, 1024, 2048 or 4096 bytes.

In D25531#565071, @jrtc27 wrote:

In D25531#565068, @mhorne wrote:

I've re-read the PLIC spec, the discussions here, and did some spelunking in the MI interrupt code. As far as I can see this change is correct.

I will see about getting the PLIC spec clarified in terms of the exact behaviour of claim/complete.

My remaining question is this: if the IP bit is cleared by the claim, and cannot be set again until the completion has been done for that context, then is there any reason to continue clearing/setting the enable bit for the interrupt we are servicing? Doesn't the claim/completion process provide the correct behaviour on its own?

Indeed. My assumption is it's there because that's what other PIC drivers in the tree do to deal with asynchronous interrupts, and it currently stops a constant interrupt storm, but is both inadequate to entirely stop spurious interrupts and now unnecessary.

In D25531#565068, @mhorne wrote:

I've re-read the PLIC spec, the discussions here, and did some spelunking in the MI interrupt code. As far as I can see this change is correct.

I will see about getting the PLIC spec clarified in terms of the exact behaviour of claim/complete.

My remaining question is this: if the IP bit is cleared by the claim, and cannot be set again until the completion has been done for that context, then is there any reason to continue clearing/setting the enable bit for the interrupt we are servicing? Doesn't the claim/completion process provide the correct behaviour on its own?

I've re-read the PLIC spec, the discussions here, and did some spelunking in the MI interrupt code. As far as I can see this change is correct.

Add comment explaining the second check, and cap the buffer size.

Please merge to 12 and 11.

Fixed a typo.

tested by pho

Address kib's review comments

s/i386/amd64/g as suggested by bcr@

Other then the note, I think it is fine. Indeed we did not handled non_plt_gnu_ifuncs.

In D25550#564939, @kib wrote:

Provide the amd64 example, in binary form.

• Make (struct ifconfig_sfp_status).power a pointer to an array of length (struct ifconfig_sfp_status).channels so that more than 4 channels may be supported in the future without changing the struct layout.
• Add a corresponding function to free the above allocation.
• Fix missing comments.

Generated code:

This patch is about to be submitted upstream. I just needs to run through some internal reviews first.

applied 0mp suggestions

My opinion? Implementor's "artistic license" call. :-)

applied wulf recomendations

What's the status of this? We're hitting this problem very frequently at Isilon and this patch does fix the issue.

#endif comments

In D17653#564941, @lwhsu wrote:

I think this is still useful, is there any concern of committing this to head?

Looks good to me now, although I would use amd64 in the example as i386 is going the way of the dodo. But it does not matter much for the example.