4 ms·
The funny thing is, had they followed some of the subclassing practices already in the kernel, it sounds like they could have had cleaner, more easily testable
by chris_wot 10y ago
The funny thing is, had they followed some of the subclassing practices already in the kernel, it sounds like they could have had cleaner, more easily testable code with what from what I can tell tends to giv them a pretty unified interface.
The belie, however, is an appalling response really:
I realize you care about code quality and style, but do you care about stable functionality? Would you really merge a bunch of huge cleanups that would potentially break tons of stuff in subtle ways because coding style is that important? I'm done with that myself. I've merged too many half-baked cleanups and new features in the past and ended up spending way more time fixing them than I would have otherwise for relatively little gain. The hw is just too complicated these days. At some point people what support for the hw they have and they want it to work. If code trumps all, then why do we have staging?
Wut? If you want stable functionality, then you follow the kernel conventions, practices and coding styles.
This whole screed equates to: "We've got some code we've put together in our silo, you amateurs who want perfection are wrong and our unified layers and push to get our processors to market mean you can't comment on our code."
The bit about cleanups makes little sense to me, they seem to have some fundamental issues baked into their code that will necessitate these very cleanups...
- mcpherrinm 10y agoI think the argument here is that stability is gained from having code shared as closely as possible with the Windows codebase, which is where most of the QA work happens, and what the real experts debugging their ASICs use. From a hardware and driver development standpoint, I think that makes a decent amount of sense. Hardware is often weird and quirky, so making sure you handle all the edge cases in two different codebases is a lot harder than doing it once. Certainly too much work for a handful of people who just want to plug their code into Linux. Stability here is on the driver/hardware interaction, not the kernel/driver boundary, which is what the kernel folks seem to care about, naturally.
- chris_wot 10y agoStability for whom? Trying to contort Linux code to follow the practices that work well for Windows does not strike me as either maintainable, or even particularly stable!
- Certhas 10y agoWhat does this have to do with Windows vs Linux? It's about closely working with hardware engineers.
- chris_wot 10y ago"I think the argument here is that stability is gained from having code shared as closely as possible with the Windows codebase". HTH.
- brainfire 10y agoYou have to read the rest of the comment too. "HTH"
- chris_wot 10y agoIndeed, I did which you seem to have thought I didn't read. So, do you think that bunging in code designed for Windows, which specifically uses a HAL, into Linux, which tries its best not to with the philosophy that the code that goes into Linux should be as clear as possible with as small an abstraction layer as possible is good for Linux, or any of the hundreds of developers or companies relying on the maintainers to keep to this coding and architecture style? I think not. So no, it didn't help.
- __s 10y agoFlipside being that if AMD drivers are developed in the open with proper convention then kernel developers will help maintain them, alleviating cost for AMD. If AMD doesn't want the public maintaining their open source driver then they don't want their driver in the kernel