netdev - Re: [RFC][PATCH 1/1] net: support for hardware timestamping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200807301638.54484.opurdila@ixiacom.com>
Date:	Wed, 30 Jul 2008 16:38:54 +0300
From:	Octavian Purdila <opurdila@...acom.com>
To:	Patrick Ohly <patrick.ohly@...el.com>
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC][PATCH 1/1] net: support for hardware timestamping

On Wednesday 30 July 2008, Patrick Ohly wrote:

> It's the app which chooses when to enable the feature, so we need a way
> to communicate that.

Ok, perhaps a new SIOCSHWTSTAMP ioctl? (or maybe we can piggy back on the 
filter one with the HWTSTAMP_FILTER_NONE you proposed?)

> > Ok, I see... How about adding a new SIOCSHWTSTAMPFILTER ioctl:
> >
> > #define HWTSTAMP_FILTER_PTP_L2 0x01
> > #define HWTSTAMP_FILTER_PTP_L4 0x02
> > ...
> > struct hwtstamp_filter {
> > 	char type;
> > };
> >
> > If needed we could later expand hwtstamp_filter to include ether_types,
> > ip_types, udp/tcp ports, etc.
>
> Yes, that'll work. Regarding the design of the ioctl() call and its
> parameter, how do we preserve backwards compatibility as new fields get
> added?
>

I think we could simply add more fields in the structure since they will only 
be used with new commands. If the app know about the new command than it will 
know to use the new structure layout.

> The initial list of defines could be:
<snip>
> I prefer an enumeration over flags because by design, only valid
> combinations are possible.
>

I agree.

Thanks,
tavi
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html