> As the article explains, HLK testing isn't really designed for non-hardware drivers and the solutions are strange at best. You're not actually improving quali

> As the article explains, HLK testing isn't really designed for non-hardware drivers and the solutions are strange at best. You're not actually improving quality in this case, you're just making us do convoluted busywork. There's a lot common to driver development that's separate from purely interacting with hardware (memory management, filesystem interaction, security, etc), some of which the HLK covers. Plenty of non-hardware drivers are capable of bringing down the system or breaking things if they do something bad in kernel mode. To be clear, the article is complaining about their specific case in which they claim to have a driver that explicitly violates nominal filesystem invariants and "cannot" pass HLK testing, not that HLK compliance is inherently a bad fit. Whether or not a different set of tests or a negotiated "Contingency" test filter are possible is a different question.