Update a comment.

1 files changed, 28 insertions, 16 deletions

diff --git a/inet.c b/inet.c
index 1ce3cfd..494de09 100644
--- a/inet.c
+++ b/inet.c
@@ -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?