All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: yoshfuji@linux-ipv6.org
Cc: kazunori@miyazawa.org, kuznet@ms2.inr.ac.ru,
	linux-kernel@vger.kernel.org, netdev@oss.sgi.com,
	usagi@linux-ipv6.org
Subject: Re: (usagi-core 12294) Re: [PATCH] IPv6 IPsec support
Date: Wed, 05 Mar 2003 15:41:00 -0800 (PST)	[thread overview]
Message-ID: <20030305.154100.28816301.davem@redhat.com> (raw)
In-Reply-To: <20030306.004820.41101302.yoshfuji@linux-ipv6.org>

   From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
   Date: Thu, 06 Mar 2003 00:48:20 +0900 (JST)
   
   > The next large task will be to abstract out more common
   > pieces of code.  There is still quite a bit of code duplication
   > between v4 and v6 xfrm methods,
   
   Yes, we will do that.  That patch is first step for reducing 
   duplicate codes between IPv4 and IPv6.

Great.  I believe it should be possible, in the end, to make the XFRM
engine %100 address-family (v4, v6 etc.) and protocol (ah, esp)
independant.  If that goal is achieved, we may move generic parts from
net/ipv4/xfrm_*.c to net/xfrm_*.c

Note that this coincides with the idea to eventually have
an address-family independant flow cache.

Most of the address-family specific areas are:

1) DST lookup (xfrm_dst_lookup_t)

2) selector key comparisons and state lookup
   (xfrm$(AF)_selector_match, xfrm$(AF)_state_find)

3) receive processing (xfrm${AF}_rcv)

#1 is made for ipv6 by Miyazawa-san's patch.  This could logically
be extended to handle issues #2 and #3 above.

All protocol specific (ESP, AH) and address-family specific references
should go away from places like include/net/xfrm.h

I think you understand all of this, and therefore I cannot wait for the
next ipsec cleanup patch from you :)

Finally, note that eventually we will need some reference counting scheme
for to allow xfrm address-family modules to be unloaded safely.

Currently, ipv4 cannot be a module and ipv6 as a module is not able
to unload :-)  So the module unload problem does not exist right
at this moment.  So ignore this issue for now.

  reply	other threads:[~2003-03-05 23:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-05 14:30 [PATH] IPv6 IPsec support Kazunori Miyazawa
2003-03-05 15:21 ` David S. Miller
2003-03-05 15:48   ` (usagi-core 12294) Re: [PATCH] " YOSHIFUJI Hideaki / 吉藤英明
2003-03-05 23:41     ` David S. Miller [this message]
2003-03-06 21:32       ` Chris Wedgwood
2003-03-06 23:27         ` David S. Miller
2003-03-05 23:25 ` [PATH] " David S. Miller
2003-03-06  0:32   ` Kazunori Miyazawa
2003-03-06  4:43     ` David S. Miller
2003-03-18 18:32       ` [PATCH] IPv6 Extension headers (Re: [PATCH] IPv6 IPsec support) Mitsuru KANDA / 神田 充
2003-03-24  5:29         ` [PATCH] IPv6 Extension headers David S. Miller

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=20030305.154100.28816301.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=kazunori@miyazawa.org \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    --cc=usagi@linux-ipv6.org \
    --cc=yoshfuji@linux-ipv6.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.