This article is reprinted with permission from the CSDN public account (ID: CSDNnews)
Compiled by | Tu Min
Recently, the Linux kernel community is brewing a significant change: in the upcoming Linux 6.19 version, the kernel build system may default to enabling the -fms-extensions parameter, which allows the use of Microsoft C extensions.
Kernel developers believe that this change could make code easier and more aesthetically pleasing to write, while also enhancing cross-platform compatibility. According to foreign media Phoronix, Linus Torvalds, the father of Linux, has not expressed any opposition to this change so far.
What are the “Microsoft C extensions”?
Technically, the core of this change is to unify the kernel build system by enabling the -fms-extensions compilation option.
-fms-extensions is an option supported by both GCC and Clang, used to enable some non-standard syntax of the Microsoft Visual C/C++ compiler. One of these is allowing anonymous nested types within structures (struct) or unions. For kernel developers, this means that code can be written more concisely and elegantly—potentially saving some stack space in certain scenarios.
Over the past years, there have been multiple proposals within the community to enable -fms-extensions by default, but due to adherence to standard C, concerns about portability, and differing opinions among core developers, these patches have not been adopted.
Currently, two patches enabling this feature have already been merged into the kbuild-next branch, which is responsible for the kernel build system subsystem. This indicates a more pragmatic attitude from the community—if core developers and Linus Torvalds do not oppose it, this change is likely to be officially enabled in the Linux 6.19 merge window.
Patch Details
When submitting the relevant patches, developer Rasmus Villemoes wrote in the email list with the subject “Kbuild: enable -fms-extensions“:
“Sometimes enabling -fms-extensions can make the code look more beautiful. However, every time someone proposes enabling -fms-extensions, there are always those who say, ‘You can write code without it, and it’s not that bad,’ which is not enough to justify adding a new compilation flag for this reason.
Each use case does indeed seem that way, but it’s also a ‘chicken and egg’ situation.
But as Linus said, if we grit our teeth and enable it once, then we can use it directly in the future without having to argue for examples each time.
Historical discussions can be found on lore.kernel.org:
-
https://lore.kernel.org/lkml/[email protected]/
-
https://lore.kernel.org/lkml/[email protected]/
-
https://lore.kernel.org/lkml/[email protected]/
-
https://lore.kernel.org/lkml/[email protected]/
-
https://lore.kernel.org/lkml/CAHk-=wjeZwww6Zswn6F_iZTpUihTSNKYppLqj36iQDDhfntuEw@mail.gmail.com/
Clearly, there are many more places in the code where it can be used, but it has just never been mentioned in past discussions about -fms-extensions.
https://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux.git/commit/
Another patch titled “kbuild: Add ‘-fms-extensions’ to areas with dedicated CFLAGS” ensures that this option is correctly passed even when using custom CFLAGS for specific architectures instead of the generic KBUILD_CFLAGS.
https://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux.git/commit/
So what is Linus Torvalds’ attitude towards these patches?
From his recent comments on the mailing list, Linus Torvalds does not oppose the introduction of Microsoft C extensions in Linux 6.19.
Impact on Developers
In fact, after enabling -fms-extensions, kernel developers will be able to use anonymous nested types within structures without explicit field names, making the code for multiple subsystems more concise and compact. Additionally, it will unify the build behavior of GCC and Clang, potentially simplifying cross-platform drivers and libraries, thereby reducing duplication and potential errors, and improving the readability of large codebases.
However, opinions on this latest initiative are mixed.
Some feel that this is symbolically significant, as a kernel that has long positioned itself in opposition to the Microsoft ecosystem is now officially allowing compiler behavior in the style of Visual Studio.
Supporters argue that the efficiency gains from code simplicity in performance-critical areas such as networking and file systems are worth the trade-off.
Of course, not everyone is excited about this—some developers believe that introducing “Microsoft-specific behavior” will undermine the principles that Linux has long adhered to. Others feel that “relying on non-standard features may complicate strict standard builds and increase vendor lock-in risks.”
This patch is still under observation, and ultimately, it will depend on the latest situation of the Linux 6.19 merge window.
However, if the patch passes review smoothly, then starting from Linux 6.19, the kernel will officially support C language extensions originating from Visual Studio—something that was almost unimaginable in discussions on mailing lists 15 years ago.
References:
https://www.phoronix.com/news/Linux-6.19-Patch-Would-MS-Ext
https://medium.com/@fedir_karasenko_14123/microsoft-c-extensions-are-coming-to-linux-6-19-20-years-after-the-first-proposal-a17878fc6e0b
https://news.ycombinator.com/item?id=45873625