From: Matti Vaittinen <matti.vaittinen@nsn.com>
To: ext David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH RFC] IPv6: RTM_GETROUTE NLM_F_MATCH handled as stated in RFC 3549
Date: Wed, 04 Jan 2012 08:24:25 +0200 [thread overview]
Message-ID: <1325658265.7008.4.camel@hakki> (raw)
In-Reply-To: <20120103.151619.1382800390097680631.davem@davemloft.net>
On Tue, 2012-01-03 at 15:16 -0500, ext David Miller wrote:
> From: Matti Vaittinen <matti.vaittinen@nsn.com>
> Date: Wed, 28 Dec 2011 16:01:55 +0200
>
> > This patch makes ipv6 module to return only routes which match
> > attributes / filled fields in RTM_GETROUTE, if NLM_F_MATCH is
> > specified and NLM_F_ROOT is not. This patch has not been tested,
> > and is meant more to be for visualization of what I thought of doing.
> > If the NLM_F_MATCH support is considered to be good idea, then I
> > will check this more thoroughly and send another patch.
> >
> > I assume this would not break *many* existing userspace applications,
> > since specifying NLM_F_MATCH (especially with no NLM_F_ROOT) sounds
> > pretty stupid - if no entries should be filtered.
> >
> > I checked iproute2, and it uses NLM_F_DUMP and does filtering entries
> > in userspace - thus it is not affected.
> >
> > I guess this same idea could be brought in RTM_GETADDR and RTM_GETLINK
> > too? Maybe also on IPv4 side?
>
> The problem is that you can't avoid writing the user level filters
> even if we add this behavior now.
>
> Any tool which wants to work on every single Linux system out there
> right now has to accomodate the case where NLM_F_MATCH isn't done by
> the kernel. It will take several years before this would be widely
> deployed even if it went in right now.
>
> This means applications are not simplified at all, in fact they become
> more complex, since they have to accomodate not just one but two
> possible cases.
I can't argue. Like Metallica sang, "Sad but true".
> I'm therefore not inclined to apply a patch like this, sorry. And even
> if I was, I'd ask that ipv4 get it first or at the same time.
>
No need to be sorry. I guess I can live with this ;) Thanks for closing
the case.
--Matti
--
Matti Vaittinen
+358 504863070
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Told a UDP joke the other night...
...but I'm not sure everyone got it...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
prev parent reply other threads:[~2012-01-04 6:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-28 14:01 [PATCH RFC] IPv6: RTM_GETROUTE NLM_F_MATCH handled as stated in RFC 3549 Matti Vaittinen
2012-01-03 20:16 ` David Miller
2012-01-04 6:24 ` Matti Vaittinen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1325658265.7008.4.camel@hakki \
--to=matti.vaittinen@nsn.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).