All of lore.kernel.org
 help / color / mirror / Atom feed
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...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.