5 ms·
What modifications would you make that might be useful? The (proprietary) hardware isn't going to change.
by tom_ 6y ago
What modifications would you make that might be useful? The (proprietary) hardware isn't going to change.
- dmurray 6y agoRemove some bugs, or improve its performance. Hardware drivers get updated all the time even when the hardware remains the same. I'm not an open-source absolutist: I think the pragmatic solution Linux went with is good here. But it's silly to suggest that the driver couldn't be improved if it were more open.
- akvadrako 6y agoThe topic is not the driver - it’s the definition of the lowest level hardware interface. It’s lists of registers and stuff like that; not things that can really be fixed by external devs.
- ptx 6y agoIf the generated code is a representation of certain unchangeable data about the hardware, you might still want to 1) represent it more compactly; 2) represent it in a form that can more easily be read and transformed to handle future use-cases for the data; 3) after some future restructuring of the driver, represent the data in a form that better fits with that structure. If you have to regenerate the code using the proprietary tool in order to restructure the driver, the generated code is not "the preferred form of the work for making modifications".
- tom_ 6y agoAll you're going to end up doing is changing the names. And for that, in my view, a big long list of defines (or whatever), autogenerated or not, is as good a form of the work as any other. And, besides, there is an excellent chance that you will never end up changing the names.
- admax88q 6y agoYou might want to port it to a new language, in which case having the hardware description and a generator tool is easier and better than converting the C headers. And yeah sure pragmatically it might not make much of a difference in this specific case, but if the AMD devs were to port their driver to a new language they wouldn't edit the C headers they would certainly just update their generator, so the preferred form for modification is clearly not the generated C headers. Not to mention if all you wanted to do was change the names, maybe prefix them with something, editing the generator is _still_ clearly the preferred format for making that change.
- andromeduck 6y agoYou fundamentally can't because the defining code is usually hard core proprietary or a proprietary toolchain artifact from cadence/synopsis. We're talking like a memory map of the entire system or 1MB+ XML blobs. Honestly lifting it from a header file manually is going to be easier for everyone.
- admax88q 6y agoWhat do you think AMD would do if they decided to port their driver to a new language? Would they update their generator or would they copy and edit the existing header? They sure as shit didn't type out these header files by hand, so clearly these are not the "preferred form" for modification.
- tom_ 6y agoBut the GPL applies to the driver they released, not some hypothetical driver that you or somebody else might create in the future. You're already going to have to rewrite it all in this proposed alternative language... this header is the least of your worries. Strikes me that AMD have supplied everything required: all the driver code in the preferred form for modification of the driver, i.e., a bunch of C files. Some of these C files are a big long list of slightly opaque magic number defines that relate to the hardware, perhaps generated by some unreleased tool, who can say - it's all speculation at this point - but that's OK! The hardware is not the bit you're going to modify. As far as the people modifying the drivers are concerned, those numbers are never going to change. This portion of the driver is fixed.