Thank you Maxim for the review
Active Repositories
Recent Activity
Today
Please see: D56118.
In D55857#1283609, @kib wrote:In D55857#1283607, @cperciva wrote:So... it's not an easy fix and definitely not an API change I can make quickly, and I don't want to hold up "better" just because we can't do "perfect" yet.
Sometimes even a promise would do.
In D55857#1283607, @cperciva wrote:In D55857#1283545, @kib wrote:I still think that the error should somehow propagate up. With this series, the device is malfunctioning, with the only hint about the reason being the single cryptic line in the dmesg, which is not even attributed cleanly to the device.
It is better to fail the driver attach in this case than to offer such failure mode.I agree in theory, but a lot of functions would need to change from (void) to (int) to do this. And there's some weird cases like what should ioapic_resume do if one of its ioapic_program_intpin calls fails. (Also, we need to program the interrupt to go nowhere rather than returning without programming it -- otherwise if an interrupt is being *re*programmed we get a panic when interrupts keep arriving at a CPU which no longer knows what to do with them.)
So... it's not an easy fix and definitely not an API change I can make quickly, and I don't want to hold up "better" just because we can't do "perfect" yet.
In D55857#1283545, @kib wrote:I still think that the error should somehow propagate up. With this series, the device is malfunctioning, with the only hint about the reason being the single cryptic line in the dmesg, which is not even attributed cleanly to the device.
It is better to fail the driver attach in this case than to offer such failure mode.
Print intpin when warning about unsupporting APIC IDs
Fix a few build issues
- Fail attach if unit > 0
- Change device description