On 06.04, Alexander Holler wrote: > Am 06.04.2015 um 11:01 schrieb Alexander Holler: > >Am 06.04.2015 um 10:44 schrieb Alexander Holler: > >>Am 06.04.2015 um 03:51 schrieb Patrick McHardy: > >>>On 05.04, Alexander Holler wrote: > >>>>Am 05.04.2015 um 14:11 schrieb Patrick McHardy: > >>>>>On 05.04, Patrick McHardy wrote: > >>>> > >>>>>>Basically this involves splitting the expression types into lhs > >>>>>>(non-const) > >>>>>>and rhs (const) parts. Keywords on the RHS side can be caught > >>>>>>using an > >>>>>>error statement and deferred to resolution during runtime. > >>>> > >>>>Sounds like trial and error. ;) > >>> > >>>The approach is, the patch isn't, it changes the grammar to have > >>>these kinds of errors in a defined state. The patch I sent > >>>however is, but I'm quite sure i understand the implications. > >> > >>Just to mention it, there is still the possibility to define and use > >>keywords for all the icmp type names. > > > >Preferable with names as used in icmp.h and icmpv6.h. As these are > >defines in C-headers, there is very high probability that these names > >are unique, even across a large number of different sets of type or > >other names. > > That would also remove the need to look up what name nft uses if would be > clear that the names are the same as defined in c-headers. > > E.g. the ICMPv6 parameter-problem is good example. In the linux headers it > is called ICMPV6_PARAMPROB, nft named it param-problem and in documentations > it is often named as parameter-problem. > > So if nft would use icmpv6_paramprob, the documentation could just refer to > the c-headers. No, an icmpv6_ prefix is redundant and I don't see any benefit in doing that. "Documentations", whatever that is, don't matter, what matters is our documentation. And whether we point people to that or some header file really doesn't matter, except that we don't expect people to read header files to use nft. Its a tool for admins, not programmers. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
