On Thu, Nov 29, 2018 at 09:25:14AM +0100, Gerd Hoffmann wrote:
Kevin, would you feel easier about the Int19h vector restoration if it were controlled by a new, static, config knob?
If we could do it safely that would be fine. My fear is that it introduces a regression. A new config option would be okay, but it doesn't sound like that will help, as it seems that once one narrows down the problem to a bad behaving optionrom, one could just as easily block that optionrom instead..
Well, as already mentioned, physical hardware seems to solve that with an config option to enable/disable hooking int19. Look here for example:
https://superuser.com/questions/1000339/interrupt-19-capture-bios-option
(Which effectively gives the user a tool to deal with the mess the broken development workflow created).
Right, but I wonder if it being a bios option indicates that it sometimes causes regressions. I suppose we could do the same - recapture int 19 by default and add an obscure option to disable that behavior.
Thats why I picked the path to just not allow int19 hooks. For pnp roms, non-pnp roms are still allowed to do that. And we have the option to refine the logic if needed, check whenever the pnp rom has a bev or bcv for example.
That's a good point - a PnP rom really shouldn't have hooked int19, so recapturing it should not be that bad.
Do you know, for this particular optionrom, if int19 is recaptured and the user then chooses it from the boot menu, does it continue to work?
I'm also trying to avoid a config option. Asking the user to deal with the mess isn't a good way IMHO ...
Agreed.
-Kevin