Posts
343Following
95Followers
3690
repeated
Thorsten Leemhuis (acct. 1/4)
kernellogger@fosstodon.org
🥳 "'We are almost at the "write a real driver in #rust" stage now, depending on what you want to do."' 🥳
That's what @gregkh wrote in the comment for the main driver core and debugfs updates merged for #Linux 6.14, as it contained "driver core rust bindings for PCI, platform, OF, and some i/o functions"; there is also a "misc device rust bindings and a sample driver to show how to use them":
https://git.kernel.org/torvalds/c/2ab002c755bfa88777e3f2db884d531f3010736c
#LinuxKernel #kernel #rustlang
2
10
2
Greg K-H
gregkh
2
1
18
repeated
Gustavo A. R. Silva 
gustavoars@fosstodon.org
I presented at Everything Open @everythingopen this afternoon. 🗣️🐧
My slides are already available for anyone who'd like to check them out.
Thanks for having me - I really enjoyed the session! 🙂 ✌🏽
https://embeddedor.com/slides/2025/eo/eo2025.pdf
0
3
0
1
0
1
1
0
1
Greg K-H
gregkh
1
0
3
repeated
daniel:// stenberg://
bagder@mastodon.socialThe short summary of if it has been worth the hassle: yeah I think so. It is now easy and fast to get new CVE IDs. We have a seat at a table where I can complain loudly on the system and what I say actually might have a (small) impact.
We have yet to deny someone else's crazy CVE attempts against curl.
2
3
0
repeated
daniel:// stenberg://
bagder@mastodon.social#curl has been a CNA for a year now https://daniel.haxx.se/blog/2024/01/16/curl-is-a-cna/
2
2
0
Greg K-H
gregkh
0
0
3
1
0
0
They might have a specific PCI driver bound to them, at the function level, and if so, the parent of the device node for that class device (i.e. input, tty, drm, etc.) will then point to that PCI function. But PCI slots don't always match up to PCI bus and device numbers either, as that's a physical thing and many PCI systems don't expose or even know that information (i.e. the BIOS doesn't know.)
Also, PCI bus numbers can change at boot, so you can't know what is happening.
Driver probing can be deferred at any time by userspace for USB devices, and I think that was recently added for PCI devices too, look for the "trusted" device information in the documentation somewhere.
Good luck!
1
0
0
You have full control over device node creation in userspace, that's what udev gives you if you want (or any udev-like program). set up a whole different /dev/ with just your naming/numbering scheme. The kernel gives you the interface and the information to do this, why not take advantage of it if you need it?
1
0
0
But yes, the race condition of "parse the topology, determine the device node, and go to open it" when the device is removed and a different one added right between those last two steps is real. Luckily in real-hardware situations, almost extremely rare if not physically impossible due to hardware debounce times, and one that we explicitly did not care about when we created sysfs and udev (i.e. physical access trumps anything).
1
0
0
Greg K-H
gregkh
6
2
10
Greg K-H
gregkhThat machine that randomly reassigned PCI ids at boot time is no longer with me, but it was great for testing. I'm sure you can do the same with virtual machines these days, passing in different virtual pci devices to them.
Persistent naming is for userspace to handle, the kernel just uses "grab the next free number" as it's naming "policy" as that's all it can really do.
2
0
3
repeated
