Re: grep.1: Use Fl for -print0
On Tue, Jan 03, 2023 at 11:55:34AM -0500, Josiah Frentsos wrote: > Index: grep.1 > === > RCS file: /cvs/src/usr.bin/grep/grep.1,v > retrieving revision 1.51 > diff -u -p -r1.51 grep.1 > --- grep.126 Jun 2022 10:57:36 - 1.51 > +++ grep.13 Jan 2023 16:52:05 - > @@ -304,7 +304,7 @@ file name. > This option makes the output unambiguous, even in the presence of file > names containing unusual characters like newlines. > This is similar to the > -.Ar -print0 > +.Fl print0 > option in > .Xr find 1 . > .El > fair enough. find(1) itself uses "Ic", but i suppose that makes sense for find.1, not grep.1. i also changed the description of print0 from "option" to "primary", since that is the language find(1) uses. jmc
Re: [PATCH v3 3/3] script(1): fix exit status wording
On Tue, Jan 03, 2023 at 03:57:20PM +0100, ?? wrote: > --- > Resend after a year; clean rebase. Keep me in CC. > > Failure-of-script status unchanged at 1 after complaints for v2. > > usr.bin/script/script.1 | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/usr.bin/script/script.1 b/usr.bin/script/script.1 > index aa8bb2790..aa55d43af 100644 > --- a/usr.bin/script/script.1 > +++ b/usr.bin/script/script.1 > @@ -80,10 +80,8 @@ or control-D > .Pq Ql ^D > will exit most interactive shells). > .Nm > -will exit with the status of 0 unless any of its child > -processes fail, in which case, > -.Nm > -will return 1. > +will exit with the status of the shell, > +or 1 if it couldn't execute it. > .Pp > Certain interactive commands, such as > .Xr vi 1 , > -- > 2.30.2 hi. can you provide some examples showing that your proposed text is correct and the current text wrong? jmc
Re: Suggested change to ports.7 man page
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. >
obsd install initial boot process slowed down
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. It is the second time I managed to install an encrypted obsd. The several installs I did, this used to happen at times, other times not. Now this is so frustrating because it prevents my obsd driver and computer to be PERFECT . Any help ? -- Sylvain Saboua PS this is posted to both lists because I am unsure which is which.
move the pf_state_tree_id type around
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?
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.c4 Jan 2023 02:00:49 - 1.1166
+++ pf.c4 Jan 2023 03:08:04 -
@@ -305,8 +305,8 @@ struct pf_pool_limit pf_pool_limits[PF_L
static __inline int pf_src_compare(struct pf_src_node *, struct pf_src_node *);
static inline int pf_state_compare_key(const struct pf_state_key *,
const struct pf_state_key *);
-static __inline int pf_state_compare_id(struct pf_state *,
- struct pf_state *);
+static inline int pf_state_compare_id(const struct pf_state *,
+ const struct pf_state *);
#ifdef INET6
static __inline void pf_cksum_uncover(u_int16_t *, u_int16_t, u_int8_t);
static __inline void pf_cksum_cover(u_int16_t *, u_int16_t, u_int8_t);
@@ -320,8 +320,7 @@ struct pf_state_list pf_state_list = PF_
RB_GENERATE(pf_src_tree, pf_src_node, entry, pf_src_compare);
RBT_GENERATE(pf_state_tree, pf_state_key, sk_entry, pf_state_compare_key);
-RB_GENERATE(pf_state_tree_id, pf_state,
-entry_id, pf_state_compare_id);
+RBT_GENERATE(pf_state_tree_id, pf_state, entry_id, pf_state_compare_id);
int
pf_addr_compare(const struct pf_addr *a, const struct pf_addr *b,
@@ -541,7 +540,7 @@ pf_src_connlimit(struct pf_state **state
struct pf_state *st;
pf_status.lcounters[LCNT_OVERLOAD_FLUSH]++;
- RB_FOREACH(st, pf_state_tree_id, _id) {
+ RBT_FOREACH(st, pf_state_tree_id, _id) {
sk = st->key[PF_SK_WIRE];
/*
* Kill states from this source. (Only those
@@ -715,8 +714,8 @@ pf_state_compare_key(const struct pf_sta
return (0);
}
-static __inline int
-pf_state_compare_id(struct pf_state *a, struct pf_state *b)
+static inline int
+pf_state_compare_id(const struct pf_state *a, const struct pf_state *b)
{
if (a->id > b->id)
return (1);
@@ -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));
}
int
@@ -1733,7 +1732,7 @@ pf_remove_state(struct pf_state *cur)
if (cur->key[PF_SK_STACK]->proto == IPPROTO_TCP)
pf_set_protostate(cur, PF_PEER_BOTH, TCPS_CLOSED);
- RB_REMOVE(pf_state_tree_id, _id, cur);
+ RBT_REMOVE(pf_state_tree_id, _id, cur);
#if NPFLOW > 0
if (cur->state_flags & PFSTATE_PFLOW)
export_pflow(cur);
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];
@@ -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();
[PATCH] Azalia bug in codec Realtek ALC892
Hi, everyone!
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
With this info I realized this patch (directly on OBSD-stable source,
sorry) and...work! Not audio problems in my PC using this patch (one day
testing, multiple apps using audio, not stuck/not latency problems).
If anybody can test, verify and give OK to this simple patch, I would
appreciate it (and I'm sure others would too, specially living in
-release versions).
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.c 8 Sep 2022 01:35:39 - 1.189
+++ azalia_codec.c 2 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";
--
Dios en su cielo, todo bien en la TierraIndex: 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.c 8 Sep 2022 01:35:39 - 1.189
+++ azalia_codec.c 2 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";
Re: ESRT support for the amd64 bootloader
On Wed, Dec 28, 2022 at 09:13:16PM +0100, Mark Kettenis wrote:
> Dear Sergii,
>
> Sorry for the delay, but I have finally found the time to work on the
> EFI variable and ESRT support for OpenBSD. As a first step, here is a
> diff that adds support for copying the ESRT in the bootloader and
> passing it on to the kernel.
>
> I adjusted your diff a bit. It now adds the new config_esrt member at
> the end of the bios_efiinfo struct and sets a flag to indicate that
> extra bit of information is present. That makes it possible to load
> new kernels with the old bootloader and vice versa.
>
> patrick@, mlarkin@, yasuoka@ and other devs: ok?
>
I am ok with this if not committed already. Thanks!
-ml
>
> Index: arch/amd64/include/biosvar.h
> ===
> RCS file: /cvs/src/sys/arch/amd64/include/biosvar.h,v
> retrieving revision 1.29
> diff -u -p -r1.29 biosvar.h
> --- arch/amd64/include/biosvar.h 29 Nov 2022 21:41:39 - 1.29
> +++ arch/amd64/include/biosvar.h 28 Dec 2022 20:03:32 -
> @@ -218,11 +218,13 @@ typedef struct _bios_efiinfo {
> uint32_tfb_reserved_mask;
> uint32_tflags;
> #define BEI_64BIT0x0001 /* 64-bit EFI implementation */
> +#define BEI_ESRT 0x0002 /* ESRT table */
> uint32_tmmap_desc_ver;
> uint32_tmmap_desc_size;
> uint32_tmmap_size;
> uint64_tmmap_start;
> uint64_tsystem_table;
> + uint64_tconfig_esrt;
> } __packed bios_efiinfo_t;
>
> #define BOOTARG_UCODE 12
> Index: arch/amd64/stand/efiboot/conf.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/conf.c,v
> retrieving revision 1.39
> diff -u -p -r1.39 conf.c
> --- arch/amd64/stand/efiboot/conf.c 12 Aug 2022 20:18:58 - 1.39
> +++ arch/amd64/stand/efiboot/conf.c 28 Dec 2022 20:03:32 -
> @@ -40,7 +40,7 @@
> #include "efidev.h"
> #include "efipxe.h"
>
> -const char version[] = "3.62";
> +const char version[] = "3.63";
>
> #ifdef EFI_DEBUG
> int debug = 0;
> Index: arch/amd64/stand/efiboot/efiboot.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
> retrieving revision 1.40
> diff -u -p -r1.40 efiboot.c
> --- arch/amd64/stand/efiboot/efiboot.c11 Jul 2022 19:45:02 -
> 1.40
> +++ arch/amd64/stand/efiboot/efiboot.c28 Dec 2022 20:03:32 -
> @@ -831,6 +831,7 @@ efi_com_putc(dev_t dev, int c)
> */
> static EFI_GUID acpi_guid = ACPI_20_TABLE_GUID;
> static EFI_GUID smbios_guid = SMBIOS_TABLE_GUID;
> +static EFI_GUID esrt_guid =
> EFI_SYSTEM_RESOURCE_TABLE_GUID;
> static intgopmode = -1;
>
> #define efi_guidcmp(_a, _b) memcmp((_a), (_b), sizeof(EFI_GUID))
> @@ -870,6 +871,34 @@ efi_makebootargs(void)
> >ConfigurationTable[i].VendorGuid) == 0)
> ei->config_smbios = (uintptr_t)
> ST->ConfigurationTable[i].VendorTable;
> + else if (efi_guidcmp(_guid,
> + >ConfigurationTable[i].VendorGuid) == 0)
> + ei->config_esrt = (uintptr_t)
> + ST->ConfigurationTable[i].VendorTable;
> + }
> +
> + /*
> + * Need to copy ESRT because call to ExitBootServices() frees memory of
> + * type EfiBootServicesData in which ESRT resides.
> + */
> + if (ei->config_esrt != 0) {
> + EFI_SYSTEM_RESOURCE_TABLE *esrt =
> + (EFI_SYSTEM_RESOURCE_TABLE *)ei->config_esrt;
> + size_t esrt_size = sizeof(*esrt) +
> + esrt->FwResourceCount * sizeof(EFI_SYSTEM_RESOURCE_ENTRY);
> + void *esrt_copy;
> +
> + /*
> + * Using EfiRuntimeServicesData as it maps to BIOS_MAP_RES,
> + * while EfiLoaderData becomes BIOS_MAP_FREE.
> + */
> + status = BS->AllocatePool(EfiRuntimeServicesData,
> + esrt_size, _copy);
> + if (status == EFI_SUCCESS) {
> + memcpy(esrt_copy, esrt, esrt_size);
> + ei->config_esrt = (uintptr_t)esrt_copy;
> + ei->flags |= BEI_ESRT;
> + }
> }
>
> /*
> Index: stand/efi/include/efiapi.h
> ===
> RCS file: /cvs/src/sys/stand/efi/include/efiapi.h,v
> retrieving revision 1.3
> diff -u -p -r1.3 efiapi.h
> --- stand/efi/include/efiapi.h7 Dec 2022 23:04:26 - 1.3
> +++ stand/efi/include/efiapi.h28 Dec 2022 20:03:32 -
> @@ -871,6 +871,10 @@ typedef struct {
>{ 0x49152e77, 0x1ada, 0x4764, \
> { 0xb7, 0xa2, 0x7a, 0xfe, 0xfe, 0xd9, 0x5e, 0x8b } }
>
>
Re: ESRT support for the amd64 bootloader
On Mon, Jan 02, 2023 at 05:52:12PM +, Peter Stuge wrote: > Mark Kettenis wrote: > > patrick@, mlarkin@, yasuoka@ and other devs: ok? > > Do what you have to do, but I plead to avoid (U)EFI lock-in as far as > technically possible, since most (U)EFI implementations are not open > source, and that does exist. > > I understand too well that (U)EFI is the modern popular firmware > interface and thus the only choice sometimes, just please do not > indulge here. > This diff does not indulge in anything. > > Thanks and kind regards > > //Peter >
grep.1: Use Fl for -print0
Index: grep.1 === RCS file: /cvs/src/usr.bin/grep/grep.1,v retrieving revision 1.51 diff -u -p -r1.51 grep.1 --- grep.1 26 Jun 2022 10:57:36 - 1.51 +++ grep.1 3 Jan 2023 16:52:05 - @@ -304,7 +304,7 @@ file name. This option makes the output unambiguous, even in the presence of file names containing unusual characters like newlines. This is similar to the -.Ar -print0 +.Fl print0 option in .Xr find 1 . .El
[PATCH v3 1/3] script(1): actually bubble child errors
script.1 says
> script will exit with the status of 0 unless any of its child
> processes fail, in which case, script will return 1.
This is a patent lie: it only exits with 1 if the host or writer
processes fail, not the actual child
Instead, wait for the child in the writer process and bubble its status
up verbatim (for signals ‒ as shell-style 128+sig)
---
Resend after a year; clean rebase. Keep me in CC.
usr.bin/script/script.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/usr.bin/script/script.c b/usr.bin/script/script.c
index da22623ff..763975d6a 100644
--- a/usr.bin/script/script.c
+++ b/usr.bin/script/script.c
@@ -251,16 +251,12 @@ dooutput(void)
sigemptyset();
sigaddset(, SIGALRM);
+ sigaddset(, SIGCHLD);
bzero(, sizeof sa);
sigemptyset(_mask);
sa.sa_handler = scriptflush;
(void)sigaction(SIGALRM, , NULL);
- bzero(, sizeof sa);
- sigemptyset(_mask);
- sa.sa_handler = SIG_IGN;
- (void)sigaction(SIGCHLD, , NULL);
-
if (pledge("stdio proc", NULL) == -1)
err(1, "pledge");
@@ -295,7 +291,17 @@ dooutput(void)
outcc += cc;
sigprocmask(SIG_UNBLOCK, , NULL);
}
- done(0);
+
+ int e = 0, err;
+ while ((err = wait()) == -1 && errno == EINTR)
+ ;
+ if (err != -1) {
+ if (WIFEXITED(e))
+ e = WEXITSTATUS(e);
+ else
+ e = 128 + WTERMSIG(e);
+ }
+ done(e);
}
void
--
2.30.2
signature.asc
Description: PGP signature
[PATCH v3 2/3] script(1): simplify shell execution
Use execl in both paths and the same warn() call
---
Resend after a year; clean rebase. Keep me in CC.
usr.bin/script/script.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/usr.bin/script/script.c b/usr.bin/script/script.c
index 763975d6a..fd2829033 100644
--- a/usr.bin/script/script.c
+++ b/usr.bin/script/script.c
@@ -313,10 +313,7 @@ scriptflush(int signo)
void
doshell(char *cmd)
{
- char *shell;
- char *argp[] = {"sh", "-c", NULL, NULL};
-
- shell = getenv("SHELL");
+ const char *shell = cmd ? NULL : getenv("SHELL");
if (shell == NULL)
shell = _PATH_BSHELL;
@@ -324,14 +321,12 @@ doshell(char *cmd)
(void)fclose(fscript);
login_tty(slave);
- if (cmd != NULL) {
- argp[2] = cmd;
- execv(_PATH_BSHELL, argp);
- warn("unable to execute %s", _PATH_BSHELL);
- } else {
+ if (cmd != NULL)
+ execl(shell, "sh", "-c", cmd, (char *)NULL);
+ else
execl(shell, shell, "-i", (char *)NULL);
- warn("%s", shell);
- }
+
+ warn("unable to execute %s", shell);
fail();
}
--
2.30.2
signature.asc
Description: PGP signature
[PATCH v3 3/3] script(1): fix exit status wording
--- Resend after a year; clean rebase. Keep me in CC. Failure-of-script status unchanged at 1 after complaints for v2. usr.bin/script/script.1 | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/usr.bin/script/script.1 b/usr.bin/script/script.1 index aa8bb2790..aa55d43af 100644 --- a/usr.bin/script/script.1 +++ b/usr.bin/script/script.1 @@ -80,10 +80,8 @@ or control-D .Pq Ql ^D will exit most interactive shells). .Nm -will exit with the status of 0 unless any of its child -processes fail, in which case, -.Nm -will return 1. +will exit with the status of the shell, +or 1 if it couldn't execute it. .Pp Certain interactive commands, such as .Xr vi 1 , -- 2.30.2 signature.asc Description: PGP signature
Re: move the pf_state_tree type around
> On 3 Jan 2023, at 17:47, Alexandr Nedvedicky wrote: > > Hello, > > On Tue, Jan 03, 2023 at 03:31:42PM +1000, David Gwynne wrote: >> the pf_state_tree type represents the rb tree that pf_state_key structs >> go into. currently pf_state_key is declared in pfvar_priv.h (because >> it's a kernel private data structure) but pf_state_tree was left in >> pfvar.h. this moves it to pfvar_priv.h, because it is also kernel >> private. >> >> while here, this moves it from the RB tree macros to RBT which shrinks >> pf.o by about 13k on amd64. > >diff reads OK to me. Do I assume right 'tree_id' tree will >be also moved from RB_*() to RBT_() in another commit? yes, sorry, i was going to say that. > thanks and OK sashan i'll put it in when im awake. cheers, dlg
Best Saudi Quality Managment Solution
FREE Trial and Special Discounts [1] None [2] ** Visit Website [3] ARMS For Information Technologies شركة ارمس لتقنية المعلومات* Unsubscribe [4] | Contact [5] 2023 All Rights Reserved [6] [7] [1] http://url9807.armsit.com/ls/click?upn=BXqOu0kOttjRu3UnUAt5Ay0oNghjDsq9JKLUBU7POrc4geQ15gkETwFWvcHeFBinsDVrAqLCL53DzSEqY8V49w-3D-3D2xa8_-2B8rDeUnZs6T4iEYkzOVw1Bza1KPpw3YcM3rG5h56ykFb2-2BnvVnUcBFPSYs8zXVn1arGxD0GxKoMvKHOVj6UD6AkMlxvHUGTbQ7zCPRUgfQcziMEpdGp-2Fb5eVLH87CJUl8aJ02J4MI57x-2BMP8UvgAHuKqawv-2B7myQB74FYZyIv-2FVmVaTiNkTwslo9bsAOJxVeZmT82N2vJLjlIazHErz1-2Bw-3D-3D [2] http://url9807.armsit.com/ls/click?upn=BXqOu0kOttjRu3UnUAt5Ay0oNghjDsq9JKLUBU7POrcBK-2FS3AEz1883z7F2nddZzs5z7F-2FdEpPdub9EgbnJYZA-3D-3DSG6E_-2B8rDeUnZs6T4iEYkzOVw1Bza1KPpw3YcM3rG5h56ykFb2-2BnvVnUcBFPSYs8zXVn1O7lMcQdJqGqh8R-2BgruvoGMHWHsd-2BKOfBVv-2BRLelCJwU-2B9GlGWxAdObelBmCIeX0iaOf8kNbuaO-2FoPk7JT7Y5C3OJOJ9RFtkXtL26RepjOMMO-2BwexfNansJCTeTga-2BbEEj3TBMfdp40awUKBIP-2Bj5yA-3D-3D [3] http://url9807.armsit.com/ls/click?upn=BXqOu0kOttjRu3UnUAt5Ay0oNghjDsq9JKLUBU7POrcBK-2FS3AEz1883z7F2nddZzs5z7F-2FdEpPdub9EgbnJYZA-3D-3DUZx4_-2B8rDeUnZs6T4iEYkzOVw1Bza1KPpw3YcM3rG5h56ykFb2-2BnvVnUcBFPSYs8zXVn1fdEgnFmynCjhnACoT-2BQDoSX-2BK0cQ8qntk4hQDHOWvNhxlN8LYAIMmELYEetFicbL2l-2FJW8-2FM4vTWmMBO3y8kERpIj7tA7SbvAjE5rRh5uHheZuinyTEtYRI3wI6ctffVbNhNd4ZiWP13jQ0oKSPDdQ-3D-3D [4] http://url9807.armsit.com/ls/click?upn=BXqOu0kOttjRu3UnUAt5Ay0oNghjDsq9JKLUBU7POrcQ4-2BbxogBblfxwbNmF9JbBJX6X0i5iW7-2Be2C5qUWVkpQ-3D-3DJKhW_-2B8rDeUnZs6T4iEYkzOVw1Bza1KPpw3YcM3rG5h56ykFb2-2BnvVnUcBFPSYs8zXVn1mOhF-2FkXWCB2kqRcYdo5ZDfWEV5QrYR0cYP3bpNoKMmaGLAL7yCHqpwQf2D-2FNyc2te1sw5zBHJq7tqlh6T7IlWkqvBSaSUM24XvbpmQ8n-2BiAXX8dV1ugRveTzQ6Jr8noRS35UzHmViqpRJ-2BkAGQgoTg-3D-3D [5] http://url9807.armsit.com/ls/click?upn=BXqOu0kOttjRu3UnUAt5Ay0oNghjDsq9JKLUBU7POrekZr6MFJeAQa08sOjr-2BKdDnhaI6WcSOewzh67Lq8UNmQ-3D-3Dxu_N_-2B8rDeUnZs6T4iEYkzOVw1Bza1KPpw3YcM3rG5h56ykFb2-2BnvVnUcBFPSYs8zXVn1QbkfVmJyFCMe-2FrfCxCWk5S5-2BTkVhod6rNqmzSy7Ajr8VgWSaqw6VSBf61wQaYjNLuys37qd3puc2kYAEPJTBRoVT0gSvOF03mSFml8fofF1pZLPx8Kp8WcxQ1t-2Fg8w59Nb9D4gcmQR0bojKvw7QfCg-3D-3D [6] http://url9807.armsit.com/ls/click?upn=BXqOu0kOttjRu3UnUAt5Ay0oNghjDsq9JKLUBU7POrcuLAJBc0tCMPpXmn1Iq5Y4aK85-2FaT68CQbBCdNIxvXwA-3D-3DolHN_-2B8rDeUnZs6T4iEYkzOVw1Bza1KPpw3YcM3rG5h56ykFb2-2BnvVnUcBFPSYs8zXVn18U-2Bcdrf10rLz6dWKaNXJ-2FawbUsoJNXZC7hxQM52tgOpPzi-2BmNsYrfOHVWAhNNF3gXnpVFPmzgJOAiAqDaQiCGUt2IEHie2RTgX7vjUJpStDyxYV0alL1TFlQWCY0-2BzQbLPvjXiqLt79i-2FHyiBCNf8Q-3D-3D [7] http://url9807.armsit.com/ls/click?upn=BXqOu0kOttjRu3UnUAt5Ay0oNghjDsq9JKLUBU7POrcAJp7VvKL0D-2FSd4bUDzADWiP-2FoCePOtlRFhP-2FKV-2BQDqw-3D-3DAZGQ_-2B8rDeUnZs6T4iEYkzOVw1Bza1KPpw3YcM3rG5h56ykFb2-2BnvVnUcBFPSYs8zXVn1Bs5HsTvmLSwvm1-2BxaQ-2BNhzsskqFjVFzAFDhHSd7V4ycRaovurZ8xenXSE5NZyqXQp47xYhNmZ5ujprhIiPhL0nu5TY7dp8vKHkgWM1SWsEuM9iyXDXkaSaY15xjBvD6jX1XRp2FQg4OTTeAdVFhBvQ-3D-3D
Re: audioctl: display variables periodically
On Sat, Dec 10, 2022 at 09:39:41AM +, Edd Barrett wrote: > I agree with ratchov that in this instance, precise timing isn't important. > So, are we OK with this or there are still objections?
