Preferred TERM for pkg_add
Hello, There was recently a bug report opened for the ansible module openbsd_pkg, where someone was getting errors due to pkg_add disliking their TERM setting: https://github.com/ansible-collections/community.general/issues/5738 Basically they are running TERM=xterm-kitty locally, which makes pkg_add disable the progress meter, easily testable like so: ``` orbb# nmap ksh: nmap: not found orbb# TERM=xterm-kitty pkg_add nmap No progress meter: failed termcap lookup on xterm-kitty quirks-6.42 signed on 2022-12-09T12:59:38Z orbb# nmap Nmap 7.91 ( https://nmap.org ) [...] ``` I can agree with the reporter that it would be better to have the ansible module "do the right thing" and set some lowest common denominator TERM instead of depending on the whims of a local environment. From what I can tell both "dumb" (as suggested by the reporter) and "unknown" seems to still print the progress bar: ``` # TERM=unknown pkg_delete nmap nmap-7.91p2: ok Read shared items: ok ``` ... and: ``` # TERM=dumb pkg_add nmap quirks-6.42 signed on 2022-12-09T12:59:38Z nmap-7.91p2: ok ``` Basically I am asking if any specific choice of a TERM would be preferred if we would make openbsd_pkg always set one of them for the different pkg_* tools. Regards, Patrik Lundin
Re: [PATCH] Azalia bug in codec Realtek ALC892
Jose Maldonado writes:
> Right now I'm using OBSD 7.2 (my first time in OBSD) and the only issue
> is my onboard audio. The audio randomly stuck (listen music or not, with
> high CPU use or not) and only a hard reboot give me back audio to next
> stuck.
>
> In dmesg don´t show nothing, but sndiod - give me this output:
>
> * snd/0 watchdog timeout *
>
> The error appear in debug info and my audio is gone. The issue is not
> new more info in this links:
>
> https://www.reddit.com/r/openbsd/comments/mybklx/keep_losing_audio_with_azalia_on_current/
>
> https://www.mail-archive.com/tech@openbsd.org/msg46701.html
>
> https://deftly.net/posts/2018-10-15-openbsd-on-lenovo-a485.html
...
> PATCH:
>
> Index: azalia_codec.c
> ===
> RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
> retrieving revision 1.189
> diff -u -p -u -r1.189 azalia_codec.c
> --- azalia_codec.c8 Sep 2022 01:35:39 - 1.189
> +++ azalia_codec.c2 Jan 2023 19:42:28 -
> @@ -312,6 +312,9 @@ azalia_codec_init_vtbl(codec_t *this)
> break;
> case 0x10ec0892:
> this->name = "Realtek ALC892";
> + if (this->subid == 0x1462ec95) {
> + this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
> + }
> break;
> case 0x10ec0897:
> this->name = "Realtek ALC897";
Thanks for the contribution Jose. The diff is OK gnezdo. Aaron, in case
you still have that hardware, maybe you would like to test/commit?
Thanks
Greg
Re: obsd install initial boot process slowed down
Le 04/01/2023 14:22, Stuart Henderson a écrit : On 2023-01-04, Nick Holland wrote: On 1/4/23 01:13, Sylvain Saboua wrote: Hi, my openbsed (encrypted) install is functionning really well, apart from one thing, that would signal a bug or smth: The initial boot process, right after I type the security key in, which displays cyphers aligning in between rotating semicolumns (I hope this is clear), is slow, on this install. Nope. Totally not clear. Sounds like the -\|/ spinner when the boot loader loads the kernel. YES! That's it. What platform, what hardware, dmesg. Sent dmesg in separate previous mail. Also...no idea what you are talking about. First boot after install? every boot? during install? EVERY boot (ever & since install) EXACTLY What are you seeing on the screen when it is "slow"? And what does "slow" mean? I see animated/rotating wheels with cyphers in between, displaying one after the other. The wheel rotates for a longer time than other install when it just seems to load instantly one after the other. (I'll upload video & send link in next message) All good questions. Sure Cold boots only, or also warm boots? BOTH cold & warm boots. If a laptop, does it make any difference whether it's on power supply or internal battery? I mostly use this laptop as a desktop (I don't move or unplug it). (draft) I'll try with the battery unplugged but I doubt it will make a difference. EDIT: Did boot unplugged to send these emails, no difference. Is disk access slow after the OS has booted or is it just during boot? No, right after this process is over everything is fine. But slow initial boot process is the main problem. Did you try without encryption and if so, was that slow too? I use openbsd since about 2018. Not as daily driver yet, but I've been getting more and more minimalistic. Started with ed or now vi also, suckless' st & surf, tmux, man ... trying to learn it all. I've had this problem randomly depending on the installs. The first 4 or so, unencrypted, install, used to be mostly fine. The previous install was encrypted and fine, but I had to reinstall it for another reason (dualbooting conflict, there is a thread here about that. Might help to upload a video to a sharing site and post a link to it. I'll do that. Link in next mail. Thank you -- Sylvain Saboua from webmail
[v2] sparc64: switch to clockintr
Now that we have resolved the problems with the UltraSPARC IIe, let's
try the clockintr switch again. For reference, here is v1:
https://marc.info/?l=openbsd-tech=166776418803680=2
The major difference in v2 is that we send_softint() if we miss when
setting the comparison register instead of spinning and retrying. I
didn't do this in v1 because I didn't know it was an option.
This is untested. I'm looking for tests on UltraSPARC I or UltraSPARC
II (%TICK), UltraSPARC IIe (Hummingbird PCI bridge %STICK), and
something newer (%STICK).
kettenis, kn: could one of you try this on a newer system? miod@ only
has the older stuff. mlarkin@ said he'd try it on the T4 but now he's
out of office.
Index: sys/arch/sparc64/include/cpu.h
===
RCS file: /cvs/src/sys/arch/sparc64/include/cpu.h,v
retrieving revision 1.100
diff -u -p -r1.100 cpu.h
--- sys/arch/sparc64/include/cpu.h 22 Oct 2022 20:09:41 - 1.100
+++ sys/arch/sparc64/include/cpu.h 5 Jan 2023 00:10:15 -
@@ -78,6 +78,7 @@
#include
#include
+#include
#include
#include
@@ -129,7 +130,7 @@ struct cpu_info {
int ci_want_resched;
int ci_handled_intr_level;
void*ci_intrpending[16][8];
- u_int64_t ci_tick;
+ struct clockintr_queue ci_queue;
struct intrhand ci_tickintr;
volatile intci_ddb_paused;
Index: sys/arch/sparc64/include/_types.h
===
RCS file: /cvs/src/sys/arch/sparc64/include/_types.h,v
retrieving revision 1.23
diff -u -p -r1.23 _types.h
--- sys/arch/sparc64/include/_types.h 5 Mar 2018 01:15:25 - 1.23
+++ sys/arch/sparc64/include/_types.h 5 Jan 2023 00:10:15 -
@@ -35,6 +35,8 @@
#ifndef _MACHINE__TYPES_H_
#define _MACHINE__TYPES_H_
+#define __HAVE_CLOCKINTR
+
#if defined(_KERNEL)
typedef struct label_t {
long val[2];
Index: sys/arch/sparc64/sparc64/clock.c
===
RCS file: /cvs/src/sys/arch/sparc64/sparc64/clock.c,v
retrieving revision 1.74
diff -u -p -r1.74 clock.c
--- sys/arch/sparc64/sparc64/clock.c29 Dec 2022 22:44:23 - 1.74
+++ sys/arch/sparc64/sparc64/clock.c5 Jan 2023 00:10:15 -
@@ -70,10 +70,12 @@
#include
#include
#include
+#include
#ifdef GPROF
#include
#endif
#include
+#include
#include
#include
@@ -132,37 +134,47 @@ struct timecounter sys_tick_timecounter
.tc_user = TC_SYS_TICK,
};
-/*
- * Statistics clock interval and variance, in usec. Variance must be a
- * power of two. Since this gives us an even number, not an odd number,
- * we discard one case and compensate. That is, a variance of 1024 would
- * give us offsets in [0..1023]. Instead, we take offsets in [1..1023].
- * This is symmetric about the point 512, or statvar/2, and thus averages
- * to that value (assuming uniform random numbers).
- */
-/* XXX fix comment to match value */
-int statvar = 8192;
-int statmin; /* statclock interval - 1/2*variance */
-
-static long tick_increment;
-
void tick_start(void);
void sys_tick_start(void);
void stick_start(void);
-void tick_rearm(uint64_t);
-void sys_tick_rearm(uint64_t);
-void stick_rearm(uint64_t);
-
inttickintr(void *);
intsys_tickintr(void *);
intstickintr(void *);
-intschedintr(void *);
-static struct intrhand level10 = { clockintr };
+uint64_t tick_nsec_cycle_ratio;
+uint64_t tick_nsec_max;
+
+void tick_rearm(void *, uint64_t);
+void tick_trigger(void *);
+
+const struct intrclock tick_intrclock = {
+ .ic_rearm = tick_rearm,
+ .ic_trigger = tick_trigger
+};
+
+uint64_t sys_tick_nsec_cycle_ratio;
+uint64_t sys_tick_nsec_max;
+
+void sys_tick_rearm(void *, uint64_t);
+void sys_tick_trigger(void *);
+
+const struct intrclock sys_tick_intrclock = {
+ .ic_rearm = sys_tick_rearm,
+ .ic_trigger = sys_tick_trigger
+};
+
+void stick_rearm(void *, uint64_t);
+void stick_trigger(void *);
+
+const struct intrclock stick_intrclock = {
+ .ic_rearm = stick_rearm,
+ .ic_trigger = stick_trigger
+};
+
+void sparc64_raise_clockintr(void);
+
static struct intrhand level0 = { tickintr };
-static struct intrhand level14 = { statintr };
-static struct intrhand schedint = { schedintr };
/*
* clock (eeprom) attaches at the sbus or the ebus (PCI)
@@ -466,7 +478,7 @@ timerattach(struct device *parent, struc
{
struct mainbus_attach_args *ma = aux;
u_int *va = ma->ma_address;
-
+#if 0
/*
* What we should have are 3 sets of registers that reside on
* different parts of SYSIO or PSYCHO. We'll use the prom
@@ -492,6 +504,8 @@ timerattach(struct device *parent, struc
printf(" ivec 0x%llx, 0x%llx\n", INTVEC(level10.ih_number),
Re: Remove remnants of removed diff -l option
On Wed, 04 Jan 2023 13:13:28 -0800, Nathan Houghton wrote: > This patch removes a few remnants of the unsupported diff -l > option from diff.c and the diff manual page. > > The diff.c usage() print is already correct, so no changes are > needed there. Thanks, committed. - todd
Remove remnants of removed diff -l option
Hi all,
This patch removes a few remnants of the unsupported diff -l
option from diff.c and the diff manual page.
The diff.c usage() print is already correct, so no changes are
needed there.
Thanks,
Nate
diff --git a/usr.bin/diff/diff.1 b/usr.bin/diff/diff.1
index 85a168d7740..e718e37ed61 100644
--- a/usr.bin/diff/diff.1
+++ b/usr.bin/diff/diff.1
@@ -46,24 +46,24 @@
.Op Fl L Ar label
.Ar file1 file2
.Nm diff
-.Op Fl abdilpTtw
+.Op Fl abdipTtw
.Op Fl I Ar pattern
.Op Fl L Ar label
.Fl C Ar number
.Ar file1 file2
.Nm diff
-.Op Fl abdiltw
+.Op Fl abditw
.Op Fl I Ar pattern
.Fl D Ar string
.Ar file1 file2
.Nm diff
-.Op Fl abdilpTtw
+.Op Fl abdipTtw
.Op Fl I Ar pattern
.Op Fl L Ar label
.Fl U Ar number
.Ar file1 file2
.Nm diff
-.Op Fl abdilNPprsTtw
+.Op Fl abdiNPprsTtw
.Oo
.Fl c | e | f |
.Fl n | q | u
@@ -466,7 +466,7 @@ utility is compliant with the
specification.
.Pp
The flags
-.Op Fl aDdIiLlNnPpqSsTtwXx
+.Op Fl aDdIiLNnPpqSsTtwXx
are extensions to that specification.
.Sh HISTORY
A
diff --git a/usr.bin/diff/diff.c b/usr.bin/diff/diff.c
index 5474199b435..8cf99595d18 100644
--- a/usr.bin/diff/diff.c
+++ b/usr.bin/diff/diff.c
@@ -43,7 +43,7 @@ struct stat stb1, stb2;
struct excludes *excludes_list;
regex_t ignore_re;
-#defineOPTIONS "0123456789abC:cdD:efhI:iL:lnNPpqrS:sTtU:uwX:x:"
+#defineOPTIONS "0123456789abC:cdD:efhI:iL:nNPpqrS:sTtU:uwX:x:"
static struct option longopts[] = {
{ "text", no_argument,0, 'a' },
{ "ignore-space-change",no_argument,0, 'b' },
--
2.37.3
efi(4): Support for EFI variables and tables in the kernel
Dear Sergii and others,
I've committed the change that passes the ESRT from the bootloader to
the kernel. So now it is time to add the interfaces to the kernel to
read it. And add the interfaces to manipulate EFI variables.
For those out of the loop: this could allow us to run fwupd on
OpenBSD, bringing us a way to update the firmware on many machines
without running through several hoops like booting Windows.
What it will also allow us to do is properly set a boot option for
OpenBSD and place it at the fron of the list. Setting EFI variables
is only allowed at securelevel 0 and below.
This diff is an adaptation of the code that Sergii wrote:
https://marc.info/?l=openbsd-tech=166405001006952=2
A few notable changes I made to that code:
* This also adds support for arm64
* Uses a different device major for /dev/efi since I used an unused
number in the middle of the table.
* Renumbered some of the ioctls to avoid leaving a gap
* Made self-contained.
* Fixed the copyright on to match the FreeBSD file
from which significant chunks were copied.
* Reworked the error handling a bit, reducing the errors to those that
actually can happen according to the EFI spec.
Other than the location of the header file, this should all be
consistent with the interfaces that FreeBSD and NetBSD provide.
ok?
Index: etc/MAKEDEV.common
===
RCS file: /cvs/src/etc/MAKEDEV.common,v
retrieving revision 1.118
diff -u -p -r1.118 MAKEDEV.common
--- etc/MAKEDEV.common 10 Nov 2022 09:50:00 - 1.118
+++ etc/MAKEDEV.common 4 Jan 2023 19:44:01 -
@@ -533,3 +533,5 @@ __devitem(dt, dt, Dynamic Tracer)dnl
_mkdev(dt, dt, {-M dt c major_dt_c 0 600-})dnl
__devitem(kstat, kstat, Kernel Statistics)dnl
_mkdev(kstat, kstat, {-M kstat c major_kstat_c 0 640-})dnl
+__devitem(efi, efi, EFI runtime services)dnl
+_mkdev(efi, efi, {-M efi c major_efi_c 0 600-})dnl
Index: etc/etc.amd64/MAKEDEV
===
RCS file: /cvs/src/etc/etc.amd64/MAKEDEV,v
retrieving revision 1.138
diff -u -p -r1.138 MAKEDEV
--- etc/etc.amd64/MAKEDEV 10 Nov 2022 11:02:26 - 1.138
+++ etc/etc.amd64/MAKEDEV 4 Jan 2023 19:44:01 -
@@ -75,6 +75,7 @@
# dt Dynamic Tracer
# diskmap Disk mapper
# dri Direct Rendering Infrastructure
+# efi EFI runtime services
# fd fd/* nodes
# fuseUserland Filesystem
# gpio* General Purpose Input/Output
@@ -358,6 +359,10 @@ fd)
MKlist[${#MKlist[*]}]=";chmod 555 fd"
;;
+efi)
+ M efi c 84 0 600
+ ;;
+
dri)
RMlist[${#RMlist[*]}]=";mkdir -p dri;rm -f"
n=0
@@ -593,19 +598,19 @@ local)
;;
all)
- R ipmi0 ttyVI00 ttyVI10 ttyVI20 ttyVI30 ttyVI40 dri nvram
- R gpio0 gpio1 gpio2 bktr0 vnd0 vnd1 vnd2 vnd3 sd0 sd1 sd2 sd3
- R sd4 sd5 sd6 sd7 sd8 sd9 cd0 cd1 rd0 tap0 tap1 tap2 tap3 tun0
- R tun1 tun2 tun3 bio pty0 fd1 fd1B fd1C fd1D fd1E fd1F fd1G
- R fd1H fd0 fd0B fd0C fd0D fd0E fd0F fd0G fd0H diskmap vscsi0
- R ch0 audio0 audio1 audio2 audio3 kstat dt kcov bpf pvbus0
- R pvbus1 vmm fuse pppac pppx hotplug ptm local wscons pci0
- R pci1 pci2 pci3 uall rmidi0 rmidi1 rmidi2 rmidi3 rmidi4
- R rmidi5 rmidi6 rmidi7 tuner0 radio0 speaker video0 video1 uk0
- R random lpa0 lpa1 lpa2 lpt0 lpt1 lpt2 tty00 tty01 tty02 tty03
- R tty04 tty05 tty06 tty07 tty08 tty09 tty0a tty0b ttyc0 ttyc1
- R ttyc2 ttyc3 ttyc4 ttyc5 ttyc6 ttyc7 apm pf pctr wd0 wd1 wd2
- R wd3 std st0 st1 fd
+ R efi0 ipmi0 ttyVI00 ttyVI10 ttyVI20 ttyVI30 ttyVI40 dri
+ R nvram gpio0 gpio1 gpio2 bktr0 vnd0 vnd1 vnd2 vnd3 sd0 sd1
+ R sd2 sd3 sd4 sd5 sd6 sd7 sd8 sd9 cd0 cd1 rd0 tap0 tap1 tap2
+ R tap3 tun0 tun1 tun2 tun3 bio pty0 fd1 fd1B fd1C fd1D fd1E
+ R fd1F fd1G fd1H fd0 fd0B fd0C fd0D fd0E fd0F fd0G fd0H
+ R diskmap vscsi0 ch0 audio0 audio1 audio2 audio3 kstat dt kcov
+ R bpf pvbus0 pvbus1 vmm fuse pppac pppx hotplug ptm local
+ R wscons pci0 pci1 pci2 pci3 uall rmidi0 rmidi1 rmidi2 rmidi3
+ R rmidi4 rmidi5 rmidi6 rmidi7 tuner0 radio0 speaker video0
+ R video1 uk0 random lpa0 lpa1 lpa2 lpt0 lpt1 lpt2 tty00 tty01
+ R tty02 tty03 tty04 tty05 tty06 tty07 tty08 tty09 tty0a tty0b
+ R ttyc0 ttyc1 ttyc2 ttyc3 ttyc4 ttyc5 ttyc6 ttyc7 apm pf pctr
+ R wd0 wd1 wd2 wd3 std st0 st1 fd
;;
wd*|sd*)
Index: etc/etc.amd64/MAKEDEV.md
===
RCS file: /cvs/src/etc/etc.amd64/MAKEDEV.md,v
retrieving revision 1.81
diff -u -p -r1.81 MAKEDEV.md
--- etc/etc.amd64/MAKEDEV.md9 Nov 2022 19:35:23 - 1.81
+++ etc/etc.amd64/MAKEDEV.md4 Jan 2023 19:44:01 -
@@ -72,6 +72,7 @@ _DEV(bpf, 23)
_DEV(dt, 30)
_DEV(diskmap, 90)
_DEV(dri, 87)
+_DEV(efi, 84)
_DEV(fdesc, 22)
_DEV(fuse, 92)
_DEV(gpio, 88)
@@
Re: Making wscons a bit more like xterm
On Wed, Jan 04, 2023 at 08:08:48PM +0100, Paul de Weerd wrote:
> On Wed, Jan 04, 2023 at 02:33:57PM -0300, Crystal Kolipe wrote:
> | On Wed, Jan 04, 2023 at 04:42:55PM +0100, Paul de Weerd wrote:
> | > Hi Crystal,
> | >
> | > I tried your patch on my laptop. With it applied, and my TERM set to
> | > 'xterm', I do get colors in mutt and tmux.
> |
> | Great! Thanks for testing :).
> |
> | > The latter, however, shows
> | > '^@^@' before the PS1 prompt upon starting a new session (`tmux new`),
> | > behavior I don't see with a 'real' xterm.
> |
> | This looks like an off-by-one in the wscons code, (not introduced by me!)
> |
> | Does the following patch, (on top of the last one), fix it?
>
> Fixes only half of it: we're down to one ^@ now (which is not fixed
> with a s/1/2/ in your below diff).
Interestingly, I haven't been able to reproduce this, and when I tested it
originally I was only ever seeing one ^@, which was fixed by the previous
patch.
However, there is another similar off-by-one nearby, which I strongly suspect
is the culprit as fixing it makes the output of 'ESC [ c' more closely match
what a real xterm does.
I'm sending the complete diff again as anybody else testing the version from
this morning will definitely want these two new fixes. So back-out the
previous mini-patch and the main one before applying this.
Hopefully it'll fix the problem.
--- dev/wscons/wsemul_vt100_keys.c.dist Sat Mar 14 00:38:50 2015
+++ dev/wscons/wsemul_vt100_keys.c Mon Jan 2 16:01:42 2023
@@ -37,11 +37,9 @@
#include
#include
+#define vt100_fkeys_len(x) (5+(x>=8)+(x>=12))
+
static const u_char *vt100_fkeys[] = {
- "\033[11~", /* F1 */
- "\033[12~",
- "\033[13~", /* F1-F5 normally don't send codes */
- "\033[14~",
"\033[15~", /* F5 */
"\033[17~", /* F6 */
"\033[18~",
@@ -50,18 +48,18 @@
"\033[21~",
"\033[23~", /* VT100: ESC */
"\033[24~", /* VT100: BS */
- "\033[25~", /* VT100: LF */
- "\033[26~",
- "\033[28~", /* help */
- "\033[29~", /* do */
- "\033[31~",
- "\033[32~",
- "\033[33~",
- "\033[34~", /* F20 */
- "\033[35~",
- "\033[36~",
- "\033[37~",
- "\033[38~"
+ "\033[1;2P",/* VT100: LF */
+ "\033[1;2Q",
+ "\033[1;2R",/* help */
+ "\033[1;2S",/* do */
+ "\033[15;2~",
+ "\033[17;2~",
+ "\033[18;2~",
+ "\033[19;2~", /* F20 */
+ "\033[20;2~",
+ "\033[21;2~",
+ "\033[23;2~",
+ "\033[24;2~"
};
static const u_char *vt100_pfkeys[] = {
@@ -96,14 +94,22 @@
edp->translatebuf, edp->flags & VTFL_UTF8));
}
- if (in >= KS_f1 && in <= KS_f24) {
- *out = vt100_fkeys[in - KS_f1];
- return (5);
+ if (in >= KS_f1 && in <= KS_f4) {
+ *out = vt100_pfkeys[in - KS_f1];
+ return (3);
}
- if (in >= KS_F1 && in <= KS_F24) {
- *out = vt100_fkeys[in - KS_F1];
- return (5);
+ if (in >= KS_F1 && in <= KS_F4) {
+ *out = vt100_pfkeys[in - KS_F1];
+ return (3);
}
+ if (in >= KS_f5 && in <= KS_f24) {
+ *out = vt100_fkeys[in - KS_f5];
+ return vt100_fkeys_len(in - KS_f5);
+ }
+ if (in >= KS_F5 && in <= KS_F24) {
+ *out = vt100_fkeys[in - KS_F5];
+ return vt100_fkeys_len(in - KS_F5);
+ }
if (in >= KS_KP_F1 && in <= KS_KP_F4) {
*out = vt100_pfkeys[in - KS_KP_F1];
return (3);
@@ -148,12 +154,12 @@
}
switch (in) {
case KS_Help:
- *out = vt100_fkeys[15 - 1];
+ *out = vt100_fkeys[15 - 1 + 4]; /* vt100_fkeys starts at F5 */
return (5);
case KS_Execute: /* "Do" */
- *out = vt100_fkeys[16 - 1];
+ *out = vt100_fkeys[16 - 1 + 4]; /* vt100_fkeys starts at F5 */
return (5);
- case KS_Find:
+ case KS_Find: /* Not defined in xterm
terminfo */
*out = "\033[1~";
return (4);
case KS_Insert:
@@ -163,7 +169,7 @@
case KS_KP_Delete:
*out = "\033[3~";
return (4);
- case KS_Select:
+ case KS_Select: /* Not defined in xterm
terminfo */
*out = "\033[4~";
return (4);
case KS_Prior:
@@ -174,14 +180,27 @@
case KS_KP_Next:
*out = "\033[6~";
return (4);
+ case KS_Backtab:
+ *out = "\033[Z";
+ return (3);
+ /*
+* Unlike insert, delete, page up, and page down, we purposely don't
+* send the same sequence of \033OE for the non-keypad
Re: Making wscons a bit more like xterm
On Wed, Jan 04, 2023 at 02:33:57PM -0300, Crystal Kolipe wrote:
| On Wed, Jan 04, 2023 at 04:42:55PM +0100, Paul de Weerd wrote:
| > Hi Crystal,
| >
| > I tried your patch on my laptop. With it applied, and my TERM set to
| > 'xterm', I do get colors in mutt and tmux.
|
| Great! Thanks for testing :).
|
| > The latter, however, shows
| > '^@^@' before the PS1 prompt upon starting a new session (`tmux new`),
| > behavior I don't see with a 'real' xterm.
|
| This looks like an off-by-one in the wscons code, (not introduced by me!)
|
| Does the following patch, (on top of the last one), fix it?
Fixes only half of it: we're down to one ^@ now (which is not fixed
with a s/1/2/ in your below diff).
Cheers,
Paul
| --- dev/wscons/wsemul_vt100_subr.c.dist Mon May 25 06:55:49 2020
| +++ dev/wscons/wsemul_vt100_subr.cWed Jan 4 14:22:05 2023
| @@ -231,7 +231,7 @@
| switch (A3(edp->modif1, edp->modif2, c)) {
| case A3('>', '\0', 'c'): /* DA secondary */
| wsdisplay_emulinput(edp->cbcookie, WSEMUL_VT_ID2,
| - sizeof(WSEMUL_VT_ID2));
| + sizeof(WSEMUL_VT_ID2)-1);
| break;
|
| case A3('\0', '\0', 'J'): /* ED selective erase in display */
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: Making wscons a bit more like xterm
On Wed, Jan 04, 2023 at 04:42:55PM +0100, Paul de Weerd wrote:
> Hi Crystal,
>
> I tried your patch on my laptop. With it applied, and my TERM set to
> 'xterm', I do get colors in mutt and tmux.
Great! Thanks for testing :).
> The latter, however, shows
> '^@^@' before the PS1 prompt upon starting a new session (`tmux new`),
> behavior I don't see with a 'real' xterm.
This looks like an off-by-one in the wscons code, (not introduced by me!)
Does the following patch, (on top of the last one), fix it?
--- dev/wscons/wsemul_vt100_subr.c.dist Mon May 25 06:55:49 2020
+++ dev/wscons/wsemul_vt100_subr.c Wed Jan 4 14:22:05 2023
@@ -231,7 +231,7 @@
switch (A3(edp->modif1, edp->modif2, c)) {
case A3('>', '\0', 'c'): /* DA secondary */
wsdisplay_emulinput(edp->cbcookie, WSEMUL_VT_ID2,
- sizeof(WSEMUL_VT_ID2));
+ sizeof(WSEMUL_VT_ID2)-1);
break;
case A3('\0', '\0', 'J'): /* ED selective erase in display */
Re: Making wscons a bit more like xterm
Hi Crystal,
I tried your patch on my laptop. With it applied, and my TERM set to
'xterm', I do get colors in mutt and tmux. The latter, however, shows
'^@^@' before the PS1 prompt upon starting a new session (`tmux new`),
behavior I don't see with a 'real' xterm.
I like the idea, thanks for your work on this diff.
Paul
On Wed, Jan 04, 2023 at 10:42:56AM -0300, Crystal Kolipe wrote:
| Continuing the move towards xterm becoming the default termtype for the
| console...
|
| This third version of the patchset adds the following features. New features
| since the last version are highlighted first:
|
| NEW - Control sequences for dim text, invisible text, strike through, italic,
| and double underline attributes are now recognised and set flags in
| wscons.
|
| NEW - Rendering of dim, invisible, struck, and double underlined text is now
| supported in rasops32.c, so users of 32bpp displays will see these text
| effects on the console.
|
| NEW - The default number of scrollback screens has been increased from five to
| twenty.
|
| * F1 - F4 now send different sequences.
| * F13 - F24 now send different sequences, but see notes below about F13 - F16.
| * With numlock OFF, keypad 5 is now 'begin' rather than unused.
| * Home, End, keypad home, and keypad end now send different sequences.
| * A new keysym has been added - KS_Backtab.
| * Shift-TAB is now defined as KS_Backtab and sends ESC [ Z.
| * Shift-F1 - Shift-F12 now send F13 - F24.
| * Five new escape sequences added for cursor movement.
|
| Running with this patch, all of the curses-based programs that I use on a
| regular basis are working and usable with TERM=xterm.
|
| The overall experience is much improved over TERM=vt220, as we get colour.
|
| Even compared to pccon, we gain the ability to use colour together with
| underline, show and hide the cursor, and use backtab. We also gain the
| practicality of relying on a very widely and well supported terminal
| definition, (xterm), which could much more reasonably become the default than
| could pccon.
|
| Additionally, a small side benefit of changing the function key sequences from
| those expected by pccon to those expected by xterm is that any programs or
| scripts which ignore terminfo and are hard coded to work with xterm will now
| work on the console as well.
|
| --- dev/wscons/wsemul_vt100_keys.c.dist Sat Mar 14 00:38:50 2015
| +++ dev/wscons/wsemul_vt100_keys.cMon Jan 2 16:01:42 2023
| @@ -37,11 +37,9 @@
| #include
| #include
|
| +#define vt100_fkeys_len(x) (5+(x>=8)+(x>=12))
| +
| static const u_char *vt100_fkeys[] = {
| - "\033[11~", /* F1 */
| - "\033[12~",
| - "\033[13~", /* F1-F5 normally don't send codes */
| - "\033[14~",
| "\033[15~", /* F5 */
| "\033[17~", /* F6 */
| "\033[18~",
| @@ -50,18 +48,18 @@
| "\033[21~",
| "\033[23~", /* VT100: ESC */
| "\033[24~", /* VT100: BS */
| - "\033[25~", /* VT100: LF */
| - "\033[26~",
| - "\033[28~", /* help */
| - "\033[29~", /* do */
| - "\033[31~",
| - "\033[32~",
| - "\033[33~",
| - "\033[34~", /* F20 */
| - "\033[35~",
| - "\033[36~",
| - "\033[37~",
| - "\033[38~"
| + "\033[1;2P",/* VT100: LF */
| + "\033[1;2Q",
| + "\033[1;2R",/* help */
| + "\033[1;2S",/* do */
| + "\033[15;2~",
| + "\033[17;2~",
| + "\033[18;2~",
| + "\033[19;2~", /* F20 */
| + "\033[20;2~",
| + "\033[21;2~",
| + "\033[23;2~",
| + "\033[24;2~"
| };
|
| static const u_char *vt100_pfkeys[] = {
| @@ -96,14 +94,22 @@
| edp->translatebuf, edp->flags & VTFL_UTF8));
| }
|
| - if (in >= KS_f1 && in <= KS_f24) {
| - *out = vt100_fkeys[in - KS_f1];
| - return (5);
| + if (in >= KS_f1 && in <= KS_f4) {
| + *out = vt100_pfkeys[in - KS_f1];
| + return (3);
| }
| - if (in >= KS_F1 && in <= KS_F24) {
| - *out = vt100_fkeys[in - KS_F1];
| - return (5);
| + if (in >= KS_F1 && in <= KS_F4) {
| + *out = vt100_pfkeys[in - KS_F1];
| + return (3);
| }
| + if (in >= KS_f5 && in <= KS_f24) {
| + *out = vt100_fkeys[in - KS_f5];
| + return vt100_fkeys_len(in - KS_f5);
| + }
| + if (in >= KS_F5 && in <= KS_F24) {
| + *out = vt100_fkeys[in - KS_F5];
| + return vt100_fkeys_len(in - KS_F5);
| + }
| if (in >= KS_KP_F1 && in <= KS_KP_F4) {
| *out = vt100_pfkeys[in - KS_KP_F1];
| return (3);
| @@ -148,12 +154,12 @@
| }
| switch (in) {
| case KS_Help:
| - *out = vt100_fkeys[15 - 1];
| + *out = vt100_fkeys[15 - 1 + 4]; /* vt100_fkeys starts at F5 */
| return (5);
| case KS_Execute: /* "Do" */
| - *out =
Re: Suggested change to ports.7 man page
On Wed, Jan 04, 2023 at 10:12:00AM +, Stuart Henderson wrote: >I don't think this helps. >It's the same for clean, update-patches, install, update-plist, >port-lib-depends-check, [...] and we already have "and of course, use >the same settings for the subsequent invocations of make" in the >section showing how to work with flavours. >-- thanks, stuart. i won;t pursue this any further. jmc > Sent from a phone, apologies for poor formatting. >On 4 January 2023 07:28:39 Jason McIntyre wrote: > >On Mon, Jan 02, 2023 at 07:00:27AM -0500, Jon Fineman wrote: > >I was trying to make clean a port I was updating and it wasn't clear > >to me that I should be adding the FLAVOR variable to the make line to > >clean the correct build. > >My suggested change below might help other people. > >Jon > >anyone? > >jmc > >Index: ports.7 > >=== > >RCS file: /cvs/src/share/man/man7/ports.7,v > >retrieving revision 1.130 > >diff -u -p -r1.130 ports.7 > >--- ports.7 20 Jul 2022 16:37:50 - 1.130 > >+++ ports.7 2 Jan 2023 11:38:27 - > >@@ -324,6 +324,9 @@ This does not recurse to dependencies un > >.Ev CLEANDEPENDS > >is defined to > >.Dv Yes . > >+To clean a build of > >+.Cm FLAVORS > >+you need to specify all of the flavors you built with. > >.It Cm distclean > >Remove the port's distfile(s). > >This does not recurse to dependencies.
Re: Making wscons a bit more like xterm
Continuing the move towards xterm becoming the default termtype for the
console...
This third version of the patchset adds the following features. New features
since the last version are highlighted first:
NEW - Control sequences for dim text, invisible text, strike through, italic,
and double underline attributes are now recognised and set flags in
wscons.
NEW - Rendering of dim, invisible, struck, and double underlined text is now
supported in rasops32.c, so users of 32bpp displays will see these text
effects on the console.
NEW - The default number of scrollback screens has been increased from five to
twenty.
* F1 - F4 now send different sequences.
* F13 - F24 now send different sequences, but see notes below about F13 - F16.
* With numlock OFF, keypad 5 is now 'begin' rather than unused.
* Home, End, keypad home, and keypad end now send different sequences.
* A new keysym has been added - KS_Backtab.
* Shift-TAB is now defined as KS_Backtab and sends ESC [ Z.
* Shift-F1 - Shift-F12 now send F13 - F24.
* Five new escape sequences added for cursor movement.
Running with this patch, all of the curses-based programs that I use on a
regular basis are working and usable with TERM=xterm.
The overall experience is much improved over TERM=vt220, as we get colour.
Even compared to pccon, we gain the ability to use colour together with
underline, show and hide the cursor, and use backtab. We also gain the
practicality of relying on a very widely and well supported terminal
definition, (xterm), which could much more reasonably become the default than
could pccon.
Additionally, a small side benefit of changing the function key sequences from
those expected by pccon to those expected by xterm is that any programs or
scripts which ignore terminfo and are hard coded to work with xterm will now
work on the console as well.
--- dev/wscons/wsemul_vt100_keys.c.dist Sat Mar 14 00:38:50 2015
+++ dev/wscons/wsemul_vt100_keys.c Mon Jan 2 16:01:42 2023
@@ -37,11 +37,9 @@
#include
#include
+#define vt100_fkeys_len(x) (5+(x>=8)+(x>=12))
+
static const u_char *vt100_fkeys[] = {
- "\033[11~", /* F1 */
- "\033[12~",
- "\033[13~", /* F1-F5 normally don't send codes */
- "\033[14~",
"\033[15~", /* F5 */
"\033[17~", /* F6 */
"\033[18~",
@@ -50,18 +48,18 @@
"\033[21~",
"\033[23~", /* VT100: ESC */
"\033[24~", /* VT100: BS */
- "\033[25~", /* VT100: LF */
- "\033[26~",
- "\033[28~", /* help */
- "\033[29~", /* do */
- "\033[31~",
- "\033[32~",
- "\033[33~",
- "\033[34~", /* F20 */
- "\033[35~",
- "\033[36~",
- "\033[37~",
- "\033[38~"
+ "\033[1;2P",/* VT100: LF */
+ "\033[1;2Q",
+ "\033[1;2R",/* help */
+ "\033[1;2S",/* do */
+ "\033[15;2~",
+ "\033[17;2~",
+ "\033[18;2~",
+ "\033[19;2~", /* F20 */
+ "\033[20;2~",
+ "\033[21;2~",
+ "\033[23;2~",
+ "\033[24;2~"
};
static const u_char *vt100_pfkeys[] = {
@@ -96,14 +94,22 @@
edp->translatebuf, edp->flags & VTFL_UTF8));
}
- if (in >= KS_f1 && in <= KS_f24) {
- *out = vt100_fkeys[in - KS_f1];
- return (5);
+ if (in >= KS_f1 && in <= KS_f4) {
+ *out = vt100_pfkeys[in - KS_f1];
+ return (3);
}
- if (in >= KS_F1 && in <= KS_F24) {
- *out = vt100_fkeys[in - KS_F1];
- return (5);
+ if (in >= KS_F1 && in <= KS_F4) {
+ *out = vt100_pfkeys[in - KS_F1];
+ return (3);
}
+ if (in >= KS_f5 && in <= KS_f24) {
+ *out = vt100_fkeys[in - KS_f5];
+ return vt100_fkeys_len(in - KS_f5);
+ }
+ if (in >= KS_F5 && in <= KS_F24) {
+ *out = vt100_fkeys[in - KS_F5];
+ return vt100_fkeys_len(in - KS_F5);
+ }
if (in >= KS_KP_F1 && in <= KS_KP_F4) {
*out = vt100_pfkeys[in - KS_KP_F1];
return (3);
@@ -148,12 +154,12 @@
}
switch (in) {
case KS_Help:
- *out = vt100_fkeys[15 - 1];
+ *out = vt100_fkeys[15 - 1 + 4]; /* vt100_fkeys starts at F5 */
return (5);
case KS_Execute: /* "Do" */
- *out = vt100_fkeys[16 - 1];
+ *out = vt100_fkeys[16 - 1 + 4]; /* vt100_fkeys starts at F5 */
return (5);
- case KS_Find:
+ case KS_Find: /* Not defined in xterm
terminfo */
*out = "\033[1~";
return (4);
case KS_Insert:
@@ -163,7 +169,7 @@
case KS_KP_Delete:
*out = "\033[3~";
return (4);
- case KS_Select:
+ case KS_Select:
Re: bgpd introduce session role for ASPA and open policy
On Wed, Jan 04, 2023 at 12:21:59PM +0100, Claudio Jeker wrote:
> bgpd already supports Open Policy (RFC 9234) and the role of the router is
> set as part of the `announce policy` config. Now ASPA also needs the role
> so it makes sense to promote setting the role in the config.
>
> I also switched the role to an enum mainly because I want 0 to be the
> default "NONE" role. Roles only matter on ebgp sessions and ibgp sessions
> should just use ROLE_NONE.
>
> announce policy now only has three options: yes, no and enforce
> If announce policy is set to yes but no role is defined the policy
> capability is silently switched to no. I'm not super happy with that
> behaviour but I think it is temporary and at one point 'role' will become
> mandatory for ebgp neighbors.
>
> Similar to turning off announce policy, ibgp sessions are forced to
> ROLE_NONE. Roles make no sense for ibgp and so forcing the role to none
> makes sure they remain consistent.
>
> The automatic changes are done so that groups can inherit default values
> that are fixed up if required.
>
> I did the minimal adjustment in bgpd.conf.5 manpage. I think more is
> needed there.
>
> This breaks the policy intergration test but I have a fix for it ready.
Reads fine.
ok with one small comment below.
> Index: session.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
> retrieving revision 1.438
> diff -u -p -r1.438 session.c
> --- session.c 28 Dec 2022 21:30:16 - 1.438
> +++ session.c 4 Jan 2023 11:11:45 -
[...]
> @@ -1442,9 +1483,12 @@ session_open(struct peer *p)
> errs += session_capa_add(opb, CAPA_REFRESH, 0);
>
> /* BGP open policy, RFC 9234, only for ebgp sessions */
> - if (p->capa.ann.role_ena && p->conf.ebgp) {
> + if (p->conf.ebgp && p->capa.ann.role_ena &&
> + p->capa.ann.role != CAPA_NONE) {
This should be ROLE_NONE
> + uint8_t val;
> + val = role2capa(p->capa.ann.role);
> errs += session_capa_add(opb, CAPA_ROLE, 1);
> - errs += ibuf_add(opb, >capa.ann.role, 1);
> + errs += ibuf_add(opb, , 1);
> }
>
> /* graceful restart and End-of-RIB marker, RFC 4724 */
more consistently use "st" as the name for struct pf_state variables
and "stp" for pf_state ** variables.
there should be no functional change here.
ok?
Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.1167
diff -u -p -r1.1167 pf.c
--- pf.c4 Jan 2023 10:31:55 - 1.1167
+++ pf.c4 Jan 2023 11:34:30 -
@@ -376,23 +376,23 @@ pf_src_compare(struct pf_src_node *a, st
}
static __inline void
-pf_set_protostate(struct pf_state *s, int which, u_int8_t newstate)
+pf_set_protostate(struct pf_state *st, int which, u_int8_t newstate)
{
if (which == PF_PEER_DST || which == PF_PEER_BOTH)
- s->dst.state = newstate;
+ st->dst.state = newstate;
if (which == PF_PEER_DST)
return;
- if (s->src.state == newstate)
+ if (st->src.state == newstate)
return;
- if (s->creatorid == pf_status.hostid &&
- s->key[PF_SK_STACK]->proto == IPPROTO_TCP &&
- !(TCPS_HAVEESTABLISHED(s->src.state) ||
- s->src.state == TCPS_CLOSED) &&
+ if (st->creatorid == pf_status.hostid &&
+ st->key[PF_SK_STACK]->proto == IPPROTO_TCP &&
+ !(TCPS_HAVEESTABLISHED(st->src.state) ||
+ st->src.state == TCPS_CLOSED) &&
(TCPS_HAVEESTABLISHED(newstate) || newstate == TCPS_CLOSED))
pf_status.states_halfopen--;
- s->src.state = newstate;
+ st->src.state = newstate;
}
void
@@ -477,25 +477,25 @@ pf_state_list_remove(struct pf_state_lis
}
int
-pf_src_connlimit(struct pf_state **state)
+pf_src_connlimit(struct pf_state **stp)
{
int bad = 0;
struct pf_src_node *sn;
- if ((sn = pf_get_src_node((*state), PF_SN_NONE)) == NULL)
+ if ((sn = pf_get_src_node((*stp), PF_SN_NONE)) == NULL)
return (0);
sn->conn++;
- (*state)->src.tcp_est = 1;
+ (*stp)->src.tcp_est = 1;
pf_add_threshold(>conn_rate);
- if ((*state)->rule.ptr->max_src_conn &&
- (*state)->rule.ptr->max_src_conn < sn->conn) {
+ if ((*stp)->rule.ptr->max_src_conn &&
+ (*stp)->rule.ptr->max_src_conn < sn->conn) {
pf_status.lcounters[LCNT_SRCCONN]++;
bad++;
}
- if ((*state)->rule.ptr->max_src_conn_rate.limit &&
+ if ((*stp)->rule.ptr->max_src_conn_rate.limit &&
pf_check_threshold(>conn_rate)) {
pf_status.lcounters[LCNT_SRCCONNRATE]++;
bad++;
@@ -504,7 +504,7 @@ pf_src_connlimit(struct pf_state **state
if (!bad)
return (0);
- if ((*state)->rule.ptr->overload_tbl) {
+ if ((*stp)->rule.ptr->overload_tbl) {
struct pfr_addr p;
u_int32_t killed = 0;
@@ -513,12 +513,12 @@ pf_src_connlimit(struct pf_state **state
log(LOG_NOTICE,
"pf: pf_src_connlimit: blocking address ");
pf_print_host(>addr, 0,
- (*state)->key[PF_SK_WIRE]->af);
+ (*stp)->key[PF_SK_WIRE]->af);
}
memset(, 0, sizeof(p));
- p.pfra_af = (*state)->key[PF_SK_WIRE]->af;
- switch ((*state)->key[PF_SK_WIRE]->af) {
+ p.pfra_af = (*stp)->key[PF_SK_WIRE]->af;
+ switch ((*stp)->key[PF_SK_WIRE]->af) {
case AF_INET:
p.pfra_net = 32;
p.pfra_ip4addr = sn->addr.v4;
@@ -531,11 +531,11 @@ pf_src_connlimit(struct pf_state **state
#endif /* INET6 */
}
- pfr_insert_kentry((*state)->rule.ptr->overload_tbl,
+ pfr_insert_kentry((*stp)->rule.ptr->overload_tbl,
, gettime());
/* kill existing states if that's required. */
- if ((*state)->rule.ptr->flush) {
+ if ((*stp)->rule.ptr->flush) {
struct pf_state_key *sk;
struct pf_state *st;
@@ -548,14 +548,14 @@ pf_src_connlimit(struct pf_state **state
* set)
*/
if (sk->af ==
- (*state)->key[PF_SK_WIRE]->af &&
- (((*state)->direction == PF_OUT &&
+ (*stp)->key[PF_SK_WIRE]->af &&
+ (((*stp)->direction == PF_OUT &&
PF_AEQ(>addr, >addr[1], sk->af)) ||
- ((*state)->direction == PF_IN &&
+ ((*stp)->direction == PF_IN &&
PF_AEQ(>addr, >addr[0], sk->af))) &&
- ((*state)->rule.ptr->flush &
+ ((*stp)->rule.ptr->flush &
bgpd introduce session role for ASPA and open policy
bgpd already supports Open Policy (RFC 9234) and the role of the router is
set as part of the `announce policy` config. Now ASPA also needs the role
so it makes sense to promote setting the role in the config.
I also switched the role to an enum mainly because I want 0 to be the
default "NONE" role. Roles only matter on ebgp sessions and ibgp sessions
should just use ROLE_NONE.
announce policy now only has three options: yes, no and enforce
If announce policy is set to yes but no role is defined the policy
capability is silently switched to no. I'm not super happy with that
behaviour but I think it is temporary and at one point 'role' will become
mandatory for ebgp neighbors.
Similar to turning off announce policy, ibgp sessions are forced to
ROLE_NONE. Roles make no sense for ibgp and so forcing the role to none
makes sure they remain consistent.
The automatic changes are done so that groups can inherit default values
that are fixed up if required.
I did the minimal adjustment in bgpd.conf.5 manpage. I think more is
needed there.
This breaks the policy intergration test but I have a fix for it ready.
--
:wq Claudio
Index: bgpd.conf.5
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
retrieving revision 1.227
diff -u -p -r1.227 bgpd.conf.5
--- bgpd.conf.5 22 Dec 2022 19:53:24 - 1.227
+++ bgpd.conf.5 3 Jan 2023 17:42:15 -
@@ -933,19 +933,11 @@ The default is
.Pp
.It Xo
.Ic announce policy
-.Pq Ic no Ns | Ns Ar role
-.Op Ic enforce
+.Pq Ic yes Ns | Ns Ic no Ns | Ns Ic enforce
.Xc
If set to
-.Ic no ,
-do not add the open policy role capability.
-The role can be one of
-.Ar provider ,
-.Ar customer ,
-.Ar rs ,
-.Ar rs-client ,
-or
-.Ar peer .
+.Ic yes ,
+add the open policy role capability.
If the role of the neighbor does not correspond to the expected role then
the session will be closed.
If
@@ -1310,6 +1302,22 @@ setting.
.Pp
.It Ic rib Ar name
Bind the neighbor to the specified RIB.
+.Pp
+.It Ic role Ar role
+Set the local role for this eBGP session.
+The role can be one of
+.Ar none ,
+.Ar provider ,
+.Ar customer ,
+.Ar rs ,
+.Ar rs-client ,
+or
+.Ar peer .
+If the role is set to
+.Ar none
+the
+.Ic announce Ic policy
+will also be disabled.
.Pp
.It Ic route-reflector Op Ar address
Act as an RFC 4456
Index: bgpd.h
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
retrieving revision 1.455
diff -u -p -r1.455 bgpd.h
--- bgpd.h 18 Nov 2022 10:17:23 - 1.455
+++ bgpd.h 3 Jan 2023 16:45:29 -
@@ -333,6 +333,15 @@ enum enforce_as {
ENFORCE_AS_ON
};
+enum role {
+ ROLE_NONE,
+ ROLE_CUSTOMER,
+ ROLE_PROVIDER,
+ ROLE_RS,
+ ROLE_RS_CLIENT,
+ ROLE_PEER,
+};
+
enum auth_method {
AUTH_NONE,
AUTH_MD5SIG,
@@ -380,12 +389,12 @@ struct capabilities {
int8_t flags[AID_MAX]; /* graceful restart per AID flags */
int8_t restart;/* graceful restart, RFC 4724 */
} grestart;
+ enum role role; /* Open Policy, RFC 9234 */
int8_t mp[AID_MAX];/* multiprotocol extensions, RFC 4760 */
+ int8_t add_path[AID_MAX]; /* ADD_PATH, RFC 7911 */
int8_t refresh;/* route refresh, RFC 2918 */
int8_t as4byte;/* 4-byte ASnum, RFC 4893 */
int8_t enhanced_rr;/* enhanced route refresh, RFC 7313 */
- int8_t add_path[AID_MAX]; /* ADD_PATH, RFC 7911 */
- uint8_t role; /* Open Policy, RFC 9234 */
int8_t role_ena; /* 1 for enable, 2 for enforce */
};
@@ -432,6 +441,7 @@ struct peer_config {
enum export_type export_type;
enum enforce_as enforce_as;
enum enforce_as enforce_local_as;
+ enum rolerole;
uint16_t max_prefix_restart;
uint16_t max_out_prefix_restart;
uint16_t holdtime;
@@ -1417,7 +1427,7 @@ const char*log_rd(uint64_t);
const char *log_ext_subtype(int, uint8_t);
const char *log_reason(const char *);
const char *log_rtr_error(enum rtr_error);
-const char *log_policy(uint8_t);
+const char *log_policy(enum role);
int aspath_snprint(char *, size_t, void *, uint16_t);
int aspath_asprint(char **, void *, uint16_t);
size_t aspath_strlen(void *, uint16_t);
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/bgpd/parse.y,v
retrieving revision 1.437
diff -u -p -r1.437 parse.y
--- parse.y 18 Nov 2022 10:17:23 - 1.437
+++ parse.y 3 Jan 2023 17:16:38 -
@@ -219,7 +219,7 @@ typedef struct {
%token EBGP IBGP
%token LOCALAS REMOTEAS DESCR LOCALADDR MULTIHOP PASSIVE MAXPREFIX RESTART
%token
Re: move the pf_state_tree_id type around
> On 4 Jan 2023, at 20:20, Alexandr Nedvedicky wrote:
>
> Hello,
>
> I agree with change as-is. Though I have some suggestions
> for few finishing touches. see comments inline.
>
> On Wed, Jan 04, 2023 at 01:15:54PM +1000, David Gwynne wrote:
>> move the pf_state_tree_id type from pfvar.h to pfvar_priv.h.
>>
>> this is like the pf_state_tree change from yesterday. the
>> pf_state_tree_id type is private to the kernel, just like the
>> pf_state_tree type.
>>
>> moving it from RB to RBT saves another 12k in pf.o on amd64.
>>
>> i also changed some hand rolled for loops over to RBT_FOREACH_SAFE.
>> they look right?
>
>All those look good to me. Suggestion below are just
>suggestions which I don't insist on.
>
>>
>> ok?
>>
>> Index: pf.c
>> ===
>> RCS file: /cvs/src/sys/net/pf.c,v
>> retrieving revision 1.1166
>> diff -u -p -r1.1166 pf.c
>> --- pf.c 4 Jan 2023 02:00:49 - 1.1166
>> +++ pf.c 4 Jan 2023 03:08:04 -
>
>> @@ -1054,7 +1053,7 @@ pf_state_insert(struct pfi_kif *kif, str
>> s->id = htobe64(pf_status.stateid++);
>> s->creatorid = pf_status.hostid;
>> }
>> - if (RB_INSERT(pf_state_tree_id, _id, s) != NULL) {
>> + if (RBT_INSERT(pf_state_tree_id, _id, s) != NULL) {
>> if (pf_status.debug >= LOG_NOTICE) {
>> log(LOG_NOTICE, "pf: state insert failed: "
>>"id: %016llx creatorid: %08x",
>> @@ -1085,7 +1084,7 @@ pf_find_state_byid(struct pf_state_cmp *
>> {
>> pf_status.fcounters[FCNT_STATE_SEARCH]++;
>>
>> - return (RB_FIND(pf_state_tree_id, _id, (struct pf_state *)key));
>> + return (RBT_FIND(pf_state_tree_id, _id, (struct pf_state *)key));
>> }
>
>would it make sense to rename argument `s` to `st`? Just to lean
>towards consistency in pf(4). `st` usually denotes state.
>
>
>> Index: pf_ioctl.c
>> ===
>> RCS file: /cvs/src/sys/net/pf_ioctl.c,v
>> retrieving revision 1.394
>> diff -u -p -r1.394 pf_ioctl.c
>> --- pf_ioctl.c 4 Jan 2023 02:00:49 - 1.394
>> +++ pf_ioctl.c 4 Jan 2023 03:08:05 -
>> @@ -1796,10 +1796,7 @@ pfioctl(dev_t dev, u_long cmd, caddr_t a
>> NET_LOCK();
>> PF_LOCK();
>> PF_STATE_ENTER_WRITE();
>> - for (s = RB_MIN(pf_state_tree_id, _id); s;
>> -s = nexts) {
>> - nexts = RB_NEXT(pf_state_tree_id, _id, s);
>> -
>> + RBT_FOREACH_SAFE(s, pf_state_tree_id, _id, nexts) {
>> if (s->direction == PF_OUT) {
>> sk = s->key[PF_SK_STACK];
>> srcaddr = >addr[1];
>
>again: same change as earlier just rename `s` to `st` when
>already there.
>
>> @@ -2828,7 +2825,7 @@ pfioctl(dev_t dev, u_long cmd, caddr_t a
>> NET_LOCK();
>> PF_LOCK();
>> PF_STATE_ENTER_WRITE();
>> - RB_FOREACH(state, pf_state_tree_id, _id)
>> + RBT_FOREACH(state, pf_state_tree_id, _id)
>> pf_src_tree_remove_state(state);
>> PF_STATE_EXIT_WRITE();
>> RB_FOREACH(n, pf_src_tree, _src_tracking)
>> @@ -2861,7 +2858,7 @@ pfioctl(dev_t dev, u_long cmd, caddr_t a
>> if (sn->states != 0) {
>> PF_ASSERT_LOCKED();
>> PF_STATE_ENTER_WRITE();
>> - RB_FOREACH(s, pf_state_tree_id,
>> + RBT_FOREACH(s, pf_state_tree_id,
>> _id)
>> pf_state_rm_src_node(s, sn);
>> PF_STATE_EXIT_WRITE();
>
>in this case branch too, rename `state` to `st`.
>
>> Index: pf_lb.c
>> ===
>> RCS file: /cvs/src/sys/net/pf_lb.c,v
>> retrieving revision 1.72
>> diff -u -p -r1.72 pf_lb.c
>> --- pf_lb.c 31 Aug 2022 11:29:12 - 1.72
>> +++ pf_lb.c 4 Jan 2023 03:08:05 -
>> @@ -311,10 +311,8 @@ pf_map_addr_sticky(sa_family_t af, struc
>> }
>> if (sns[type]->states != 0) {
>> /* XXX expensive */
>> - RB_FOREACH(s, pf_state_tree_id,
>> - _id)
>> - pf_state_rm_src_node(s,
>> -sns[type]);
>> + RBT_FOREACH(s, pf_state_tree_id, _id)
>> + pf_state_rm_src_node(s, sns[type]);
>> }
>
>rename `s` to `st`
>
>
>> sns[type]->expire = 1;
>> pf_remove_src_node(sns[type]);
>> Index: pfvar.h
>> ===
>> RCS file: /cvs/src/sys/net/pfvar.h,v
>> retrieving revision 1.526
>> diff -u -p -r1.526 pfvar.h
>> --- pfvar.h 4 Jan 2023 02:00:49 - 1.526
>> +++ pfvar.h 4 Jan 2023 03:08:05 -
>> @@ -1581,10 +1581,6 @@ RB_HEAD(pf_src_tree, pf_src_node);
>> RB_PROTOTYPE(pf_src_tree, pf_src_node, entry, pf_src_compare);
>> extern struct pf_src_tree tree_src_tracking;
>>
>> -RB_HEAD(pf_state_tree_id, pf_state);
>> -RB_PROTOTYPE(pf_state_tree_id, pf_state,
>> -entry_id, pf_state_compare_id);
>> -extern struct pf_state_tree_id tree_id;
>> extern struct pf_state_list pf_state_list;
>
>I think we can move pf_state_list to pvar_priv.h too
>
> with or without suggestions included the diff is OK sashan
i'll put this in as is, and have a go at some pf_state variable renames as a
follow up.
>
> thanks and
> regards
> sashan
Re: move the pf_state_tree_id type around
Hello,
I agree with change as-is. Though I have some suggestions
for few finishing touches. see comments inline.
On Wed, Jan 04, 2023 at 01:15:54PM +1000, David Gwynne wrote:
> move the pf_state_tree_id type from pfvar.h to pfvar_priv.h.
>
> this is like the pf_state_tree change from yesterday. the
> pf_state_tree_id type is private to the kernel, just like the
> pf_state_tree type.
>
> moving it from RB to RBT saves another 12k in pf.o on amd64.
>
> i also changed some hand rolled for loops over to RBT_FOREACH_SAFE.
> they look right?
All those look good to me. Suggestion below are just
suggestions which I don't insist on.
>
> ok?
>
> Index: pf.c
> ===
> RCS file: /cvs/src/sys/net/pf.c,v
> retrieving revision 1.1166
> diff -u -p -r1.1166 pf.c
> --- pf.c 4 Jan 2023 02:00:49 - 1.1166
> +++ pf.c 4 Jan 2023 03:08:04 -
> @@ -1054,7 +1053,7 @@ pf_state_insert(struct pfi_kif *kif, str
> s->id = htobe64(pf_status.stateid++);
> s->creatorid = pf_status.hostid;
> }
> - if (RB_INSERT(pf_state_tree_id, _id, s) != NULL) {
> + if (RBT_INSERT(pf_state_tree_id, _id, s) != NULL) {
> if (pf_status.debug >= LOG_NOTICE) {
> log(LOG_NOTICE, "pf: state insert failed: "
> "id: %016llx creatorid: %08x",
> @@ -1085,7 +1084,7 @@ pf_find_state_byid(struct pf_state_cmp *
> {
> pf_status.fcounters[FCNT_STATE_SEARCH]++;
>
> - return (RB_FIND(pf_state_tree_id, _id, (struct pf_state *)key));
> + return (RBT_FIND(pf_state_tree_id, _id, (struct pf_state *)key));
> }
would it make sense to rename argument `s` to `st`? Just to lean
towards consistency in pf(4). `st` usually denotes state.
> Index: pf_ioctl.c
> ===
> RCS file: /cvs/src/sys/net/pf_ioctl.c,v
> retrieving revision 1.394
> diff -u -p -r1.394 pf_ioctl.c
> --- pf_ioctl.c4 Jan 2023 02:00:49 - 1.394
> +++ pf_ioctl.c4 Jan 2023 03:08:05 -
> @@ -1796,10 +1796,7 @@ pfioctl(dev_t dev, u_long cmd, caddr_t a
> NET_LOCK();
> PF_LOCK();
> PF_STATE_ENTER_WRITE();
> - for (s = RB_MIN(pf_state_tree_id, _id); s;
> - s = nexts) {
> - nexts = RB_NEXT(pf_state_tree_id, _id, s);
> -
> + RBT_FOREACH_SAFE(s, pf_state_tree_id, _id, nexts) {
> if (s->direction == PF_OUT) {
> sk = s->key[PF_SK_STACK];
> srcaddr = >addr[1];
again: same change as earlier just rename `s` to `st` when
already there.
> @@ -2828,7 +2825,7 @@ pfioctl(dev_t dev, u_long cmd, caddr_t a
> NET_LOCK();
> PF_LOCK();
> PF_STATE_ENTER_WRITE();
> - RB_FOREACH(state, pf_state_tree_id, _id)
> + RBT_FOREACH(state, pf_state_tree_id, _id)
> pf_src_tree_remove_state(state);
> PF_STATE_EXIT_WRITE();
> RB_FOREACH(n, pf_src_tree, _src_tracking)
> @@ -2861,7 +2858,7 @@ pfioctl(dev_t dev, u_long cmd, caddr_t a
> if (sn->states != 0) {
> PF_ASSERT_LOCKED();
> PF_STATE_ENTER_WRITE();
> - RB_FOREACH(s, pf_state_tree_id,
> + RBT_FOREACH(s, pf_state_tree_id,
> _id)
> pf_state_rm_src_node(s, sn);
> PF_STATE_EXIT_WRITE();
in this case branch too, rename `state` to `st`.
> Index: pf_lb.c
> ===
> RCS file: /cvs/src/sys/net/pf_lb.c,v
> retrieving revision 1.72
> diff -u -p -r1.72 pf_lb.c
> --- pf_lb.c 31 Aug 2022 11:29:12 - 1.72
> +++ pf_lb.c 4 Jan 2023 03:08:05 -
> @@ -311,10 +311,8 @@ pf_map_addr_sticky(sa_family_t af, struc
> }
> if (sns[type]->states != 0) {
> /* XXX expensive */
> - RB_FOREACH(s, pf_state_tree_id,
> -_id)
> - pf_state_rm_src_node(s,
> - sns[type]);
> + RBT_FOREACH(s, pf_state_tree_id, _id)
> + pf_state_rm_src_node(s, sns[type]);
> }
rename `s` to `st`
> sns[type]->expire = 1;
> pf_remove_src_node(sns[type]);
> Index: pfvar.h
> ===
> RCS file: /cvs/src/sys/net/pfvar.h,v
> retrieving revision 1.526
> diff -u -p -r1.526 pfvar.h
> --- pfvar.h 4 Jan 2023 02:00:49 - 1.526
> +++ pfvar.h 4 Jan 2023 03:08:05
Re: Suggested change to ports.7 man page
I don't think this helps. It's the same for clean, update-patches, install, update-plist, port-lib-depends-check, [...] and we already have "and of course, use the same settings for the subsequent invocations of make" in the section showing how to work with flavours. -- Sent from a phone, apologies for poor formatting. On 4 January 2023 07:28:39 Jason McIntyre wrote: On Mon, Jan 02, 2023 at 07:00:27AM -0500, Jon Fineman wrote: I was trying to make clean a port I was updating and it wasn't clear to me that I should be adding the FLAVOR variable to the make line to clean the correct build. My suggested change below might help other people. Jon anyone? jmc Index: ports.7 === RCS file: /cvs/src/share/man/man7/ports.7,v retrieving revision 1.130 diff -u -p -r1.130 ports.7 --- ports.7 20 Jul 2022 16:37:50 - 1.130 +++ ports.7 2 Jan 2023 11:38:27 - @@ -324,6 +324,9 @@ This does not recurse to dependencies un .Ev CLEANDEPENDS is defined to .Dv Yes . +To clean a build of +.Cm FLAVORS +you need to specify all of the flavors you built with. .It Cm distclean Remove the port's distfile(s). This does not recurse to dependencies.
