> Gesendet: Freitag, 22. März 2019 um 16:44 Uhr > Von: "Stephen Hemminger" <[email protected]> > An: "Harald Albrecht" <[email protected]> > Cc: [email protected] > Betreff: Re: [RFC 1/1] net/tun: fdinfo to relate TAP/TUN network interfaces > unambiguously with their serving processes > > The /proc formats are fixed and legacy at this point. Please don't add > anything new. > > Why not add values to sysfs (one value per file)?
This leaves me completely lost now, as I'm unclear as to how the "link" between a /sys/class/net/$NIF/ TAP/TUN network device and its serving process(es) could look like -- can you please help me here? What I need is to relate TAP/TUN network interfaces with their serving processes -- please note the plural here, as due to passing fd's down to child processes. So would it then make sense to add a new /sys/class/net/$NIF/taptun_owner DEVICE_ATTR which returns a (tabbed) list of serving process PIDs? If yes to returning a list of serving process PIDs, then how to I get all the PIDs? With my really limited understanding of things in this field I would need to scan all processes for their fd's in order to see which ones are referencing the $NIF TAP/TUN in question. This would be exactly what I'm currently doing in user space in my diag software, but now I would need to move this into the kernel into sysfs territory, is that what you are suggesting? To me the road down the fdinfo path had the advantage that it is keeping the specific app semantics out of the kernel, that is, searching for serving processes in kernel land -- but I might be misunderstanding this. Am I completely on the wrong track here with my question about listing the serving processes; is there a better way? As I said above, I'm (not only slightly) lost at the moment... -- Harald
