Enable cargo-wdk to package drivers using a .inf file rather than a .inx file.

[krishnakumar4a4]

Since cargo-wdk generates a new driver with a .inx file by default, the current implementation assumes that a .inx file will always be included during packaging. However, having a .inf file instead of a .inx file is also makes a driver valid for packaging and we need to support that. Also, study if stampinf is tolerant of running directly on .inf files or otherwise skip it.

[wmmc88]

@krishnakumar4a4 was there an actual customer ask for this?

I would also want to know if this is natively supported in Visual Studio when compiling C drivers, since OTTOMH stampinf is always run.

There's also things stampinf does with inx files like automatically populating WDF specific sections, arch sections, cat file section, etc. Allowing for "hardcoded" inf files runs risk of sync issues (ex. inf says its for arm64, but user accidentally built it for x64 and is confused why its not loading). I think you need pretty strong justification if you want to add this new behavior.

[krishnakumar4a4]

@krishnakumar4a4 was there an actual customer ask for this?

No, there was no specific request here. This actually came up during one of our code discussions, where we noticed that the build fails completely if there’s no INX file in the driver. We weren’t sure if that’s the expected behaviour, especially since I’ve seen multiple samples in the C sample drivers repository that use INF files instead of INX. One such example is this: https://github.com/microsoft/Windows-driver-samples/blob/main/filesys/miniFilter/MetadataManager/fmm.inf.

The original intent of the issue was to investigate and potentially support INF-based drivers, but I’ve just realised that the title and description currently suggest we’ve already decided to support them. I think I should update both to reflect the original intention more accurately.

I would also want to know if this is natively supported in Visual Studio when compiling C drivers, since OTTOMH stampinf is always run.

You're right—Visual Studio's UI doesn't seem to allow disabling the stampinf step. While Copilot suggests an alternative by modifying the .vcxproj file, it includes disclaimers explaining why skipping this step isn't recommended. Overall, it feels unnatural to skip it.

There's also things stampinf does with inx files like automatically populating WDF specific sections, arch sections, cat file section, etc. Allowing for "hardcoded" inf files runs risk of sync issues (ex. inf says its for arm64, but user accidentally built it for x64 and is confused why its not loading). I think you need pretty strong justification if you want to add this new behavior.

Yes, I have a similar understanding that INX provides templating for INF files. Since I’ve seen sample drivers with INF files, I assumed INF-based driver setups are valid and hence may have a need to support them. However, if the decision to support only drivers with INX files was intentional to avoid the potential issues you mentioned, I’m happy to close this issue. If that’s not the case, we can keep it open to explore the possibility of supporting drivers with INF files. I can update the issue title to reflect it as an investigation task and revise the description to avoid suggesting any specific solution at this stage. Let me know.

[wmmc88]

I think you should validate the assumptions / copilots assumptions and document your findings here. Then can close.