All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Aleksandrov <nikolay@nvidia.com>
To: "bridge@lists.linux-foundation.org" 
	<bridge@lists.linux-foundation.org>,
	"henrik.bjoernlund@microchip.com"
	<henrik.bjoernlund@microchip.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jiri@mellanox.com" <jiri@mellanox.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Roopa Prabhu <roopa@nvidia.com>,
	"idosch@mellanox.com" <idosch@mellanox.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>
Cc: "horatiu.vultur@microchip.com" <horatiu.vultur@microchip.com>
Subject: Re: [PATCH net-next v4 08/10] bridge: cfm: Netlink GET configuration Interface.
Date: Fri, 9 Oct 2020 21:56:43 +0000	[thread overview]
Message-ID: <1180153d9d7dc5d5c6af9c2eb32f4052c47e14f3.camel@nvidia.com> (raw)
In-Reply-To: <20201009143530.2438738-9-henrik.bjoernlund@microchip.com>

On Fri, 2020-10-09 at 14:35 +0000, Henrik Bjoernlund wrote:
> This is the implementation of CFM netlink configuration
> get information interface.
> 
> Add new nested netlink attributes. These attributes are used by the
> user space to get configuration information.
> 
> GETLINK:
>     Request filter RTEXT_FILTER_CFM_CONFIG:
>     Indicating that CFM configuration information must be delivered.
> 
>     IFLA_BRIDGE_CFM:
>         Points to the CFM information.
> 
>     IFLA_BRIDGE_CFM_MEP_CREATE_INFO:
>         This indicate that MEP instance create parameters are following.
>     IFLA_BRIDGE_CFM_MEP_CONFIG_INFO:
>         This indicate that MEP instance config parameters are following.
>     IFLA_BRIDGE_CFM_CC_CONFIG_INFO:
>         This indicate that MEP instance CC functionality
>         parameters are following.
>     IFLA_BRIDGE_CFM_CC_RDI_INFO:
>         This indicate that CC transmitted CCM PDU RDI
>         parameters are following.
>     IFLA_BRIDGE_CFM_CC_CCM_TX_INFO:
>         This indicate that CC transmitted CCM PDU parameters are
>         following.
>     IFLA_BRIDGE_CFM_CC_PEER_MEP_INFO:
>         This indicate that the added peer MEP IDs are following.
> 
> CFM nested attribute has the following attributes in next level.
> 
> GETLINK RTEXT_FILTER_CFM_CONFIG:
>     IFLA_BRIDGE_CFM_MEP_CREATE_INSTANCE:
>         The created MEP instance number.
>         The type is u32.
>     IFLA_BRIDGE_CFM_MEP_CREATE_DOMAIN:
>         The created MEP domain.
>         The type is u32 (br_cfm_domain).
>         It must be BR_CFM_PORT.
>         This means that CFM frames are transmitted and received
>         directly on the port - untagged. Not in a VLAN.
>     IFLA_BRIDGE_CFM_MEP_CREATE_DIRECTION:
>         The created MEP direction.
>         The type is u32 (br_cfm_mep_direction).
>         It must be BR_CFM_MEP_DIRECTION_DOWN.
>         This means that CFM frames are transmitted and received on
>         the port. Not in the bridge.
>     IFLA_BRIDGE_CFM_MEP_CREATE_IFINDEX:
>         The created MEP residence port ifindex.
>         The type is u32 (ifindex).
> 
>     IFLA_BRIDGE_CFM_MEP_DELETE_INSTANCE:
>         The deleted MEP instance number.
>         The type is u32.
> 
>     IFLA_BRIDGE_CFM_MEP_CONFIG_INSTANCE:
>         The configured MEP instance number.
>         The type is u32.
>     IFLA_BRIDGE_CFM_MEP_CONFIG_UNICAST_MAC:
>         The configured MEP unicast MAC address.
>         The type is 6*u8 (array).
>         This is used as SMAC in all transmitted CFM frames.
>     IFLA_BRIDGE_CFM_MEP_CONFIG_MDLEVEL:
>         The configured MEP unicast MD level.
>         The type is u32.
>         It must be in the range 1-7.
>         No CFM frames are passing through this MEP on lower levels.
>     IFLA_BRIDGE_CFM_MEP_CONFIG_MEPID:
>         The configured MEP ID.
>         The type is u32.
>         It must be in the range 0-0x1FFF.
>         This MEP ID is inserted in any transmitted CCM frame.
> 
>     IFLA_BRIDGE_CFM_CC_CONFIG_INSTANCE:
>         The configured MEP instance number.
>         The type is u32.
>     IFLA_BRIDGE_CFM_CC_CONFIG_ENABLE:
>         The Continuity Check (CC) functionality is enabled or disabled.
>         The type is u32 (bool).
>     IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL:
>         The CC expected receive interval of CCM frames.
>         The type is u32 (br_cfm_ccm_interval).
>         This is also the transmission interval of CCM frames when enabled.
>     IFLA_BRIDGE_CFM_CC_CONFIG_EXP_MAID:
>         The CC expected receive MAID in CCM frames.
>         The type is CFM_MAID_LENGTH*u8.
>         This is MAID is also inserted in transmitted CCM frames.
> 
>     IFLA_BRIDGE_CFM_CC_PEER_MEP_INSTANCE:
>         The configured MEP instance number.
>         The type is u32.
>     IFLA_BRIDGE_CFM_CC_PEER_MEPID:
>         The CC Peer MEP ID added.
>         The type is u32.
>         When a Peer MEP ID is added and CC is enabled it is expected to
>         receive CCM frames from that Peer MEP.
> 
>     IFLA_BRIDGE_CFM_CC_RDI_INSTANCE:
>         The configured MEP instance number.
>         The type is u32.
>     IFLA_BRIDGE_CFM_CC_RDI_RDI:
>         The RDI that is inserted in transmitted CCM PDU.
>         The type is u32 (bool).
> 
>     IFLA_BRIDGE_CFM_CC_CCM_TX_INSTANCE:
>         The configured MEP instance number.
>         The type is u32.
>     IFLA_BRIDGE_CFM_CC_CCM_TX_DMAC:
>         The transmitted CCM frame destination MAC address.
>         The type is 6*u8 (array).
>         This is used as DMAC in all transmitted CFM frames.
>     IFLA_BRIDGE_CFM_CC_CCM_TX_SEQ_NO_UPDATE:
>         The transmitted CCM frame update (increment) of sequence
>         number is enabled or disabled.
>         The type is u32 (bool).
>     IFLA_BRIDGE_CFM_CC_CCM_TX_PERIOD:
>         The period of time where CCM frame are transmitted.
>         The type is u32.
>         The time is given in seconds. SETLINK IFLA_BRIDGE_CFM_CC_CCM_TX
>         must be done before timeout to keep transmission alive.
>         When period is zero any ongoing CCM frame transmission
>         will be stopped.
>     IFLA_BRIDGE_CFM_CC_CCM_TX_IF_TLV:
>         The transmitted CCM frame update with Interface Status TLV
>         is enabled or disabled.
>         The type is u32 (bool).
>     IFLA_BRIDGE_CFM_CC_CCM_TX_IF_TLV_VALUE:
>         The transmitted Interface Status TLV value field.
>         The type is u8.
>     IFLA_BRIDGE_CFM_CC_CCM_TX_PORT_TLV:
>         The transmitted CCM frame update with Port Status TLV is enabled
>         or disabled.
>         The type is u32 (bool).
>     IFLA_BRIDGE_CFM_CC_CCM_TX_PORT_TLV_VALUE:
>         The transmitted Port Status TLV value field.
>         The type is u8.
> 
> Signed-off-by: Henrik Bjoernlund  <henrik.bjoernlund@microchip.com>
> Reviewed-by: Horatiu Vultur  <horatiu.vultur@microchip.com>
> ---
>  include/uapi/linux/if_bridge.h |   6 ++
>  net/bridge/br_cfm_netlink.c    | 161 +++++++++++++++++++++++++++++++++
>  net/bridge/br_netlink.c        |  29 +++++-
>  net/bridge/br_private.h        |   6 ++
>  4 files changed, 200 insertions(+), 2 deletions(-)
> 

Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>


WARNING: multiple messages have this Message-ID (diff)
From: Nikolay Aleksandrov <nikolay@nvidia.com>
To: "bridge@lists.linux-foundation.org"
	<bridge@lists.linux-foundation.org>,
	"henrik.bjoernlund@microchip.com"
	<henrik.bjoernlund@microchip.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jiri@mellanox.com" <jiri@mellanox.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Roopa Prabhu <roopa@nvidia.com>,
	"idosch@mellanox.com" <idosch@mellanox.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>
Cc: "horatiu.vultur@microchip.com" <horatiu.vultur@microchip.com>
Subject: Re: [Bridge] [PATCH net-next v4 08/10] bridge: cfm: Netlink GET configuration Interface.
Date: Fri, 9 Oct 2020 21:56:43 +0000	[thread overview]
Message-ID: <1180153d9d7dc5d5c6af9c2eb32f4052c47e14f3.camel@nvidia.com> (raw)
In-Reply-To: <20201009143530.2438738-9-henrik.bjoernlund@microchip.com>

On Fri, 2020-10-09 at 14:35 +0000, Henrik Bjoernlund wrote:
> This is the implementation of CFM netlink configuration
> get information interface.
> 
> Add new nested netlink attributes. These attributes are used by the
> user space to get configuration information.
> 
> GETLINK:
>     Request filter RTEXT_FILTER_CFM_CONFIG:
>     Indicating that CFM configuration information must be delivered.
> 
>     IFLA_BRIDGE_CFM:
>         Points to the CFM information.
> 
>     IFLA_BRIDGE_CFM_MEP_CREATE_INFO:
>         This indicate that MEP instance create parameters are following.
>     IFLA_BRIDGE_CFM_MEP_CONFIG_INFO:
>         This indicate that MEP instance config parameters are following.
>     IFLA_BRIDGE_CFM_CC_CONFIG_INFO:
>         This indicate that MEP instance CC functionality
>         parameters are following.
>     IFLA_BRIDGE_CFM_CC_RDI_INFO:
>         This indicate that CC transmitted CCM PDU RDI
>         parameters are following.
>     IFLA_BRIDGE_CFM_CC_CCM_TX_INFO:
>         This indicate that CC transmitted CCM PDU parameters are
>         following.
>     IFLA_BRIDGE_CFM_CC_PEER_MEP_INFO:
>         This indicate that the added peer MEP IDs are following.
> 
> CFM nested attribute has the following attributes in next level.
> 
> GETLINK RTEXT_FILTER_CFM_CONFIG:
>     IFLA_BRIDGE_CFM_MEP_CREATE_INSTANCE:
>         The created MEP instance number.
>         The type is u32.
>     IFLA_BRIDGE_CFM_MEP_CREATE_DOMAIN:
>         The created MEP domain.
>         The type is u32 (br_cfm_domain).
>         It must be BR_CFM_PORT.
>         This means that CFM frames are transmitted and received
>         directly on the port - untagged. Not in a VLAN.
>     IFLA_BRIDGE_CFM_MEP_CREATE_DIRECTION:
>         The created MEP direction.
>         The type is u32 (br_cfm_mep_direction).
>         It must be BR_CFM_MEP_DIRECTION_DOWN.
>         This means that CFM frames are transmitted and received on
>         the port. Not in the bridge.
>     IFLA_BRIDGE_CFM_MEP_CREATE_IFINDEX:
>         The created MEP residence port ifindex.
>         The type is u32 (ifindex).
> 
>     IFLA_BRIDGE_CFM_MEP_DELETE_INSTANCE:
>         The deleted MEP instance number.
>         The type is u32.
> 
>     IFLA_BRIDGE_CFM_MEP_CONFIG_INSTANCE:
>         The configured MEP instance number.
>         The type is u32.
>     IFLA_BRIDGE_CFM_MEP_CONFIG_UNICAST_MAC:
>         The configured MEP unicast MAC address.
>         The type is 6*u8 (array).
>         This is used as SMAC in all transmitted CFM frames.
>     IFLA_BRIDGE_CFM_MEP_CONFIG_MDLEVEL:
>         The configured MEP unicast MD level.
>         The type is u32.
>         It must be in the range 1-7.
>         No CFM frames are passing through this MEP on lower levels.
>     IFLA_BRIDGE_CFM_MEP_CONFIG_MEPID:
>         The configured MEP ID.
>         The type is u32.
>         It must be in the range 0-0x1FFF.
>         This MEP ID is inserted in any transmitted CCM frame.
> 
>     IFLA_BRIDGE_CFM_CC_CONFIG_INSTANCE:
>         The configured MEP instance number.
>         The type is u32.
>     IFLA_BRIDGE_CFM_CC_CONFIG_ENABLE:
>         The Continuity Check (CC) functionality is enabled or disabled.
>         The type is u32 (bool).
>     IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL:
>         The CC expected receive interval of CCM frames.
>         The type is u32 (br_cfm_ccm_interval).
>         This is also the transmission interval of CCM frames when enabled.
>     IFLA_BRIDGE_CFM_CC_CONFIG_EXP_MAID:
>         The CC expected receive MAID in CCM frames.
>         The type is CFM_MAID_LENGTH*u8.
>         This is MAID is also inserted in transmitted CCM frames.
> 
>     IFLA_BRIDGE_CFM_CC_PEER_MEP_INSTANCE:
>         The configured MEP instance number.
>         The type is u32.
>     IFLA_BRIDGE_CFM_CC_PEER_MEPID:
>         The CC Peer MEP ID added.
>         The type is u32.
>         When a Peer MEP ID is added and CC is enabled it is expected to
>         receive CCM frames from that Peer MEP.
> 
>     IFLA_BRIDGE_CFM_CC_RDI_INSTANCE:
>         The configured MEP instance number.
>         The type is u32.
>     IFLA_BRIDGE_CFM_CC_RDI_RDI:
>         The RDI that is inserted in transmitted CCM PDU.
>         The type is u32 (bool).
> 
>     IFLA_BRIDGE_CFM_CC_CCM_TX_INSTANCE:
>         The configured MEP instance number.
>         The type is u32.
>     IFLA_BRIDGE_CFM_CC_CCM_TX_DMAC:
>         The transmitted CCM frame destination MAC address.
>         The type is 6*u8 (array).
>         This is used as DMAC in all transmitted CFM frames.
>     IFLA_BRIDGE_CFM_CC_CCM_TX_SEQ_NO_UPDATE:
>         The transmitted CCM frame update (increment) of sequence
>         number is enabled or disabled.
>         The type is u32 (bool).
>     IFLA_BRIDGE_CFM_CC_CCM_TX_PERIOD:
>         The period of time where CCM frame are transmitted.
>         The type is u32.
>         The time is given in seconds. SETLINK IFLA_BRIDGE_CFM_CC_CCM_TX
>         must be done before timeout to keep transmission alive.
>         When period is zero any ongoing CCM frame transmission
>         will be stopped.
>     IFLA_BRIDGE_CFM_CC_CCM_TX_IF_TLV:
>         The transmitted CCM frame update with Interface Status TLV
>         is enabled or disabled.
>         The type is u32 (bool).
>     IFLA_BRIDGE_CFM_CC_CCM_TX_IF_TLV_VALUE:
>         The transmitted Interface Status TLV value field.
>         The type is u8.
>     IFLA_BRIDGE_CFM_CC_CCM_TX_PORT_TLV:
>         The transmitted CCM frame update with Port Status TLV is enabled
>         or disabled.
>         The type is u32 (bool).
>     IFLA_BRIDGE_CFM_CC_CCM_TX_PORT_TLV_VALUE:
>         The transmitted Port Status TLV value field.
>         The type is u8.
> 
> Signed-off-by: Henrik Bjoernlund  <henrik.bjoernlund@microchip.com>
> Reviewed-by: Horatiu Vultur  <horatiu.vultur@microchip.com>
> ---
>  include/uapi/linux/if_bridge.h |   6 ++
>  net/bridge/br_cfm_netlink.c    | 161 +++++++++++++++++++++++++++++++++
>  net/bridge/br_netlink.c        |  29 +++++-
>  net/bridge/br_private.h        |   6 ++
>  4 files changed, 200 insertions(+), 2 deletions(-)
> 

Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>


  reply	other threads:[~2020-10-09 21:56 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-09 14:35 [PATCH net-next v4 00/10] net: bridge: cfm: Add support for Connectivity Fault Management(CFM) Henrik Bjoernlund
2020-10-09 14:35 ` [Bridge] " Henrik Bjoernlund
2020-10-09 14:35 ` [PATCH net-next v4 01/10] net: bridge: extend the process of special frames Henrik Bjoernlund
2020-10-09 14:35   ` [Bridge] " Henrik Bjoernlund
2020-10-09 21:40   ` Nikolay Aleksandrov
2020-10-09 21:40     ` [Bridge] " Nikolay Aleksandrov
2020-10-12  9:12   ` Nikolay Aleksandrov
2020-10-12  9:12     ` [Bridge] " Nikolay Aleksandrov
2020-10-12 11:57     ` henrik.bjoernlund
2020-10-12 11:57       ` [Bridge] " henrik.bjoernlund
2020-10-09 14:35 ` [PATCH net-next v4 02/10] bridge: cfm: Add BRIDGE_CFM to Kconfig Henrik Bjoernlund
2020-10-09 14:35   ` [Bridge] " Henrik Bjoernlund
2020-10-09 21:39   ` Nikolay Aleksandrov
2020-10-09 21:39     ` [Bridge] " Nikolay Aleksandrov
2020-10-12 13:13     ` henrik.bjoernlund
2020-10-12 13:13       ` [Bridge] " henrik.bjoernlund
2020-10-09 21:40   ` Nikolay Aleksandrov
2020-10-09 21:40     ` [Bridge] " Nikolay Aleksandrov
2020-10-09 14:35 ` [PATCH net-next v4 03/10] bridge: uapi: cfm: Added EtherType used by the CFM protocol Henrik Bjoernlund
2020-10-09 14:35   ` [Bridge] " Henrik Bjoernlund
2020-10-09 21:41   ` Nikolay Aleksandrov
2020-10-09 21:41     ` [Bridge] " Nikolay Aleksandrov
2020-10-12 13:13     ` henrik.bjoernlund
2020-10-12 13:13       ` [Bridge] " henrik.bjoernlund
2020-10-09 14:35 ` [PATCH net-next v4 04/10] bridge: cfm: Kernel space implementation of CFM. MEP create/delete Henrik Bjoernlund
2020-10-09 14:35   ` [Bridge] " Henrik Bjoernlund
2020-10-09 21:42   ` Nikolay Aleksandrov
2020-10-09 21:42     ` [Bridge] " Nikolay Aleksandrov
2020-10-12 13:12     ` henrik.bjoernlund
2020-10-12 13:12       ` [Bridge] " henrik.bjoernlund
2020-10-09 14:35 ` [PATCH net-next v4 05/10] bridge: cfm: Kernel space implementation of CFM. CCM frame TX added Henrik Bjoernlund
2020-10-09 14:35   ` [Bridge] " Henrik Bjoernlund
2020-10-09 21:49   ` Nikolay Aleksandrov
2020-10-09 21:49     ` [Bridge] " Nikolay Aleksandrov
2020-10-12 13:11     ` henrik.bjoernlund
2020-10-12 13:11       ` [Bridge] " henrik.bjoernlund
2020-10-09 14:35 ` [PATCH net-next v4 06/10] bridge: cfm: Kernel space implementation of CFM. CCM frame RX added Henrik Bjoernlund
2020-10-09 14:35   ` [Bridge] " Henrik Bjoernlund
2020-10-09 21:52   ` Nikolay Aleksandrov
2020-10-09 21:52     ` [Bridge] " Nikolay Aleksandrov
2020-10-12 13:11     ` henrik.bjoernlund
2020-10-12 13:11       ` [Bridge] " henrik.bjoernlund
2020-10-09 14:35 ` [PATCH net-next v4 07/10] bridge: cfm: Netlink SET configuration Interface Henrik Bjoernlund
2020-10-09 14:35   ` [Bridge] " Henrik Bjoernlund
2020-10-09 21:53   ` Nikolay Aleksandrov
2020-10-09 21:53     ` [Bridge] " Nikolay Aleksandrov
2020-10-12 13:07     ` henrik.bjoernlund
2020-10-12 13:07       ` [Bridge] " henrik.bjoernlund
2020-10-10  1:45   ` Jakub Kicinski
2020-10-10  1:45     ` [Bridge] " Jakub Kicinski
2020-10-12 13:05     ` Henrik Bjoernlund
2020-10-12 13:05       ` [Bridge] " Henrik Bjoernlund
2020-10-09 14:35 ` [PATCH net-next v4 08/10] bridge: cfm: Netlink GET " Henrik Bjoernlund
2020-10-09 14:35   ` [Bridge] " Henrik Bjoernlund
2020-10-09 21:56   ` Nikolay Aleksandrov [this message]
2020-10-09 21:56     ` Nikolay Aleksandrov
2020-10-09 21:59     ` Nikolay Aleksandrov
2020-10-09 21:59       ` [Bridge] " Nikolay Aleksandrov
2020-10-12 13:10       ` henrik.bjoernlund
2020-10-12 13:10         ` [Bridge] " henrik.bjoernlund
2020-10-12 13:10     ` henrik.bjoernlund
2020-10-12 13:10       ` [Bridge] " henrik.bjoernlund
2020-10-09 14:35 ` [PATCH net-next v4 09/10] bridge: cfm: Netlink GET status Interface Henrik Bjoernlund
2020-10-09 14:35   ` [Bridge] " Henrik Bjoernlund
2020-10-09 22:00   ` Nikolay Aleksandrov
2020-10-09 22:00     ` [Bridge] " Nikolay Aleksandrov
2020-10-12 13:09     ` henrik.bjoernlund
2020-10-12 13:09       ` [Bridge] " henrik.bjoernlund
2020-10-09 14:35 ` [PATCH net-next v4 10/10] bridge: cfm: Netlink Notifications Henrik Bjoernlund
2020-10-09 14:35   ` [Bridge] " Henrik Bjoernlund
2020-10-09 22:03   ` Nikolay Aleksandrov
2020-10-09 22:03     ` [Bridge] " Nikolay Aleksandrov
2020-10-12 13:08     ` henrik.bjoernlund
2020-10-12 13:08       ` [Bridge] " henrik.bjoernlund

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=1180153d9d7dc5d5c6af9c2eb32f4052c47e14f3.camel@nvidia.com \
    --to=nikolay@nvidia.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=henrik.bjoernlund@microchip.com \
    --cc=horatiu.vultur@microchip.com \
    --cc=idosch@mellanox.com \
    --cc=jiri@mellanox.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=roopa@nvidia.com \
    /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.