Sorry, been away.
On Tue, Aug 20, 2019 at 9:27 PM Florian Westphal <fw@xxxxxxxxx> wrote:
>
> Jones Desougi <jones.desougi+netfilter@xxxxxxxxx> wrote:
> > On Sun, Aug 18, 2019 at 8:22 PM Ander Juaristi <a@xxxxxxxxxxxx> wrote:
> > >
> > > On 17/8/19 15:43, Jones Desougi wrote:
> > > >> diff --git a/include/uapi/linux/netfilter/nf_tables.h b/include/uapi/linux/netfilter/nf_tables.h
> > > >> index 82abaa183fc3..b83b62eb4b01 100644
> > > >> --- a/include/uapi/linux/netfilter/nf_tables.h
> > > >> +++ b/include/uapi/linux/netfilter/nf_tables.h
> > > >> @@ -799,6 +799,9 @@ enum nft_exthdr_attributes {
> > > >> * @NFT_META_OIFKIND: packet output interface kind name (dev->rtnl_link_ops->kind)
> > > >> * @NFT_META_BRI_IIFPVID: packet input bridge port pvid
> > > >> * @NFT_META_BRI_IIFVPROTO: packet input bridge vlan proto
> > > >> + * @NFT_META_TIME_NS: time since epoch (in nanoseconds)
> > > >> + * @NFT_META_TIME_DAY: day of week (from 0 = Sunday to 6 = Saturday)
> > > >
> > > > This would be clearer as NFT_META_TIME_WEEKDAY. Just day can mean a
> > > > lot of things.
> > > > Matches nicely with the added nft_meta_weekday function too.
> > >
> > > I agree with you here. Seems to me WEEKDAY is clearer.
> > >
> > > >
> > > >> + * @NFT_META_TIME_HOUR: hour of day (in seconds)
> > > >
> > > > This isn't really an hour, so why call it that (confuses unit at least)?
> > > > Something like NFT_META_TIME_TIMEOFDAY? Alternatively TIMEINDAY.
> > > > Presumably the added nft_meta_hour function also derives its name from
> > > > this, but otherwise has nothing to do with hours.
> > > >
> > >
> > > But not so sure on this one. TIMEOFDAY sounds to me equivalent to HOUR,
> > > though less explicit (more ambiguous).
> >
> > HOUR is a unit, much like NS, but its use is quite different with no
> > clear hint as to how. Unlike the latter it's also not the unit of the
> > value. From that perspective the name comes up empty of meaning. If
> > you already know what it means, the name can be put in context, but
> > that's not explicit at all.
>
> If the NFT_META_TIME_* names are off, then those for the
> frontend are too.
In part, but they are not that tightly bound. Or shouldn't be. See
regarding hour below.
>
> I think
> meta time <iso-date>
> meta hour <relative to this day>
> meta day <weekday>
>
> are fine, and thus so are the uapi enums.
>
> Examples:
>
> meta time < "2019-06-06 17:20:20" drop
> meta hour 11:00-17:00 accept
> meta day "Sat" drop
>
> What would you suggest as alternatives?
Using weekday here as well would be the obvious choice, e.g.
meta weekday "Sat" drop
Not being explicit seems bad to me, especially in the kernel interface.
However, for hour the context is different.
Hour is relevant in this frontend interface, since the time
specification is hour anchored.
An alternative implementation might use nautic 'five bells in morning
watch' or whatever for the user, but it would still translate to time
of day in seconds in the kernel interface.
