arm64: random-order kernel
Hi, with some guidance from Theo I have random-order kernels on arm64. In one instance the kernel did not boot up. This could be a real bug, or not. Please try this diff and make sure the machine still boots up. If it does not: Please send me the gap.S and the lorder file from the kernel compile directory. Thanks, Patrick diff --git a/sys/arch/arm64/arm64/locore.S b/sys/arch/arm64/arm64/locore.S index 76b585ebb46..b7ef5321e59 100644 --- a/sys/arch/arm64/arm64/locore.S +++ b/sys/arch/arm64/arm64/locore.S @@ -30,232 +30,14 @@ #include "assym.h" #include #include -#include -#include #include -#include - -#defineVIRT_BITS 39 - -#defineDEVICE_MEM 0 -#defineNORMAL_UNCACHED 1 -#defineNORMAL_MEM 2 - -/* - * We assume: - * MMU on with an identity map, or off - * D-Cache: off - * I-Cache: on or off - * We are loaded at a 2MiB aligned address - */ - -#defineINIT_STACK_SIZE (PAGE_SIZE * 4) - - .text - .globl _start -_start: - mov x21, x0 - mov x22, x1 - mov x23, x2 - - /* Drop to EL1 */ - bl drop_to_el1 - - /* -* Disable the MMU. We may have entered the kernel with it on and -* will need to update the tables later. If this has been set up -* with anything other than a VA == PA map then this will fail, -* but in this case the code to find where we are running from -* would have also failed. -*/ - dsb sy - mrs x2, sctlr_el1 - bic x2, x2, SCTLR_M - msr sctlr_el1, x2 - isb - - /* Set the context id */ - msr contextidr_el1, xzr - - /* Get the virt -> phys offset */ - bl get_virt_delta - - /* Store symbol value. */ - adr x0, .Lesym - ldr x0, [x0] - sub x0, x0, x29 - add x21, x21, x29 - str x21, [x0] - - /* -* At this point: -* x29 = PA - VA -* x28 = Our physical load address -*/ - - /* Create the page tables */ - bl create_pagetables - - /* -* At this point: -* x27 = TTBR0 table -* x26 = TTBR1 table -*/ - - /* Enable the mmu */ - bl start_mmu - - /* Jump to the virtual address space */ - ldr x15, .Lvirtdone - br x15 - -.Linitstack: - .xword initstack -.Linitstack_end: - .xword initstack_end -virtdone: - /* Set up the stack */ - adr x25, .Linitstack_end - ldr x25, [x25] - mov sp, x25 - mov x8, #TRAPFRAME_SIZEOF - sub x8, x8, (STACKALIGNBYTES) - and x8, x8, ~(STACKALIGNBYTES) - - // pass base of kernel stack as proc0 - adr x25, .Linitstack - ldr x25, [x25] - - sub sp, sp, x8 - - /* Zero the BSS */ - ldr x15, .Lbss - ldr x14, .Lend -1: - str xzr, [x15], #8 - cmp x15, x14 - b.lo1b - - /* Backup the module pointer */ - mov x1, x0 - - /* Make the page table base a virtual address */ - sub x26, x26, x29 - - // XXX - shouldn't this be 8 * 5 (struct grew from 4 -> 5) - sub sp, sp, #(64 * 4) - mov x0, sp - - /* Negate the delta so it is VA -> PA */ - neg x29, x29 - - str x1, [x0] /* modulep */ - str x26, [x0, 8]/* kern_l1pt */ - str x29, [x0, 16] /* kern_delta */ - str x25, [x0, 24] /* kern_stack */ - str x21, [x0, 32] /* ? (x0 arg on boot) */ - str x22, [x0, 40] /* ? (x1 arg on boot) */ - str x23, [x0, 48] /* fdt (x2 arg on boot) */ - - /* trace back starts here */ - mov fp, #0 - /* Branch to C code */ - bl initarm - bl _C_LABEL(main) - - /* We should not get here */ - brk 0 - - .align 3 -.Lvirtdone: - .quad virtdone -.Lbss: - .quad __bss_start -.Lstart: - .quad _start -.Lend: - .quad _end -.Lcpu_info_primary: - .quad _C_LABEL(cpu_info_primary) - -/* - * If we are started in EL2, configure the required hypervisor - * registers and drop to EL1. - */ -drop_to_el1: - mrs x1, CurrentEL - lsr x1, x1, #2 - cmp x1, #0x2 - b.eq1f - ret -1: - /* Configure the Hypervisor */ - mov x2, #(HCR_RW) - msr hcr_el2, x2 - - /* Load the Virtualization Process ID Register */ - mrs x2, midr_el1 - msr vpidr_el2, x2 - - /* Load the Virtualization Multiprocess ID Register */ - mrs x2, mpidr_el1 - msr vmpidr_el2, x2 - - /* Set the bits that need to be 1 in sctlr_el1 */ - ldr x2, .Lsctlr_res1 - msr sctlr_el1, x2 - - /* Don't trap to EL2 for exceptions */ - mov x2, #CPTR_RES1 - msr cptr_el2, x2 - - /*
Re: Question on getcwd(3) behavior on OpenBSD
On Sat, Jun 03, 2017 at 06:13:56PM +0200, Alexander Bochmann wrote: > Hi, > > ...on Wed, May 31, 2017 at 03:07:55PM -0400, Ted Unangst wrote: > > > Kurt Mosiejczuk wrote: > > > Just recently converted the main user machines students and faculty use > > > to OpenBSD 6.1. I've found out that git will abort in one scenario > > > where there is a directory in the tree where the user has execute > > > permissions but not read permissions. > > Not so much a corner case as explicitly documented as a possible error. > > I played some more with this. > > I have a couple of directories, and a user that is not in the > sys group: > > drwxrwx--x 3 root sys 512 Jun 3 15:04 test1 > drwxrwx-wx 2 root sys 512 Jun 3 15:09 test1/subdir > drwxrwx-wx 2 root sys 512 Jun 3 15:16 test2 > > On OpenBSD 6.1, this is what happens when I try to run a "pwd" > in those directories as the above user: > > $ cd /tmp/test1 > $ pwd > /tmp/test1 > $ cd /tmp/test1/subdir > $ pwd > ksh: pwd: can't get current directory - Permission denied > $ cd /tmp/test2 > $ pwd > /tmp/test2 > > I don't quite understand the Permission denied in test1/subdir? > Am I missing something? > I will try a shot. it is mostly how I understand it, and I could be wrong (but I read the code source for some parts) :) - for "entering" in a directory (chdir(2)), you need the "search" permission on it (VEXEC - executable bit). - for reading the name of a node, you need the "read" permission (VREAD) on the node directory which contain it. The inode itself doesn't know its name (think about hardlinks), but only the parent directory. So in /tmp/test1 or /tmp/test2, in order to get the full path, you need: - VEXEC perm on test1 (or test2) - VEXEC|VREAD perm on /tmp (in order to read the name of "test1" node in /tmp) - VEXEC|VREAD perm on / (in order to read the name of "tmp" node in "/") you have all of them, you get the full pathname. Now for /tmp/test1/subdir, you need: - VEXEC perm on subdir - VEXEC|VREAD perm on test1 - VEXEC|VREAD perm on /tmp - VEXEC|VREAD perm on / here you don't have VREAD perm on "test1" (only VEXEC), so you can't obtain the name of "subdir" as it is written in "test1" vnode: getcwd(3) fails. -- Sebastien Marie
Re: Question on getcwd(3) behavior on OpenBSD
Hi, ...on Wed, May 31, 2017 at 03:07:55PM -0400, Ted Unangst wrote: > Kurt Mosiejczuk wrote: > > Just recently converted the main user machines students and faculty use > > to OpenBSD 6.1. I've found out that git will abort in one scenario > > where there is a directory in the tree where the user has execute > > permissions but not read permissions. > Not so much a corner case as explicitly documented as a possible error. I played some more with this. I have a couple of directories, and a user that is not in the sys group: drwxrwx--x 3 root sys 512 Jun 3 15:04 test1 drwxrwx-wx 2 root sys 512 Jun 3 15:09 test1/subdir drwxrwx-wx 2 root sys 512 Jun 3 15:16 test2 On OpenBSD 6.1, this is what happens when I try to run a "pwd" in those directories as the above user: $ cd /tmp/test1 $ pwd /tmp/test1 $ cd /tmp/test1/subdir $ pwd ksh: pwd: can't get current directory - Permission denied $ cd /tmp/test2 $ pwd /tmp/test2 I don't quite understand the Permission denied in test1/subdir? Am I missing something? Alex.
[patch/bgpctl] Add support for extended communities (updated)
(forgot to add the manual bit in the previous patch)
Hello,
Here is a patch to allow usage of extended communities with bgpctl :
bgpctl show ip bgp ext-community rt 10:10
bgpctl netw add 2001:db8:1::/64 ext soo 10:50
Denis
Index: bgpctl/bgpctl.8
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.8,v
retrieving revision 1.77
diff -u -p -r1.77 bgpctl.8
--- bgpctl/bgpctl.8 29 May 2017 21:27:36 - 1.77
+++ bgpctl/bgpctl.8 3 Jun 2017 14:30:51 -
@@ -326,6 +326,9 @@ anywhere in the AS path.
.It Cm community Ar community
Show all entries with community
.Ar community .
+.It Cm ext-community Ar ext-community
+Show all entries with extended-community
+.Ar ext-community .
.It Cm large-community Ar large-community
Show all entries with large-community
.Ar large-community .
Index: bgpctl/bgpctl.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.195
diff -u -p -r1.195 bgpctl.c
--- bgpctl/bgpctl.c 31 May 2017 10:48:06 - 1.195
+++ bgpctl/bgpctl.c 3 Jun 2017 14:30:51 -
@@ -261,6 +261,11 @@ main(int argc, char *argv[])
sizeof(res->community));
type = IMSG_CTL_SHOW_RIB_COMMUNITY;
}
+ if (res->extcommunity.flags == EXT_COMMUNITY_FLAG_VALID) {
+ memcpy(, >extcommunity,
+ sizeof(res->extcommunity));
+ type = IMSG_CTL_SHOW_RIB_EXTCOMMUNITY;
+ }
if (res->large_community.as != COMMUNITY_UNSET &&
res->large_community.ld1 != COMMUNITY_UNSET &&
res->large_community.ld2 != COMMUNITY_UNSET) {
Index: bgpctl/parser.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/parser.c,v
retrieving revision 1.77
diff -u -p -r1.77 parser.c
--- bgpctl/parser.c 14 Feb 2017 13:13:23 - 1.77
+++ bgpctl/parser.c 3 Jun 2017 14:30:51 -
@@ -47,6 +47,8 @@ enum token_type {
RIBNAME,
SHUTDOWN_COMMUNICATION,
COMMUNITY,
+ EXTCOMMUNITY,
+ EXTCOM_SUBTYPE,
LARGE_COMMUNITY,
LOCALPREF,
MED,
@@ -94,12 +96,16 @@ static const struct token t_show_mrt_as[
static const struct token t_show_prefix[];
static const struct token t_show_ip[];
static const struct token t_show_community[];
+static const struct token t_show_extcommunity[];
+static const struct token t_show_ext_subtype[];
static const struct token t_show_largecommunity[];
static const struct token t_network[];
static const struct token t_network_show[];
static const struct token t_prefix[];
static const struct token t_set[];
static const struct token t_community[];
+static const struct token t_extcommunity[];
+static const struct token t_ext_subtype[];
static const struct token t_largecommunity[];
static const struct token t_localpref[];
static const struct token t_med[];
@@ -166,6 +172,7 @@ static const struct token t_show_rib[] =
{ ASTYPE, "peer-as", AS_PEER,t_show_rib_as},
{ ASTYPE, "empty-as", AS_EMPTY, t_show_rib},
{ KEYWORD, "community",NONE, t_show_community},
+ { KEYWORD, "ext-community", NONE, t_show_extcommunity},
{ KEYWORD, "large-community", NONE,t_show_largecommunity},
{ FLAG, "best", F_CTL_ACTIVE, t_show_rib},
{ FLAG, "selected", F_CTL_ACTIVE, t_show_rib},
@@ -288,6 +295,29 @@ static const struct token t_show_communi
{ ENDTOKEN, "", NONE, NULL}
};
+static const struct token t_show_extcommunity[] = {
+ { EXTCOM_SUBTYPE, "bdc", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "defgw",NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "esi-lab", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "esi-rt", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "l2vid",NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "mac-mob", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "odi", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "ort", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "ori", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "ovs", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "rt", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "soo", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "srcas",NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "vrfri",NONE, t_show_ext_subtype},
+ { ENDTOKEN, "", NONE, NULL}
+};
+
+static const struct token
Re: mcast-proxy daemon
On Sat, May 27, 2017 at 11:05:13PM +0200, Paul de Weerd wrote: | - lacks an rc.d init script Here's a diff that adds an rc.d script 'mcastproxy' (other daemons that have a '-' in their name also drop it in their rc.d script, so I followed that example) I stuck it in /etc/rc around the startup of other proxies, but there may be better places for it. Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/ Index: rc === RCS file: /cvs/src/etc/rc,v retrieving revision 1.498 diff -u -p -r1.498 rc --- rc 30 May 2017 12:04:26 - 1.498 +++ rc 3 Jun 2017 14:29:13 - @@ -549,7 +549,7 @@ if ifconfig lo0 inet6 >/dev/null 2>&1; t fi fi -start_daemon hostapd lpd smtpd slowcgi httpd ftpd +start_daemon hostapd lpd smtpd slowcgi httpd ftpd mcastproxy start_daemon ftpproxy ftpproxy6 tftpd tftpproxy identd inetd rarpd bootparamd start_daemon rbootd mopd vmd spamd spamlogd sndiod echo '.' Index: rc.conf === RCS file: /cvs/src/etc/rc.conf,v retrieving revision 1.216 diff -u -p -r1.216 rc.conf --- rc.conf 30 May 2017 12:04:26 - 1.216 +++ rc.conf 3 Jun 2017 14:27:48 - @@ -38,6 +38,7 @@ ldattach_flags=NO # for normal use: "[op ldomd_flags=NO ldpd_flags=NO lpd_flags=NO # for normal use: "" (or "-l" for debugging) +mcastproxy_flags=NO mopd_flags=NO mrouted_flags=NO # be sure to enable multicast below npppd_flags=NO Index: rc.d/mcastproxy === RCS file: rc.d/mcastproxy diff -N rc.d/mcastproxy --- /dev/null 1 Jan 1970 00:00:00 - +++ rc.d/mcastproxy 3 Jun 2017 14:26:53 - @@ -0,0 +1,11 @@ +#!/bin/sh +# +# $OpenBSD$ + +daemon="/usr/sbin/mcast-proxy" + +. /etc/rc.d/rc.subr + +rc_reload=NO + +rc_cmd $1
chmod.1: Correct =X behaviour
=X actually works quite fine despite the mentioned condition: $ touch f; mkdir d $ chmod =X f d $ ls -ld f d d--x--x--x 2 kle wheel 512 Jun 3 15:11 d/ -- 1 kle wheel0 Jun 3 15:11 f One of the given examples has been updated to reflect this. Whether to implement/fix the desired(?) limitation is another question. Index: chmod.1 === RCS file: /cvs/src/bin/chmod/chmod.1,v retrieving revision 1.41 diff -u -p -r1.41 chmod.1 --- chmod.1 31 Dec 2015 23:38:16 - 1.41 +++ chmod.1 3 Jun 2017 13:10:02 - @@ -287,15 +287,6 @@ Execute/search bits. .It X The execute/search bits if the file is a directory or any of the execute/search bits are set in the original (unmodified) mode. -Operations with the -.Ar perm -symbol -.Sq X -are only meaningful in conjunction with the -.Ar op -symbol -.Sq + , -and are ignored in all other cases. .It u User permission bits in the mode of the original file. .It g @@ -333,7 +324,7 @@ Deny write permission to group and other Set the read and write permissions to the usual defaults, but retain any execute permissions that are currently set: .Pp -.Dl $ chmod =rw,+X file +.Dl $ chmod =rwX file .Pp Make a directory or file searchable/executable by everyone if it is already searchable/executable by anyone:
Makefile: Use -exec not xargs(1) with find(1)
-exec has been around since 2012 is cleaner and shorter, I don't see why
xargs(1) should be used for such simple cases. Besides that don't walk
the tree twice.
Index: include/Makefile
===
RCS file: /cvs/src/include/Makefile,v
retrieving revision 1.219
diff -u -p -r1.219 Makefile
--- include/Makefile17 Apr 2017 15:53:21 - 1.219
+++ include/Makefile3 Jun 2017 12:48:19 -
@@ -100,10 +100,9 @@ includes:
cd ${.CURDIR}/$$i && ${RUN_MAKE}; \
done
chown -RP ${BINOWN}:${BINGRP} ${DESTDIR}/usr/include
- find ${DESTDIR}/usr/include -type f -print0 | \
- xargs -0r chmod a=r
- find ${DESTDIR}/usr/include \( -type d -o -type l \) -print0 | \
- xargs -0r chmod -h u=rwx,go=rx
+ find ${DESTDIR}/usr/include \
+ \( -type f -exec chmod a=r {} + \) -o \
+ \( \( -type d -o -type l \) -exec chmod -h u=rwx,go=rx {} + \)
copies:
@echo copies: ${LDIRS}
Index: share/zoneinfo/Makefile
===
RCS file: /cvs/src/share/zoneinfo/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- share/zoneinfo/Makefile 24 Nov 2016 14:38:30 - 1.11
+++ share/zoneinfo/Makefile 3 Jun 2017 12:48:19 -
@@ -81,8 +81,9 @@ realinstall: ${DATA} ${REDO} ${YEARISTYP
(cd ${.CURDIR}/datfiles; \
${ZIC} -y ${YEARISTYPECOPY} -d ${TZDIR} -p ${POSIXRULES})
chown -R ${BINOWN}:${BINGRP} ${TZDIR}
- find ${TZDIR} -type f -print0 | xargs -0r chmod a=r
- find ${TZDIR} -type d -print0 | xargs -0r chmod a=rx
+ find ${TZDIR} \
+ \( -type f -exec chmod a=r {} + \) -o \
+ \( -type d -exec chmod a=rx {} + \)
${INSTALL} -c -o root -g bin -m 644 ${.CURDIR}/datfiles/iso3166.tab \
${DESTDIR}/usr/share/misc
${INSTALL} -c -o root -g bin -m 644 ${.CURDIR}/datfiles/zone.tab \
Re: FreeType 2.8
On Mon, May 29, 2017 at 05:10:11PM +0200, David Coppa wrote: > > Here's the update to freetype-2.8 (also attached). > > As usual, please test and/or put it in a bulk build... > Hi, This looks good to me. Note that it "fixes" the vertical spacing issue in xterm with some truetype fonts (DejaVu Sans Mono in my case), I no longer need need to set 'XTerm.*.scaleHeight: 1.1' in my X resources to avoid having '_' and other low parts of glyphs beeing hidden at the bottom of windows. >From my point of view it's a good thing, but other users may be surprised. It may be a consequence of the new "slight" anti-aliasing algorithm (which I'm using), but there are many other changes in ChangeLog that may affect glyph heights. -- Matthieu Herrb
[patch/bgpctl] Add support for extended communities
Hello,
Here is a patch to allow usage of extended communities with bgpctl :
bgpctl show ip bgp ext-community rt 10:10
bgpctl netw add 2001:db8:1::/64 ext soo 10:50
Denis
Index: bgpctl/bgpctl.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.195
diff -u -p -r1.195 bgpctl.c
--- bgpctl/bgpctl.c 31 May 2017 10:48:06 - 1.195
+++ bgpctl/bgpctl.c 3 Jun 2017 11:25:00 -
@@ -261,6 +261,11 @@ main(int argc, char *argv[])
sizeof(res->community));
type = IMSG_CTL_SHOW_RIB_COMMUNITY;
}
+ if (res->extcommunity.flags == EXT_COMMUNITY_FLAG_VALID) {
+ memcpy(, >extcommunity,
+ sizeof(res->extcommunity));
+ type = IMSG_CTL_SHOW_RIB_EXTCOMMUNITY;
+ }
if (res->large_community.as != COMMUNITY_UNSET &&
res->large_community.ld1 != COMMUNITY_UNSET &&
res->large_community.ld2 != COMMUNITY_UNSET) {
Index: bgpctl/parser.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/parser.c,v
retrieving revision 1.77
diff -u -p -r1.77 parser.c
--- bgpctl/parser.c 14 Feb 2017 13:13:23 - 1.77
+++ bgpctl/parser.c 3 Jun 2017 11:25:00 -
@@ -47,6 +47,8 @@ enum token_type {
RIBNAME,
SHUTDOWN_COMMUNICATION,
COMMUNITY,
+ EXTCOMMUNITY,
+ EXTCOM_SUBTYPE,
LARGE_COMMUNITY,
LOCALPREF,
MED,
@@ -94,12 +96,16 @@ static const struct token t_show_mrt_as[
static const struct token t_show_prefix[];
static const struct token t_show_ip[];
static const struct token t_show_community[];
+static const struct token t_show_extcommunity[];
+static const struct token t_show_ext_subtype[];
static const struct token t_show_largecommunity[];
static const struct token t_network[];
static const struct token t_network_show[];
static const struct token t_prefix[];
static const struct token t_set[];
static const struct token t_community[];
+static const struct token t_extcommunity[];
+static const struct token t_ext_subtype[];
static const struct token t_largecommunity[];
static const struct token t_localpref[];
static const struct token t_med[];
@@ -166,6 +172,7 @@ static const struct token t_show_rib[] =
{ ASTYPE, "peer-as", AS_PEER,t_show_rib_as},
{ ASTYPE, "empty-as", AS_EMPTY, t_show_rib},
{ KEYWORD, "community",NONE, t_show_community},
+ { KEYWORD, "ext-community", NONE, t_show_extcommunity},
{ KEYWORD, "large-community", NONE,t_show_largecommunity},
{ FLAG, "best", F_CTL_ACTIVE, t_show_rib},
{ FLAG, "selected", F_CTL_ACTIVE, t_show_rib},
@@ -288,6 +295,29 @@ static const struct token t_show_communi
{ ENDTOKEN, "", NONE, NULL}
};
+static const struct token t_show_extcommunity[] = {
+ { EXTCOM_SUBTYPE, "bdc", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "defgw",NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "esi-lab", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "esi-rt", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "l2vid",NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "mac-mob", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "odi", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "ort", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "ori", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "ovs", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "rt", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "soo", NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "srcas",NONE, t_show_ext_subtype},
+ { EXTCOM_SUBTYPE, "vrfri",NONE, t_show_ext_subtype},
+ { ENDTOKEN, "", NONE, NULL}
+};
+
+static const struct token t_show_ext_subtype[] = {
+ { EXTCOMMUNITY, "", NONE, t_show_rib},
+ { ENDTOKEN, "", NONE, NULL}
+};
+
static const struct token t_show_largecommunity[] = {
{ LARGE_COMMUNITY, "", NONE, t_show_rib},
{ ENDTOKEN, "", NONE, NULL}
@@ -317,6 +347,7 @@ static const struct token t_network_show
static const struct token t_set[] = {
{ NOTOKEN, "", NONE, NULL},
{ KEYWORD, "community",NONE, t_community},
+ { KEYWORD, "ext-community",NONE, t_extcommunity},
{ KEYWORD, "large-community", NONE, t_largecommunity},
