On May 14, 2016, at 1:26 PM, Richard Cochran <richardcoch...@gmail.com> wrote:
> On Sat, May 14, 2016 at 11:47:22AM -0700, Guy Harris wrote:
>> So if you have a GUI application for packet capture, with a combo box to
>> select the type of time stamping, should it:
>>
>> 1) regardless of whether ETHTOOL_GET_TS_INFO is available, open the
>> adapter, try each of the time stamp types to see whether it works, and show
>> a combo box based on that;
>>
>> 2) use ETHTOOL_GET_TS_INFO if available;
>>
>> 3) offer all possibilities regardless of whether they work with the
>> adapter or not, and just report an error for possibilities that don't work?
>>
>> My preference is 2) - which is the main reason why libpcap offers "what
>> possibilities are available?" APIs, not just "request this possibility" APIs.
>
> You are going to have to implement #1 in any case, if you want your
> program to work on all kernels.
What libpcap currently implements is a combination of #2 and #3, where:
if it's compiled with headers that define ETHTOOL_GET_TS_INFO, it tries
to do ETHTOOL_GET_TS_INFO and, if that fails with EOPNOTSUPP or EINVAL, it
offers all possibilities;
if it's compiled with headers that don't define it, it just offers all
possibilities.
It could do a combination of #2 and #1, where "offers all possibilities" is
replaced by "opens the adapter, tries each of the possibilities, and offers the
ones that don't fail" - but, other than the current bugs with
ETHTOOL_GET_TS_INFO, I don't see any advantage to doing only #1, rather than
trying #2, perhaps with some special-casing to work around the bugs in
question, and only falling back on actually trying to set the options if we
can't ask about them.
