Adjust url of SD Association in comment in sdhc.c
hi, the legit URL of the SD Associations is www.sdcard.org, not www.sdcard.com. felix Index: sys/dev/sdmmc/sdhc.c === RCS file: /cvs/src/sys/dev/sdmmc/sdhc.c,v retrieving revision 1.69 diff -u -p -u -r1.69 sdhc.c --- sys/dev/sdmmc/sdhc.c14 Aug 2020 14:49:04 - 1.69 +++ sys/dev/sdmmc/sdhc.c13 Jun 2021 03:36:39 - @@ -18,7 +18,7 @@ /* * SD Host Controller driver based on the SD Host Controller Standard - * Simplified Specification Version 1.00 (www.sdcard.com). + * Simplified Specification Version 1.00 (www.sdcard.org). */ #include -- GPG/PGP: 7A0B612C / 5F4D 9B06 C240 3250 35BF 66ED 1AD3 A9B8 7A0B 612C https://hazardous.org/ - f...@hazardous.org - fkr@irc - @felixkronlage
Re: add table_procexec in smtpd
Re-sending, I forgot to cc: aisha & tech: > On 12 Jun 2021, at 22:47, Gilles CHEHADE wrote: > >> >> On 12 Jun 2021, at 15:15, Eric Faurot wrote: >> >> On Wed, Jun 09, 2021 at 05:41:36PM -0400, Aisha Tammy wrote: >>> Hi, >>> Here is the updated diff, which removes table_proc and adds table_procexec >>> as the default backend when no backend name matches. >>> >> >> Hi. >> >> I'm not opposed to the idea, but I have a couple of comments: >> >> First, if the two implementations are not going to coexists, >> we can just replace table_proc.c. > > True, though proc-exec was the name used for filters so it may be a good to > unify and drop the legacy “proc” name. > This will be hidden to users so quite frankly it’s a matter of dev preference. > > >> Second, since the goal is to expose the protocol directly, instead of >> relying on wrappers (through opensmtpd-extras api), we should take >> time to refine it properly before, and avoid having to bump it every >> other day. For example, I don't see the point of adding timestamps in >> the request. Do we want to be case-sensitive on the commands? Do we >> need some kind of handshake? Also, there can be long-term plan to use >> the same process for different tables, or even for other backends. > > I’m unsure I understand your point: > > The protocol is based on the filter protocol, follows the same logic and line > header to solve the same issues, this is precisely so that there’s no need to > bump every other day as we already figured what was needed for third party > adding to interoperate with smtpd. > This also has the advantage that you can have a single parser handle these > different API instead of having a filter protocol parser, a table protocol > parser (and maybe in the future a queue protocol parser… etc). > > WRT timestamps there were many uses for them ranging from timeout detection > both in daemon / add-ons, profiling, logging the time an event was generated > vs processes overhead, etc… > It allowed ensuring that all addons handling the same event have the exact > same timestamp associated to the event. > > WRT to case-sensitivity, I don’t recall using upper-case myself, to me the > protocol is case-sensitive and as far as I can remember I always used > lowercase :-/ > I’m all for lowering case here. > > WRT to handshake, it has multiple uses ranging from ensuring the addons get > their configuration from the daemon to synchronising the daemon start with > addons readiness. > Remember, we didn’t have this with filters and realised we couldn’t do > without, it is the same for tables, they need to get their “table name” at > start so we need the daemon to pass them, and we also need the daemon to not > start using them before they are ready. > > >> Finally the implementation could be factorized a bit, but that's a >> detail at this time. I think the close operation (is it really useful >> anyway?) >> should use fclose() instead of kill(), and maybe wait() too? > > The implementation can probably be improved, this was a PoC that allowed me > to write various table backends but it was never meant to be committed in the > first place.
Re: add table_procexec in smtpd
> On 12 Jun 2021, at 18:57, Aisha Tammy wrote: > > On 6/12/21 9:15 AM, Eric Faurot wrote: >> On Wed, Jun 09, 2021 at 05:41:36PM -0400, Aisha Tammy wrote: >>> Hi, >>> Here is the updated diff, which removes table_proc and adds >>> table_procexec as the default backend when no backend name matches. >>> >> Hi. >> >> I'm not opposed to the idea, but I have a couple of comments: >> >> First, if the two implementations are not going to coexists, >> we can just replace table_proc.c. > Sounds good with me :D >> >> Second, since the goal is to expose the protocol directly, instead of >> relying on wrappers (through opensmtpd-extras api), we should take >> time to refine it properly before, and avoid having to bump it every >> other day. For example, I don't see the point of adding timestamps in >> the request. > My WIP LDAP wrapper does not use the timestamps. I have not been privy to the > historical context of the development of this protocol, so I do not know why > it exists. > I am fine with removing it. I’m unsure removing them would be a good idea, not only it wouldn’t bring any benefit but it would prevent tracking the time an event was generated in the daemon from a table backend and would make the protocol diverge from the filters protocol while they are the same protocol as of today and could use the same parser with different handler functions based on the event field. >> Do we want to be case-sensitive on the commands? > I reused the current table_service_name function present in table.c and hence > set it to all-caps. I think keeping it such is not an issue but I don't care > if we move to lowercase. > I would prefer being case sensitive, so as not to overly-complicate our > checks. I agree. >> Do we need some kind of handshake? > I do not see a need for this between the table-open and the table-process. > The table-process may do handshakes (or whatever) in its backend, which we > should not be worrying about. Maybe I misunderstood but the handshake is very much needed between the daemon and non-builtin tables, similarly to filters. This is what guarantees that the daemon doesn’t start using a table that’s not ready but also what allows passing daemon informations to table backends so they build their initial state. >> Also, there can be long-term plan to use >> the same process for different tables, or even for other backends. >> >> Finally the implementation could be factorized a bit, but that's a >> detail at this time. I think the close operation (is it really useful >> anyway?) >> should use fclose() instead of kill(), and maybe wait() too? > I agree, I am not sure if the table-close is very useful. I am also fine with > moving it to fclose, though I don't know how to manually close a table >.< > > BTW, can I remove the table_check function? I haven't seen a use for it even > after scrounging around a bit. > > Unless any comments, I'll send the next patch (soonish) with fclose and > timestamps, table_check removed. >
Re: upgrade pixman to version 0.40
Hi again, On Sat, 5 Jun 2021 09:47:16 +0200 Matthieu Herrb wrote: > Hi, > > the patch below updates the pixman library to version 0.40. > > To test, apply the patch in $XSRCDIR/lib/pixman using > > patch -p0 -E < /this/patch > > and the rebuild xenocara according to release(8). > It builds fine on powerpc. I've tested a fvwm session with various base X11 utils without issues. Also, the below hunk did not apply properly. Charlène. > Index: aclocal.m4 > === > RCS file: /cvs/OpenBSD/xenocara/lib/pixman/aclocal.m4,v > retrieving revision 1.13 > diff -u -p -u -r1.13 aclocal.m4 > --- aclocal.m411 May 2019 07:46:06 - 1.13 > +++ aclocal.m410 Jan 2021 13:36:25 - > @@ -8606,9 +8606,9 @@ m4_ifndef([_LT_PROG_F77], > [AC_DEFUN([_L m4_ifndef([_LT_PROG_FC], > [AC_DEFUN([_LT_PROG_FC])]) m4_ifndef([_LT_PROG_CXX], > [AC_DEFUN([_LT_PROG_CXX])]) > -dnl pkg.m4 - Macros to locate and utilise pkg-config. -*- Autoconf > -*- -dnl serial 11 (pkg-config-0.29.1) > -dnl > +# pkg.m4 - Macros to locate and utilise pkg-config. -*- Autoconf > -*- +# serial 12 (pkg-config-0.29.2) > + > dnl Copyright © 2004 Scott James Remnant . > dnl Copyright © 2012-2015 Dan Nicholson > dnl
Re: cwm: Exclude ignored windows from search menu
On Sat, Jun 12, 2021 at 10:41:05PM +0200, Leon Fischer wrote: > There is no use in listing ignored windows, which are generally used as > for "status bars", in the window search menu (M-slash). It clutters up > the menu with persistent windows that the user would very rarely want > to focus. `M-/fooCM-x' seems like the canonical way to quickly close ignored windows, but also in general I consider search to be inclusive. > This patch excludes them from menu-window and menu-window-hidden. > They can be focused with the mouse instead if needed. It kills the last effective way to select such windows: What if there is no mouse? What if there are lots of windows and you have to reshuffle by moving or pushing them to the background in order to find ignored windows? Seems like a big step backward; I think the current ignore semantics are useful and sane as they are.
Re: add table_procexec in smtpd
On 6/12/21 9:15 AM, Eric Faurot wrote: On Wed, Jun 09, 2021 at 05:41:36PM -0400, Aisha Tammy wrote: Hi, Here is the updated diff, which removes table_proc and adds table_procexec as the default backend when no backend name matches. Hi. I'm not opposed to the idea, but I have a couple of comments: First, if the two implementations are not going to coexists, we can just replace table_proc.c. Sounds good with me :D Second, since the goal is to expose the protocol directly, instead of relying on wrappers (through opensmtpd-extras api), we should take time to refine it properly before, and avoid having to bump it every other day. For example, I don't see the point of adding timestamps in the request. My WIP LDAP wrapper does not use the timestamps. I have not been privy to the historical context of the development of this protocol, so I do not know why it exists. I am fine with removing it. Do we want to be case-sensitive on the commands? I reused the current table_service_name function present in table.c and hence set it to all-caps. I think keeping it such is not an issue but I don't care if we move to lowercase. I would prefer being case sensitive, so as not to overly-complicate our checks. Do we need some kind of handshake? I do not see a need for this between the table-open and the table-process. The table-process may do handshakes (or whatever) in its backend, which we should not be worrying about. Also, there can be long-term plan to use the same process for different tables, or even for other backends. Finally the implementation could be factorized a bit, but that's a detail at this time. I think the close operation (is it really useful anyway?) should use fclose() instead of kill(), and maybe wait() too? I agree, I am not sure if the table-close is very useful. I am also fine with moving it to fclose, though I don't know how to manually close a table >.< BTW, can I remove the table_check function? I haven't seen a use for it even after scrounging around a bit. Unless any comments, I'll send the next patch (soonish) with fclose and timestamps, table_check removed. Cheers, Aisha Eric.
cwm: Exclude ignored windows from search menu
There is no use in listing ignored windows, which are generally used as
for "status bars", in the window search menu (M-slash). It clutters up
the menu with persistent windows that the user would very rarely want
to focus.
This patch excludes them from menu-window and menu-window-hidden.
They can be focused with the mouse instead if needed.
Index: cwmrc.5
===
RCS file: /cvs/xenocara/app/cwm/cwmrc.5,v
retrieving revision 1.76
diff -u -p -r1.76 cwmrc.5
--- cwmrc.5 16 Apr 2020 13:32:35 - 1.76
+++ cwmrc.5 12 Jun 2021 20:28:27 -
@@ -193,7 +193,7 @@ The default is 50.
.It Ic ignore Ar windowname
Ignore, and do not warp to, windows with the name
.Ar windowname
-when drawing borders and cycling through windows.
+when drawing borders, searching windows and cycling through windows.
.It Ic moveamount Ar pixels
Set a default size for the keyboard movement bindings,
in pixels.
Index: kbfunc.c
===
RCS file: /cvs/xenocara/app/cwm/kbfunc.c,v
retrieving revision 1.170
diff -u -p -r1.170 kbfunc.c
--- kbfunc.c20 Mar 2020 18:50:08 - 1.170
+++ kbfunc.c12 Jun 2021 20:28:27 -
@@ -516,6 +516,8 @@ kbfunc_menu_client(void *ctx, struct car
TAILQ_INIT();
TAILQ_FOREACH(cc, >clientq, entry) {
+ if (cc->flags & CLIENT_IGNORE)
+ continue;
if ((cargs->flag & CWM_MENU_WINDOW_ALL) ||
(cc->flags & CLIENT_HIDDEN))
menuq_add(, cc, NULL);
Re: fix isascii(3) manpage
On Fri, Jun 11, 2021 at 09:56:20AM +, Miod Vallat wrote: > All the is*() ctype.h functions take an int as argument, but valid > values are only EOF, and the range of values of `unsigned char'. > > All, but one: the XPG4 isascii(), which has no such restriction. > Quoting https://pubs.opengroup.org/onlinepubs/9699919799/ : > ``The isascii() function is defined on all integer values.'' > > Hence the following diff. > fixed, thanks! jmc > Index: isascii.3 > === > RCS file: /OpenBSD/src/lib/libc/gen/isascii.3,v > retrieving revision 1.13 > diff -u -p -r1.13 isascii.3 > --- isascii.3 17 Jul 2013 05:42:11 - 1.13 > +++ isascii.3 11 Jun 2021 09:54:13 - > @@ -77,11 +77,3 @@ The > .Fn isascii > function first appeared in > .At v7 . > -.Sh CAVEATS > -The argument to > -.Fn isascii > -must be > -.Dv EOF > -or representable as an > -.Li unsigned char ; > -otherwise, the result is undefined. >
Re: add table_procexec in smtpd
On Wed, Jun 09, 2021 at 05:41:36PM -0400, Aisha Tammy wrote: > Hi, > Here is the updated diff, which removes table_proc and adds table_procexec > as the default backend when no backend name matches. > Hi. I'm not opposed to the idea, but I have a couple of comments: First, if the two implementations are not going to coexists, we can just replace table_proc.c. Second, since the goal is to expose the protocol directly, instead of relying on wrappers (through opensmtpd-extras api), we should take time to refine it properly before, and avoid having to bump it every other day. For example, I don't see the point of adding timestamps in the request. Do we want to be case-sensitive on the commands? Do we need some kind of handshake? Also, there can be long-term plan to use the same process for different tables, or even for other backends. Finally the implementation could be factorized a bit, but that's a detail at this time. I think the close operation (is it really useful anyway?) should use fclose() instead of kill(), and maybe wait() too? Eric.
Re: ifnewlladdr spl
Is it expected interrupt handlers modify ifp->if_flags?
> On 10 Jun 2021, at 20:17, Alexander Bluhm wrote:
>
> Hi,
>
> I have seen this crash trace on a 6.6 based system, but I think the
> bug exists still in -current. It happened when an ixl(4) interface
> was removed from trunk(4).
>
> uvm_fault(0xfd8739dc6558, 0x0, 0, 1) -> e
> fatal page fault in supervisor mode
> trap type 6 code 0 rip 81012a86 cs 8 rflags 10202 cr2 0 cpl 7 rsp
> 80002e4bd170
> gsbase 0x816d6ff0 kgsbase 0x0
> panic: trap type 6, code=0, pc=81012a86
> Starting stack trace...
> panic() at panic+0x113
> kerntrap(80bf3000) at kerntrap+0xdc
> alltraps_kern_meltdown(6,0,4,0,80bf3000,0) at
> alltraps_kern_meltdown+0x7b
> ixl_intr(80bf3000) at ixl_intr+0x3e6
> intr_handler(816d6ff0,80b57200) at intr_handler+0x5b
> Xintr_ioapic_edge30_untramp(4,814d3a00,4,18041969,816d6ff0,d)
> at Xintr_ioapic_edge30_untramp+0x19f
> Xspllower(8178fb58,816d6ff0,8139d743,80bffd00,8178fb40,10)
> at Xspllower+0xc
> softintr_dispatch(0) at softintr_dispatch+0xc5
> Xsoftclock(80bf3048,0,8139d743,80bf3048,81207800,814e862f)
> at Xsoftclock+0x1f
> ifnewlladdr(81624e10) at ifnewlladdr+0xf8
> trunk_port_destroy(80002e4bd6e0) at trunk_port_destroy+0x2fd
> trunk_ioctl(fd87387594c0,81207800,8048698e) at trunk_ioctl+0x6a6
> ifioctl(fd87623df448,80002e46e2d8,48,80002e4bd7d0) at
> ifioctl+0x2d6
> sys_ioctl(360,80002e46e2d8,36) at sys_ioctl+0x3cd
> syscall(0) at syscall+0x3d1
> Xsyscall(6,36,1,36,7f7da720,7f7daa21) at Xsyscall+0x128
> end of kernel
> end trace frame: 0x7f7da780, count: 241
> End of stack trace.
> syncing disks...
>
> ifnewlladdr() is interrupted by ixl transmit interrupt. There it
> crashes in ixl_txeof as txr is NULL. The code in -current if_ixl.c
> has changed, so it might not happen anymore. But I think the bug
> is in ifnewlladdr().
>
> ifnewlladdr() sets splnet() and configures the interface up and
> down. The ixl_down() code has some interrupt barriers which cannot
> work while interrupts are blocked by splnet(). So interrupts fire
> at splx() when the driver does not expect them.
>
> Combining interrupt barriers with spl protection looks like a bad
> idea.
>
> Is there anything that lowers spl in all cases during intr_barrier(),
> ifq_barrier() or timeout_del_barrier()?
>
> How should spls work together with barriers?
>
> The integrity of ifnewlladdr() state should be guaranteed by netlock.
> Changing if_flags needs splnet() as they are used by all drivers.
> The in6_ functions need netlock. And driver SIOCSIFFLAGS ioctl
> must not have splnet().
>
> Is reducing splnet() the correct aproach?
>
> bluhm
>
> Index: net/if.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/if.c,v
> retrieving revision 1.641
> diff -u -p -r1.641 if.c
> --- net/if.c 25 May 2021 22:45:09 - 1.641
> +++ net/if.c 10 Jun 2021 14:32:12 -
> @@ -3109,6 +3109,8 @@ ifnewlladdr(struct ifnet *ifp)
> short up;
> int s;
>
> + NET_ASSERT_LOCKED();
> +
> s = splnet();
> up = ifp->if_flags & IFF_UP;
>
> @@ -3116,11 +3118,14 @@ ifnewlladdr(struct ifnet *ifp)
> /* go down for a moment... */
> ifp->if_flags &= ~IFF_UP;
> ifrq.ifr_flags = ifp->if_flags;
> + splx(s);
> (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t));
> + s = splnet();
> }
>
> ifp->if_flags |= IFF_UP;
> ifrq.ifr_flags = ifp->if_flags;
> + splx(s);
> (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t));
>
> #ifdef INET6
> @@ -3139,11 +3144,12 @@ ifnewlladdr(struct ifnet *ifp)
> #endif
> if (!up) {
> /* go back down */
> + s = splnet();
> ifp->if_flags &= ~IFF_UP;
> ifrq.ifr_flags = ifp->if_flags;
> + splx(s);
> (*ifp->if_ioctl)(ifp, SIOCSIFFLAGS, (caddr_t));
> }
> - splx(s);
> }
>
> void
>
