Re: Add wsfont.9, documenting the wsfont subsystem
On Tue, Nov 13, 2018 at 11:05:27PM +0100, Frederic Cambus wrote:
> Hi tech@,
>
> Here is a diff to add wsfont.9, documenting the wsfont subsystem.
>
> This is wsfont.9 revision 1.18 from NetBSD with the following changes:
>
> - Add $Mdocdate$ marker
> - Remove documentation for wsfont_matches() which we don't have
> - Remove wsfont_find() arguments which we don't have
> - Add missing arguments for wsfont_lock() which NetBSD doesn't have
> - Modify wsfont_enum() signature to match our implementation
> - Modify the wsdisplay_font structure to add the index and cookie members
> which NetBSD doesn't have
> - Removed some macros for font encoding we do not support anymore
> - Removed and corrected stuff which doesn't apply to us because
> the codebases have diverged
>
> Comments? OK?
>
morning.
the page reads ok, but it should really be named after one of the
actual functions and "wsfont" removed from NAME, in keeping with other
pages.
jmc
> Index: share/man/man9/wsfont.9
> ===
> RCS file: share/man/man9/wsfont.9
> diff -N share/man/man9/wsfont.9
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ share/man/man9/wsfont.9 13 Nov 2018 21:57:35 -
> @@ -0,0 +1,191 @@
> +.\" $OpenBSD$
> +.\" $NetBSD: wsfont.9,v 1.18 2012/01/13 23:09:51 wiz Exp $
> +.\"
> +.\" Copyright (c) 2001 The NetBSD Foundation, Inc.
> +.\" All rights reserved.
> +.\"
> +.\" This code is derived from software contributed to The NetBSD Foundation
> +.\" by Gregory McGarry.
> +.\"
> +.\" Redistribution and use in source and binary forms, with or without
> +.\" modification, are permitted provided that the following conditions
> +.\" are met:
> +.\" 1. Redistributions of source code must retain the above copyright
> +.\"notice, this list of conditions and the following disclaimer.
> +.\" 2. Redistributions in binary form must reproduce the above copyright
> +.\"notice, this list of conditions and the following disclaimer in the
> +.\"documentation and/or other materials provided with the distribution.
> +.\"
> +.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
> +.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> LIMITED
> +.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> PARTICULAR
> +.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
> +.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> +.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> +.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> +.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> +.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> +.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> +.\" POSSIBILITY OF SUCH DAMAGE.
> +.\"
> +.Dd $Mdocdate$
> +.Dt WSFONT 9
> +.Os
> +.Sh NAME
> +.Nm wsfont ,
> +.Nm wsfont_init ,
> +.Nm wsfont_find ,
> +.Nm wsfont_add ,
> +.Nm wsfont_remove ,
> +.Nm wsfont_enum ,
> +.Nm wsfont_lock ,
> +.Nm wsfont_unlock ,
> +.Nm wsfont_map_unichar
> +.Nd wscons font support
> +.Sh SYNOPSIS
> +.In dev/wscons/wsconsio.h
> +.In dev/wsfont/wsfont.h
> +.Ft void
> +.Fn wsfont_init "void"
> +.Ft int
> +.Fn wsfont_find "const char *name" "int width" "int height" "int stride"
> +.Ft int
> +.Fn wsfont_add "struct wsdisplay_font *font" "int copy"
> +.Ft int
> +.Fn wsfont_remove "int cookie"
> +.Ft void
> +.Fn wsfont_enum "int (*cb)(void *, struct wsdisplay_font *)" "void *cbarg"
> +.Ft int
> +.Fn wsfont_lock "int cookie" "struct wsdisplay_font **ptr" "int bitorder" \
> +"int byteorder"
> +.Ft int
> +.Fn wsfont_unlock "int cookie"
> +.Ft int
> +.Fn wsfont_map_unichar "struct wsdisplay_font *font" "int c"
> +.Sh DESCRIPTION
> +The
> +.Nm
> +module is a component of the wscons
> +.\" .Xr wscons 9
> +framework to provide access to display fonts.
> +Fonts may be loaded dynamically into the kernel or included statically
> +in the kernel at compile time.
> +Display drivers which emulate a glass-tty console on a bit-mapped
> +display can add, remove and find fonts for use by device-dependent
> +blitter operations.
> +.Pp
> +The primary data type for manipulating fonts is the
> +.Em wsdisplay_font
> +structure in
> +.Pa dev/wscons/wsconsio.h :
> +.Bd -literal
> +struct wsdisplay_font {
> + char name[WSFONT_NAME_SIZE];/* font name */
> + int index;
> + int firstchar;
> + int numchars; /* size of font table */
> + int encoding; /* font encoding */
> + u_int fontwidth;/* character width */
> + u_int fontheight; /* character height */
> + u_int stride;
> + int bitorder;
> + int byteorder;
> + void *cookie;
> + void *data; /* pointer to font table */
> +};
> +.Ed
> +.Pp
> +The maximum font table size is
>
s_client.c typo
Index: s_client.c === RCS file: /cvs/src/usr.bin/openssl/s_client.c,v retrieving revision 1.36 diff -u -p -u -r1.36 s_client.c --- s_client.c 11 Feb 2018 20:03:10 - 1.36 +++ s_client.c 14 Nov 2018 03:51:08 - @@ -891,7 +891,7 @@ re_start: BIO_free(fbio); if (!foundit) BIO_printf(bio_err, - "didn't found STARTTLS in server response," + "didn't find STARTTLS in server response," " try anyway...\n"); BIO_printf(sbio, ". STARTTLS\r\n"); BIO_read(sbio, sbuf, BUFSIZZ);
tunnels, ecn, and ipv4 header checksums
while looking at outgoing ttl processing and rfc 6040, i noted that gif
and gre patched a packets ttl, but didn't update the checksum on the
packet.
i think there's two issues here. firstly, we need to update the checksum
when the packet is patched, but only for v4, and secondly, we should
clear the csum_flags on an mbuf after the first decap.
this patch addresses the first issue. i have removed the ttl patching in
gre and gif, but gif and the ipip code still patch the ecn on a packet.
gif did not update the v4 checksum, and ipip recalculates the whole
checksum.
the stuff procter worked on in pf shows that you can do a small
update to the checksum rather than recalcuate the whole thing. this
adds a function to the ecn code that does just that for tos field,
which is where the ecn is store.
it also updates gif and ipip to use it.
ok?
Index: netinet/ip_ecn.c
===
RCS file: /cvs/src/sys/netinet/ip_ecn.c,v
retrieving revision 1.8
diff -u -p -r1.8 ip_ecn.c
--- netinet/ip_ecn.c24 Sep 2016 14:51:37 - 1.8
+++ netinet/ip_ecn.c14 Nov 2018 01:40:22 -
@@ -154,3 +154,19 @@ ip_ecn_egress(int mode, u_int8_t *outer,
}
return (1);
}
+
+void
+ip_tos_patch(struct ip *ip, uint8_t tos)
+{
+ uint16_t old;
+ uint16_t new;
+ uint32_t x;
+
+ old = htons(ip->ip_tos);
+ new = htons(tos);
+
+ ip->ip_tos = tos;
+
+ x = ip->ip_sum + old - new;
+ ip->ip_sum = (x) + (x >> 16);
+}
Index: netinet/ip_ecn.h
===
RCS file: /cvs/src/sys/netinet/ip_ecn.h,v
retrieving revision 1.6
diff -u -p -r1.6 ip_ecn.h
--- netinet/ip_ecn.h15 Mar 2012 16:37:11 - 1.6
+++ netinet/ip_ecn.h14 Nov 2018 01:40:22 -
@@ -47,5 +47,6 @@
#if defined(_KERNEL)
extern void ip_ecn_ingress(int, u_int8_t *, u_int8_t *);
extern int ip_ecn_egress(int, u_int8_t *, u_int8_t *);
+void ip_tos_patch(struct ip *, uint8_t);
#endif /* _KERNEL */
#endif /* _NETINET_IP_ECN_H_ */
Index: netinet/ip_ipip.c
===
RCS file: /cvs/src/sys/netinet/ip_ipip.c,v
retrieving revision 1.88
diff -u -p -r1.88 ip_ipip.c
--- netinet/ip_ipip.c 28 Aug 2018 15:15:02 - 1.88
+++ netinet/ip_ipip.c 14 Nov 2018 01:40:22 -
@@ -239,16 +239,14 @@ ipip_input_if(struct mbuf **mp, int *off
itos = ip->ip_tos;
mode = m->m_flags & (M_AUTH|M_CONF) ?
ECN_ALLOWED_IPSEC : ECN_ALLOWED;
- if (!ip_ecn_egress(mode, , >ip_tos)) {
+ if (!ip_ecn_egress(mode, , )) {
DPRINTF(("%s: ip_ecn_egress() failed\n", __func__));
ipipstat_inc(ipips_pdrops);
goto bad;
}
/* re-calculate the checksum if ip_tos was changed */
- if (itos != ip->ip_tos) {
- ip->ip_sum = 0;
- ip->ip_sum = in_cksum(m, hlen);
- }
+ if (itos != ip->ip_tos)
+ ip_tos_patch(ip, itos);
break;
#ifdef INET6
case IPPROTO_IPV6:
Index: net/if_gif.c
===
RCS file: /cvs/src/sys/net/if_gif.c,v
retrieving revision 1.121
diff -u -p -r1.121 if_gif.c
--- net/if_gif.c14 Nov 2018 01:30:38 - 1.121
+++ net/if_gif.c14 Nov 2018 01:40:22 -
@@ -805,7 +805,7 @@ gif_input(struct gif_tunnel *key, struct
if (ip_ecn_egress(ECN_ALLOWED, , ) == 0)
goto drop;
- ip->ip_tos = itos;
+ ip_tos_patch(ip, itos);
m->m_pkthdr.ph_family = AF_INET;
input = ipv4_input;
Add wsfont.9, documenting the wsfont subsystem
Hi tech@,
Here is a diff to add wsfont.9, documenting the wsfont subsystem.
This is wsfont.9 revision 1.18 from NetBSD with the following changes:
- Add $Mdocdate$ marker
- Remove documentation for wsfont_matches() which we don't have
- Remove wsfont_find() arguments which we don't have
- Add missing arguments for wsfont_lock() which NetBSD doesn't have
- Modify wsfont_enum() signature to match our implementation
- Modify the wsdisplay_font structure to add the index and cookie members
which NetBSD doesn't have
- Removed some macros for font encoding we do not support anymore
- Removed and corrected stuff which doesn't apply to us because
the codebases have diverged
Comments? OK?
Index: share/man/man9/wsfont.9
===
RCS file: share/man/man9/wsfont.9
diff -N share/man/man9/wsfont.9
--- /dev/null 1 Jan 1970 00:00:00 -
+++ share/man/man9/wsfont.9 13 Nov 2018 21:57:35 -
@@ -0,0 +1,191 @@
+.\"$OpenBSD$
+.\" $NetBSD: wsfont.9,v 1.18 2012/01/13 23:09:51 wiz Exp $
+.\"
+.\" Copyright (c) 2001 The NetBSD Foundation, Inc.
+.\" All rights reserved.
+.\"
+.\" This code is derived from software contributed to The NetBSD Foundation
+.\" by Gregory McGarry.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
+.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
+.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+.\" POSSIBILITY OF SUCH DAMAGE.
+.\"
+.Dd $Mdocdate$
+.Dt WSFONT 9
+.Os
+.Sh NAME
+.Nm wsfont ,
+.Nm wsfont_init ,
+.Nm wsfont_find ,
+.Nm wsfont_add ,
+.Nm wsfont_remove ,
+.Nm wsfont_enum ,
+.Nm wsfont_lock ,
+.Nm wsfont_unlock ,
+.Nm wsfont_map_unichar
+.Nd wscons font support
+.Sh SYNOPSIS
+.In dev/wscons/wsconsio.h
+.In dev/wsfont/wsfont.h
+.Ft void
+.Fn wsfont_init "void"
+.Ft int
+.Fn wsfont_find "const char *name" "int width" "int height" "int stride"
+.Ft int
+.Fn wsfont_add "struct wsdisplay_font *font" "int copy"
+.Ft int
+.Fn wsfont_remove "int cookie"
+.Ft void
+.Fn wsfont_enum "int (*cb)(void *, struct wsdisplay_font *)" "void *cbarg"
+.Ft int
+.Fn wsfont_lock "int cookie" "struct wsdisplay_font **ptr" "int bitorder" \
+"int byteorder"
+.Ft int
+.Fn wsfont_unlock "int cookie"
+.Ft int
+.Fn wsfont_map_unichar "struct wsdisplay_font *font" "int c"
+.Sh DESCRIPTION
+The
+.Nm
+module is a component of the wscons
+.\" .Xr wscons 9
+framework to provide access to display fonts.
+Fonts may be loaded dynamically into the kernel or included statically
+in the kernel at compile time.
+Display drivers which emulate a glass-tty console on a bit-mapped
+display can add, remove and find fonts for use by device-dependent
+blitter operations.
+.Pp
+The primary data type for manipulating fonts is the
+.Em wsdisplay_font
+structure in
+.Pa dev/wscons/wsconsio.h :
+.Bd -literal
+struct wsdisplay_font {
+ char name[WSFONT_NAME_SIZE];/* font name */
+ int index;
+ int firstchar;
+ int numchars; /* size of font table */
+ int encoding; /* font encoding */
+ u_int fontwidth;/* character width */
+ u_int fontheight; /* character height */
+ u_int stride;
+ int bitorder;
+ int byteorder;
+ void *cookie;
+ void *data; /* pointer to font table */
+};
+.Ed
+.Pp
+The maximum font table size is
+.Em WSDISPLAY_MAXFONTSZ .
+.Pp
+The
+.Nm
+framework supports fonts with the following encodings:
+.Bl -tag -width compact
+.It Dv WSDISPLAY_FONTENC_ISO
+ISO-encoded fonts.
+.It Dv WSDISPLAY_FONTENC_IBM
+IBM-encoded fonts commonly available for IBM CGA, EGA and VGA display
+adapters.
+.El
+.Sh FUNCTIONS
+.Bl -tag -width compact
+.It Fn wsfont_init "void"
+Initialise the font list with the built-in fonts.
+.It Fn wsfont_find "name" "width" "height"
mg: fix undo transpose-paragraph
Currently undoing transpose-paragraph doesn't work as expected. This diff fixes that. ok? Index: paragraph.c === RCS file: /cvs/src/usr.bin/mg/paragraph.c,v retrieving revision 1.45 diff -u -p -r1.45 paragraph.c --- paragraph.c 6 Sep 2016 16:25:47 - 1.45 +++ paragraph.c 13 Nov 2018 21:20:48 - @@ -338,6 +338,8 @@ transposepara(int f, int n) if (n == 0) return (TRUE); + undo_boundary_enable(FFRAND, 0); + /* find a paragraph, set mark, then goto the end */ gotobop(FFRAND, 1); curwp->w_markp = curwp->w_dotp; @@ -364,6 +366,8 @@ transposepara(int f, int n) return (FALSE); } (void)yank(FFRAND, 1); + + undo_boundary_enable(FFRAND, 1); return (TRUE); }
Re: [macppc] BSS PLT format and ports-clang
Thanks for mentioning -msecure-plt. I grep'd our current LLVM source, and the option isn't here. But it has been added since then [1], so i'll try adding patches that enables it. Charlène. [1] https://reviews.llvm.org/D44921 On Tue, 13 Nov 2018 14:42:55 -0500 Raul Miller wrote: > What happens if you build with -msecure-plt or -fno-plt? > > Thanks, > > -- > Raul > > On Tue, Nov 13, 2018 at 2:39 PM Charlene Wendling > wrote: > > > > Hi, > > > > bcallah@ (mostly) and i (who owns the hardware and builds) are > > currently trying to get llvm/clang working on macpcc. That would > > allow us to try unbreaking many ports on this platform, especially > > those that depend on webkitgtk4. > > > > It currently builds [1] and installs [2] properly. I then tried to > > build a port with clang, successfully, but it fails at runtime. > > This is what i get, even with a simple "hello world", on OpenBSD > > 6.4-current (GENERIC) > > #263 (2018/11/09): > > > > $ ./hello > > ld.so: hello: unsupported insecure BSS PLT object > > > > Recently, support for BSS PLT format has been deleted [3]. > > > > Is it possible to fix clang so we get binaries that work at runtime? > > > > Reintroducing BSS PLT is probably not the best solution, and is only > > considered a "decent guess" to fix the issue. > > > > Your opinions are welcome! > > > > Charlène. > > > > > > [1] https://transfer.sh/So4dg/llvm.working.build.log > > [2] > > https://bsd.network/system/media_attachments/files/000/613/163/original/4279771bd01ce556.png?1542113789 > > [3] https://marc.info/?l=openbsd-cvs=154174152917901=2 > > >
Re: [macppc] BSS PLT format and ports-clang
What happens if you build with -msecure-plt or -fno-plt? Thanks, -- Raul On Tue, Nov 13, 2018 at 2:39 PM Charlene Wendling wrote: > > Hi, > > bcallah@ (mostly) and i (who owns the hardware and builds) are currently > trying to get llvm/clang working on macpcc. That would allow us to try > unbreaking many ports on this platform, especially those that depend on > webkitgtk4. > > It currently builds [1] and installs [2] properly. I then tried to build > a port with clang, successfully, but it fails at runtime. This is what i > get, even with a simple "hello world", on OpenBSD 6.4-current (GENERIC) > #263 (2018/11/09): > > $ ./hello > ld.so: hello: unsupported insecure BSS PLT object > > Recently, support for BSS PLT format has been deleted [3]. > > Is it possible to fix clang so we get binaries that work at runtime? > > Reintroducing BSS PLT is probably not the best solution, and is only > considered a "decent guess" to fix the issue. > > Your opinions are welcome! > > Charlène. > > > [1] https://transfer.sh/So4dg/llvm.working.build.log > [2] > https://bsd.network/system/media_attachments/files/000/613/163/original/4279771bd01ce556.png?1542113789 > [3] https://marc.info/?l=openbsd-cvs=154174152917901=2 >
[macppc] BSS PLT format and ports-clang
Hi, bcallah@ (mostly) and i (who owns the hardware and builds) are currently trying to get llvm/clang working on macpcc. That would allow us to try unbreaking many ports on this platform, especially those that depend on webkitgtk4. It currently builds [1] and installs [2] properly. I then tried to build a port with clang, successfully, but it fails at runtime. This is what i get, even with a simple "hello world", on OpenBSD 6.4-current (GENERIC) #263 (2018/11/09): $ ./hello ld.so: hello: unsupported insecure BSS PLT object Recently, support for BSS PLT format has been deleted [3]. Is it possible to fix clang so we get binaries that work at runtime? Reintroducing BSS PLT is probably not the best solution, and is only considered a "decent guess" to fix the issue. Your opinions are welcome! Charlène. [1] https://transfer.sh/So4dg/llvm.working.build.log [2] https://bsd.network/system/media_attachments/files/000/613/163/original/4279771bd01ce556.png?1542113789 [3] https://marc.info/?l=openbsd-cvs=154174152917901=2
bgpd refactor community code
This is a large diff that changes the way communities are stored in
filters and filter_sets. Both standard communities and large communities
now share the same data structure for lookups and at the same time the
filters are extended to allow more then one community to match per rule
(currently the maximum is 3). I did leave extended communities outside for
now since this diff is already big enough but they will follow in a second
step.
So now filters like
deny to any large-community 196618:0:666 large-community 196618:0:3
deny to any community 13030:1016 community 13030:5
will work and match only if both communities are matched.
As a side effect the bgpctl show rib code is changed and there is no
longer a limitation that only one of the filter is allowed to be used.
In other words 'bgpctl show rib as 13030 community 1303:1036' will
work now.
Apart from that there should be no other visible change.
Please test and report back
--
:wq Claudio
PS: diff is against /usr/src since both bgpd and bgpctl need to be patched
Index: usr.sbin/bgpctl/bgpctl.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.223
diff -u -p -r1.223 bgpctl.c
--- usr.sbin/bgpctl/bgpctl.c1 Nov 2018 10:09:52 - 1.223
+++ usr.sbin/bgpctl/bgpctl.c13 Nov 2018 13:43:04 -
@@ -173,14 +173,7 @@ main(int argc, char *argv[])
ribreq.prefix = res->addr;
ribreq.prefixlen = res->prefixlen;
}
- if (res->community.as != COMMUNITY_UNSET &&
- res->community.type != COMMUNITY_UNSET)
- ribreq.community = res->community;
- if (res->large_community.as != COMMUNITY_UNSET &&
- res->large_community.ld1 != COMMUNITY_UNSET &&
- res->large_community.ld2 != COMMUNITY_UNSET)
- ribreq.large_community = res->large_community;
- /* XXX extended communities missing? */
+ /* XXX currently no communities support */
ribreq.neighbor = neighbor;
ribreq.aid = res->aid;
ribreq.flags = res->flags;
@@ -277,30 +270,17 @@ main(int argc, char *argv[])
case SHOW_RIB:
bzero(, sizeof(ribreq));
type = IMSG_CTL_SHOW_RIB;
- if (res->as.type != AS_UNDEF) {
- ribreq.as = res->as;
- type = IMSG_CTL_SHOW_RIB_AS;
- }
if (res->addr.aid) {
ribreq.prefix = res->addr;
ribreq.prefixlen = res->prefixlen;
type = IMSG_CTL_SHOW_RIB_PREFIX;
}
- if (res->community.as != COMMUNITY_UNSET &&
- res->community.type != COMMUNITY_UNSET) {
+ if (res->as.type != AS_UNDEF)
+ ribreq.as = res->as;
+ if (res->community.type != COMMUNITY_TYPE_NONE)
ribreq.community = res->community;
- type = IMSG_CTL_SHOW_RIB_COMMUNITY;
- }
- if (res->extcommunity.flags == EXT_COMMUNITY_FLAG_VALID) {
+ if (res->extcommunity.flags == EXT_COMMUNITY_FLAG_VALID)
ribreq.extcommunity = 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) {
- ribreq.large_community = res->large_community;
- type = IMSG_CTL_SHOW_RIB_LARGECOMMUNITY;
- }
ribreq.neighbor = neighbor;
strlcpy(ribreq.rib, res->rib, sizeof(ribreq.rib));
ribreq.aid = res->aid;
@@ -399,14 +379,7 @@ main(int argc, char *argv[])
ribreq.prefix = res->addr;
ribreq.prefixlen = res->prefixlen;
}
- if (res->community.as != COMMUNITY_UNSET &&
- res->community.type != COMMUNITY_UNSET)
- ribreq.community = res->community;
- if (res->large_community.as != COMMUNITY_UNSET &&
- res->large_community.ld1 != COMMUNITY_UNSET &&
- res->large_community.ld2 != COMMUNITY_UNSET)
- ribreq.large_community = res->large_community;
- /* XXX ext communities missing? */
+ /* XXX currently no community support */
ribreq.neighbor = neighbor;
ribreq.aid = res->aid;
ribreq.flags = res->flags;
Index: usr.sbin/bgpctl/parser.c
===
RCS file:
Re: /usr/share/calendar/calendar.christian - two entries for "First Sunday of Advent (4th Sunday before Christmas)"
On Mon, Nov 12, 2018 at 07:00:31AM +, Jason McIntyre wrote: > On Sun, Nov 11, 2018 at 11:03:35PM +, Raf Czlonka wrote: > > It's that magical time of the year again :^) > > > > Anyone? > > > > R. > > > > morning. > > [...] unfortunately calendar doesn;t handle such dates well. This fact is documented for calendar.christian. calendar.1 says: > calendar.christianChristian holidays (should be updated yearly by the > local system administrator so that roving holidays > are set correctly for the current year). So the dates are included there to demonstrate the variability and the intent is that your admin update the file periodically (how quaint!). > firstly, the BUGS entry: maybe we should just say that calendar doesn;t > handle all holidays, rather than singling out jewish ones. Something like "calendar doesn't handle roving holidays..." and perhaps provide an example or two could work. It think it's written that way because there are a number of Jewish holidays that "move around", so to speak. > the solution to your question - someone writes code to handle this, or > someone steps up to maintain the file. it won;t be me, i'm afraid. I think the priority of certain keywords could be adjusted to make calendar produce results more in line with what a user might expect. Unclear if such a change is even allowed given the software's well established behavior, but currently the entry 11/ThuLast+3\tFirst Sunday of Advent yields November 15th. This happens because the parser prioritizes "Thu" and +3 over "ThuLast". Stepping through it in the debugger, "Last" is never even looked at. So you get the 3rd thursday in November, i.e. Nov 15th. But intuitively you ought to get 3 days after the last Thursday in November, i.e. (this year) December 2nd. I'm going to give making this change a shot just for the hell of it. And if it's too late to change the behavior, *shrugs*. > > On Sun, Nov 12, 2017 at 08:11:04AM GMT, Raf Czlonka wrote: > > > Hi all, > > > > > > I've just noticed something strange in the > > > /usr/share/calendar/calendar.christian file, namely: > > > > > > 11/SunLast First Sunday of Advent (4th Sunday before Christmas) > > > 12/SunFirst First Sunday of Advent (4th Sunday before Christmas) > > > > > > Obviously, in any given year either is true - not both. > > > > > > I do understand the intent - the beginning of Advent will either > > > be on the last Sunday of November or the first Sunday of December > > > depending which day of the week Christmas Day falls on. > > > > > > Calculating it isn't difficult - last Thursday of November + 3 days - > > > but I'm not sure whether adding any additional code to calendar(1) > > > is desirable. > > > > > > I don't know what the best solution to the above is as currently, > > > as it stands, these entries are confusing - at first glance the > > > above looks like a bug and after figuring out it isn't one, I'm > > > sill none the wise which one it is without consulting another > > > calendar. > > > > > > Adding code, modifying the above entries or an additional entry in > > > the BUGS section in the manual. What are your thought? > > > > > > Best regards, > > > > > > Raf > > >
Re: 6.4 - RX not working on new supported BCM574xx (bnxt)
FYI, the NIC is working well on Centos/Vmware OS. >From all of your findings, does the driver need to be updated ? Can anyone has resolve this issue? Many thanks Luthing -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-dev-tech-f151936.html
