[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110119192409.GE1845@del.dom.local>
Date: Wed, 19 Jan 2011 20:24:09 +0100
From: Jarek Poplawski <jarkao2@...il.com>
To: Jan Engelhardt <jengelh@...ozas.de>
Cc: jamal <hadi@...erus.ca>, Pablo Neira Ayuso <pablo@...filter.org>,
David Miller <davem@...emloft.net>,
arthur.marsh@...ernode.on.net, eric.dumazet@...il.com,
netdev@...r.kernel.org
Subject: Re: inbound connection problems when "netlink: test for all flags
of the NLM_F_DUMP composite" commit applied
On Wed, Jan 19, 2011 at 07:04:06PM +0100, Jan Engelhardt wrote:
>
> On Wednesday 2011-01-19 17:54, Jarek Poplawski wrote:
> >
> >I still don't understand why you call this the nonsense. There are
> >two dump flags NLM_F_ROOT and NLM_F_MATCH plus for convenience
> >NLM_F_DUMP as 2 in 1. Avahi uses these specific flags. Why would
> >anybody have added these specific flags if they can never be used
> >separately?
>
> It looks like the authors' intentinos were to make NLM_F_MATCH not
> stop after a single entry has been found. So that sounds like dump,
> ok.
>
> But NLM_F_ROOT does not quite strike me as a dump request. What if I
> wanted just a single item returned but still start at the root?
Hmm... Does it say about starting at the root?:
" NLM_F_ROOT Return the complete table instead of a
single entry."
>
> Or asking from a different direction, what's NLM_F_ROOT good for
> when, say, struct rtmsg->rtm_table specifies (in rtnetlink) where to
> start? (Particularly, 0 for an "invisible root" that contains all
> tables.)
I can't say I understand these flags, but IMHO the main point is we
should respect them as separate, even if mostly unused and look like
unnecessary. (Unless there is really no other way of fixing this
genetlink bug.) If it were undocumented... but after all this the RFC.
Jarek P.
--
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
Powered by blists - more mailing lists