dect
/
libpcap
Archived
13
0
Fork 0
Code Releases Activity

Update a comment.

This commit is contained in:
Guy Harris 2010-03-10 15:53:55 -08:00
parent b3eca60b5c
commit c3184553df
1 changed files with 28 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
inet.c
View File

@ -366,26 +366,38 @@ add_or_find_if(pcap_if_t **curdev_ret, pcap_if_t **alldevs, const char *name,
* a Cisco 340 or 350, rather than an old Aironet card, it should use
* that in the description.
*
* Do NetBSD, DragonflyBSD, or OpenBSD support this as well? OpenBSD
* lets you get a description, but it's not generated by the OS, it's
* set with another ioctl that ifconfig supports; we use that to get
* the description in OpenBSD.
* Do NetBSD, DragonflyBSD, or OpenBSD support this as well? FreeBSD
* and OpenBSD let you get a description, but it's not generated by the OS,
* it's set with another ioctl that ifconfig supports; we use that to get
* a description in FreeBSD and OpenBSD, but if there is no such
* description available, it still might be nice to get some description
* string based on the device type or something such as that.
*
* In OS X, the System Configuration framework can apparently return
* names in 10.4 and later; it also appears that freedesktop.org's HAL
* offers an "info.product" string, but the HAL specification says
* it "should not be used in any UI" and "subsystem/capability
* specific properties" should be used instead. Using that would
* require that libpcap applications be linked with the frameworks/
* libraries in question, which would be a bit of a pain unless we
* offer, for example, a pkg-config:
* names in 10.4 and later.
*
* http://pkg-config.freedesktop.org/wiki/
* It also appears that freedesktop.org's HAL offers an "info.product"
* string, but the HAL specification says it "should not be used in any
* UI" and "subsystem/capability specific properties" should be used
* instead and, in any case, I think HAL is being deprecated in
* favor of other stuff such as DeviceKit. DeviceKit doesn't appear
* to have any obvious product information for devices, but maybe
* I haven't looked hard enough.
*
* script, so applications can just use that script to find out what
* libraries you need to link with when linking with libpcap.
* pkg-config is GPLed; I don't know whether that would prevent its
* use with a BSD-licensed library such as libpcap.
* Using the System Configuration framework, or HAL, or DeviceKit, or
* whatever, would require that libpcap applications be linked with
* the frameworks/libraries in question. That shouldn't be a problem
* for programs linking with the shared version of libpcap (unless
* you're running on AIX - which I think is the only UN*X that doesn't
* support linking a shared library with other libraries on which it
* depends, and having an executable linked only with the first shared
* library automatically pick up the other libraries when started -
* and using HAL or whatever). Programs linked with the static
* version of libpcap would have to use pcap-config with the --static
* flag in order to get the right linker flags in order to pick up
* the additional libraries/frameworks; those programs need that anyway
* for libpcap 1.1 and beyond on Linux, as, by default, it requires
* -lnl.
*
* Do any other UN*Xes, or desktop environments support getting a
* description?