On Dec 2, 2012, at 6:54 PM, Paul Sheer <paulsh...@gmail.com> wrote:
>>> !strcmp(ent->d_name, "bonding_masters")) continue;
>>
>> No.
>>
>> That wires in a particular name, and when the *next* weird file gets added
>> by some future kernel revision, we won't handle it, and would end up wiring
>> in another name, lather, rinse, repeat.
>>
>> Instead, it should ignore "." and "..", ignore all *plain files* (rather
>> than directories), and check whether there's a "subsystem" item underneath
>> the item (just in case there are directories, or symlinks that point to
>> directories, in there that *don't* correspond to devices, either now or in
>> the future).
>
> Hmmm
>
> i recall on some systems they are symlinks not directories
Symlinks pointing to directories. Given that we're looking to see whether
there's a "subsystem" underneath the entry in question, so that the item in
/sys/class/net is the next-to-last component of the pathname rather than the
last component, the lstat() will follow the symlink in question - one of the
goals was to make "is it a directory or a symlink?" irrelevant, and looking for
something underneath it achieves that goal.
> what about if they don't contain "subsystem" in the future?
Well:
http://kernel.org/doc/Documentation/sysfs-rules.txt
The properties of a device are:
...
o subsystem (block, tty, pci, ...)
- simple string, never a path or a link
- retrieved by reading the "subsystem"-link and using only the
last element of the target path
so they appear to be claiming that a "device" will have a ""subsystem"-link".
> or older kernel versions that don't contain "subsystem" (do they?) ?
2.6.0 doesn't appear to. "ifindex" would probably be a better choice, as
1) 2.6.0 *does* have it
and
2) it's more specific to network interfaces.
I've checked in a change to use ifindex instead.
> or future versions that add subsystem to bonding_masters?
They'd have to make it a directory to do that, but ifindex is safer - if it got
an ifindex attribute, that'd be because it was an interface....
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
