NVIDIA Transitioning To Official, Open-Source Linux GPU Kernel Driver

[oiaohm]

Again, your message is so full of inaccuracies and things you wanna think are true but they aren't not, I don't want to continue this conversation any longer.

https://kernel-recipes.org/en/2019/t...-live-the-cve/
You need to watch this video because you are keep on with inaccuracies.

• What was the last time you visited https://github.com/lm-sensors/lm-sensors ? Suprise, the project is essentially dead, bugs linger for years, there's zero active development.
• What was the last time you checked commits in https://git.kernel.org/pub/scm/linux.../drivers/hwmon ? Likewise, some commits here and there, overall quite a bleak picture.
• What is the source of "Hardware sensors we are seeing more released and with specifications these days and included in the mainline kernel"? Your imagination?
• The existing hw sensor drivers continue to show sensors without names and without any proper formulas.
• AMD and Intel continue to release fucking nothing in terms of properly supporting a ton of MSR registers responsible for various hardware states.
• What was the last time you ran HWiNFO64 and compared to what lm-sensors provide?

The f*k it matters that old deprecated versions of HWiNFO64 don't work in Windows 11 when the app is compatible with all Windows versions starting from 95: https://www.hwinfo.com/about-software/ which is basically unheard of in Linux? Show me a single serious GUI application which works in Fedora 36 and RedHat 5.0 from 1996 out of the box without using hacks, tricks, chroots, VM, etc.? No, nothing?

This is stack of false arguments based on a stack of incorrect information. lm-sensors and hwmon should be compared to what Windows provides out the box not to HWINFO64. Yes what windows provides is not good either we need Intel and AMD and others todo better everywhere.

https://git.kernel.org/pub/scm/linux.../drivers/hwmon checking commits is really easy and hwmon is not dead and if you had you would not have not questions my statement on stuff being added from specifications at a higher rate than it use to be. I agree not developing as fast as I would like does not make my statement false.

You overlook that the version of HWINFO64 that works on Windows 10 release does not work after the 2 year kernel update then release after that update does not work after future updates this comes a repeating pattern. Yes HWINFO64 supports lot of versions of Windows but HWINFO64 deprecating lots of versions because it has a Windows Kernel driver and Microsoft is changing the driver ABI lot often than people claim. So like or not the program HWINFO64 is in fact example of Windows unstable kernel ABI and it compatible with multi versions of Windows due to the developers effort not Microsoft providing a stable kernel ABI.. Also find alternative to HWINFO64 on Windows once you attempt that you will find out that its odd on Windows as well the alternatives don't make a kernel space driver because it hard work and don't provide the same detail.

HWINFO64 is commonly updating it driver to support newer versions of windows as the Windows driver ABI changes and breaks the driver. This arguement that I cannot use tricks to allow old applications to work would be basically equal to say run old windows applications on Windows 11 with SXS removed right. SXS is mostly a userspace feature without Windows does not support applications as much..

Linux will continue to be nothing on the desktop until someone realizes that ISVs and IHVs absolutely require stable API/ABI. There are no ifs and whats, period. That's the fact of life, that's how the software industry has operated for the past three decades. No amount of preaching about the "advantages" of the open source development model will change that.

No this requires you to admit the facts. Stable kernel driver ABI really don't exist on Windows, Linux, Mac OS.... Only appears to work due to IHV, ISV effort. So that different parties require a stable driver ABI don't add up. Birdie there are somethings not matter how much you like cannot properly be done.

The old microkernel idea where the drivers are a different ring/memory space to core kernel are the only cases where you find functional stable kernel driver ABI. Yes this is exactly like Linux kernel cuse fuse, UIO drivers even this is not perfect. Why is this because in reality when you load module/driver into kernel space directly it can interface with what ever by direct memory actions this leads to a problem.

Linux kernel include modversion because at one point the Linux kernel developers did attempt to have a stable kernel driver ABI and I mean serous-ally attempt.. There has been dispute between Linus Torvalds and Linux Distributions over modversion. Linus Torvalds is correct that modversions does not pick up all the defects a kernel driver could have. modversion is designed to version the imported symbols into module to hopefully pickup when those have changed to prevent crashing system.

Is there any different solutions yes there is Solaris one is interesting their compiler linker supports relinking so you have a kernel module for one version of the Solaris kernel you need it to work in a different version you take the module file and link a wrapper object file to that kernel module and now hopefully it should work. Yes this also gave Solaris the interesting option of taking kernel module driver and converting it into a usermode driver in cases you have driver accessing changed structures.. Reality here this that Solaris had done is basically the kernel module/driver equal of Microsoft SXS.

Lastly, open source et al, why do unsupported device drivers get dropped from the Linux kernel? How does that coincide with "Release specs, we'll write drivers and it'll be all good?" That's always been a bloody lie. 99% of contributions to the Linux kernel are made by large corporations which only care about their own use cases, software and devices.

The reality here drivers are commonly removed from the Linux kernel because there is no one with the hardware to test that the updates to the driver works any more and that is after normally 2 years of that being the case. So the driver is technically bit rotted in that case. Yes this does show up because hardware that has software emulation on vm or boch or something else remain being supported because those drivers still can be tested.

Releasing the specs helps, Releasing emulator for the hardware also helps.

birdie the reality nothing you have show proves a stable ABI for driver exist https://kernel-recipes.org/en/2019/t...-live-the-cve/ this presentation shows you that does not exist from RHEL because it details how RHEL brakes it stable ABI promise legally(not morally) and also explains what happens with Android and other items. This issues causing HWINFO64 and Nvidia and all other parties using drivers on Windows to update their drivers show stable driver ABI does not exist on Windows.

At some point you have to accept reality. Stable driver ABI in anything other than microkernel designed OS cannot exist because security faults and other things will require you to change the structures inside kernel space so breaking that Stable driver ABI. Problem here is that inside kernel space drivers can use direct pointers to structures so your ABI is very large very complex and really simple to break even a different in compiler can do. A intel developer at one point did experiment with running linux kernel drivers in individual virtual machines. You have Solaris that did relinking. Solaris with relinking has 30+ year old binary solaris drivers still working on current day Solaris. Remember Solaris is not using stable driver ABI they are using wrappers to convert old ABI to new ABI and where required to move driver out of kernel space so that kernel structures presented to driver can be faked.

Yes SXS under windows using manfests and wrapper DLL is fairly much doing the same thing as how Solaris got it to work. Not have stable ABI at all but have a system to provide wrappers so something can use old deprecated ABI yet work anyhow.

birdie what you are asking for basically does not work with the test of time. Its about time you pull your head out the sand and have look around at reality. Stable ABI mostly does not exist. Where it appear to exist and function well someone is normally working very hard with wrappers or rebuilding stuff.

The hard point birdie if you want driver to keep on remaining work no matter what you most likely not what a stable driver ABI instead want a Solaris driver relinking system as this allows old drivers to be updated and put into compatibility modes.

Same with wanting stable ABI for applications in user space you mostly don't want that instead you want something like Microsoft SXS that is a stack of wrappers so newer applications can use newer ABI and gain performance advantages.

Stable ABI requests in most cases like it or not are asking for the wrong thing.