Re: wg(4) ipv6 ospf6d
On Thu, Aug 26, 2021 at 12:20:58AM +0100, Stuart Henderson wrote: > On 2021/08/25 19:58, Crystal Kolipe wrote: > > On Wed, Aug 25, 2021 at 06:02:11PM +0100, Stuart Henderson wrote: > > > If I manually configure a link-local the interface is successfully > > > added. > > > > > > Anyone have an idea what the behaviour should be here? For passive > > > would it make sense to accept an interface without link-local? > > > > Is there a specific use case for leaving the interface configured without > > IPv6 link-local? > > > > We use IPv6 extensively, (and are aware of various issues with the OpenBSD > > IPv6 implementation), but I'm not aware of any advantage or problem that is > > resolved by deliberately removing or not configuring link-local. If we > > support this particular case of wg on such an interface, and by extension > > encourage the general practice, then users with little experience of IPv6 > > are likely to start shooting themselves in the foot by disabling it on a > > whim. > > > > If there is a problem somewhere that is resolved by removing IPv6 > > link-local, I'm curious to know what it is. > > > > It's not a question of "removing IPv6 link-local", with wg it is not > there at all unless you go out your way and explicitly configure a > link-local address. Then surely the correct solution is to ensure that wg interfaces with any IPv6 address configured also present a link-local, rather than trying to accomodate the the non-standard configuration of an interface which doesn't? That is why I asked if there was a use case which I wasn't aware of. This would also make the behaviour of wg more consistent with other methods of implementing a VPN. For example, we tend to use ipsec exclusively over IPv6 binding it to various vether interfaces at the endpoints, and those vether interfaces gain usable IPv6 link local addresses automatically as expected. Even if ospf6d is changed to accept an interface without link-local, wouldn't it still be desirable for wg interfaces to configure a locally scoped address just as vether does?
Re: ucc(4): enumerate all usages
Anton Lindqvist writes: > As the Consumer Control usages are well defined by the HID Usage Tables > specification ucc might as well enumerate all of them. Finding an > appropriate scan code recognized by X11 for each usage is more tricky. > I've added a few more but the majority are still unmapped. Linux has > defined a couple of more usages covered by the evdev key codes > ($xenocara/dist/xkeyboard-config/keycodes/evdev) but those symbols are > not picked up in an vanilla X11 configuration on OpenBSD, according to > setxkbmap(1). Looks like most of the rest of the plumbing is missing for my buttons. I do get the pretty-printed names (below). Sadly no xev wiggling with or without this patch with my devices. > This should at least lower the barrier for adding scan codes for wanted > keys. > > Note that the strings are discarded unless UCC_DEBUG is enabled. With this patch I get this prettier output: uhidev2 at uhub3 port 2 configuration 1 interface 2 "Kinesis Advantage2 Keyboard" rev 2.00/1.00 addr 4 uhidev2: iclass 3/0, 2 report ids ucc0 at uhidev2 reportid 1ucc_add_key: bit 0, usage "Scan Next Track" ucc_add_key: bit 1, usage "Scan Previous Track" ucc_add_key: bit 2, usage "Play/Pause" ucc_add_key: bit 3, usage "Mute" ucc_add_key: bit 4, usage "Volume Increment" ucc_add_key: bit 5, usage "Volume Decrement" ucc_add_key: bit 6, usage "AL Calculator" : 7 usages, 7 keys, enum wskbd2 at ucc0 mux 1 uhid0 at uhidev2 reportid 2: input=1, output=0, feature=0 uaudio0 at uhub0 port 5 configuration 1 interface 1 "Google Pixel USB-C earbuds" rev 2.00/0.20 addr 7 uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 7 ctls audio1 at uaudio0 uhidev5 at uhub0 port 5 configuration 1 interface 3 "Google Pixel USB-C earbuds" rev 2.00/0.20 addr 7 uhidev5: iclass 3/0, 5 report ids uhid1 at uhidev5 reportid 1: input=1, output=0, feature=0 uhid2 at uhidev5 reportid 4: input=0, output=38, feature=0 ucc1 at uhidev5 reportid 5ucc_add_key: bit 0, usage "Volume Increment" ucc_add_key: bit 1, usage "Volume Decrement" ucc_add_key: bit 2, usage "Play/Pause" : 37 usages, 3 keys, enum wskbd3 at ucc1 mux 1 The earbuds buttons are working when connected to a phone, so they aren't damaged. Thanks Greg
Re: wg(4) ipv6 ospf6d
On 2021/08/25 19:58, Crystal Kolipe wrote: > On Wed, Aug 25, 2021 at 06:02:11PM +0100, Stuart Henderson wrote: > > If I manually configure a link-local the interface is successfully > > added. > > > > Anyone have an idea what the behaviour should be here? For passive > > would it make sense to accept an interface without link-local? > > Is there a specific use case for leaving the interface configured without > IPv6 link-local? > > We use IPv6 extensively, (and are aware of various issues with the OpenBSD > IPv6 implementation), but I'm not aware of any advantage or problem that is > resolved by deliberately removing or not configuring link-local. If we > support this particular case of wg on such an interface, and by extension > encourage the general practice, then users with little experience of IPv6 are > likely to start shooting themselves in the foot by disabling it on a whim. > > If there is a problem somewhere that is resolved by removing IPv6 link-local, > I'm curious to know what it is. > It's not a question of "removing IPv6 link-local", with wg it is not there at all unless you go out your way and explicitly configure a link-local address.
Re: wg(4) ipv6 ospf6d
On Wed, Aug 25, 2021 at 06:02:11PM +0100, Stuart Henderson wrote: > If I manually configure a link-local the interface is successfully > added. > > Anyone have an idea what the behaviour should be here? For passive > would it make sense to accept an interface without link-local? Is there a specific use case for leaving the interface configured without IPv6 link-local? We use IPv6 extensively, (and are aware of various issues with the OpenBSD IPv6 implementation), but I'm not aware of any advantage or problem that is resolved by deliberately removing or not configuring link-local. If we support this particular case of wg on such an interface, and by extension encourage the general practice, then users with little experience of IPv6 are likely to start shooting themselves in the foot by disabling it on a whim. If there is a problem somewhere that is resolved by removing IPv6 link-local, I'm curious to know what it is.
Re: wg(4) ipv6 ospf6d
On 2021/08/25 13:33, Daniel Jakots wrote: > On Wed, 25 Aug 2021 18:02:11 +0100, Stuart Henderson > wrote: > > > If I manually configure a link-local the interface is successfully > > added. > > > > Anyone have an idea what the behaviour should be here? For passive > > would it make sense to accept an interface without link-local? > > I discussed about that with remi@ a few months ago when I considered > using ospf6d, as I had the same cryptic error than you give. I was told: > > > ospf6d can not work without a link-local address on the interface. > > RFC 5340 mandates the use of link-local addresses in section 2.5. > > And here's a link to the mentioned section: > https://datatracker.ietf.org/doc/html/rfc5340#section-2.5 > > Cheers, > Daniel Thanks, but in itself that doesn't give a reason to have this restriction on a "passive" interface, in that case it's only redistributing the network on the interface, not sending OSPF packets on the interface itself.
Re: wg(4) ipv6 ospf6d
Stefan Sperling(s...@stsp.name) on 2021.08.25 22:02:02 +0200:
> On Wed, Aug 25, 2021 at 08:13:26PM +0200, Florian Obser wrote:
> > On 2021-08-25 18:02 +01, Stuart Henderson wrote:
> > > Trying to announce a network on a wg(4) interface via ospf6d, just
> > > using passive to pick up the prefix, i.e.
> > >
> > > interface wg0 { passive }
> > >
> > > It's failing with "/etc/ospf6d.conf:10: unnumbered interface wg0".
> > >
> > > With -v I get 'interface with index 27 not found' (this is "normal"
> > > with ospf6d) and the routable address does show up e.g. "if_newaddr:
> > > ifindex 27, addr 2a03::xx:xx::/64" before giving the
> > > unnumbered interface error. There is normally no link-local address
> > > for wg.
> > >
> > > If I manually configure a link-local the interface is successfully
> > > added.
> > >
> > > Anyone have an idea what the behaviour should be here? For passive
> > > would it make sense to accept an interface without link-local?
> > >
> >
> > RFC 4291 2.1:
> >All interfaces are required to have at least one Link-Local unicast
> >address.
>
> If you're not using the interface to send or receive OSPF messages this
> should not matter. I doubt the RFC authors considered the possibility
> of an IPv6-capable interface that doesn't support link-local.
Thats because by definition it's not IPv6 capable :-P
In this case, it should be possible to distribute a route that points to the
wg peer using
redistribute _prefix_ depend on wg0
instead of using passive.
If that does not work i would like to know why.
Re: wg(4) ipv6 ospf6d
On 25 August 2021 22:02:02 CEST, Stefan Sperling wrote:
>On Wed, Aug 25, 2021 at 08:13:26PM +0200, Florian Obser wrote:
>> On 2021-08-25 18:02 +01, Stuart Henderson wrote:
>> > Trying to announce a network on a wg(4) interface via ospf6d, just
>> > using passive to pick up the prefix, i.e.
>> >
>> > interface wg0 { passive }
>> >
>> > It's failing with "/etc/ospf6d.conf:10: unnumbered interface wg0".
>> >
>> > With -v I get 'interface with index 27 not found' (this is "normal"
>> > with ospf6d) and the routable address does show up e.g. "if_newaddr:
>> > ifindex 27, addr 2a03::xx:xx::/64" before giving the
>> > unnumbered interface error. There is normally no link-local address
>> > for wg.
>> >
>> > If I manually configure a link-local the interface is successfully
>> > added.
>> >
>> > Anyone have an idea what the behaviour should be here? For passive
>> > would it make sense to accept an interface without link-local?
>> >
>>
>> RFC 4291 2.1:
>>All interfaces are required to have at least one Link-Local unicast
>>address.
>
>If you're not using the interface to send or receive OSPF messages this
>should not matter. I doubt the RFC authors considered the possibility
>of an IPv6-capable interface that doesn't support link-local.
>
I'm always amazed when anything works at all with wireguard and IPv6.
Not my fleas, not my circus *shrug*
--
Sent from a mobile device. Please excuse poor formatting.
Re: wg(4) ipv6 ospf6d
On Wed, Aug 25, 2021 at 08:13:26PM +0200, Florian Obser wrote:
> On 2021-08-25 18:02 +01, Stuart Henderson wrote:
> > Trying to announce a network on a wg(4) interface via ospf6d, just
> > using passive to pick up the prefix, i.e.
> >
> > interface wg0 { passive }
> >
> > It's failing with "/etc/ospf6d.conf:10: unnumbered interface wg0".
> >
> > With -v I get 'interface with index 27 not found' (this is "normal"
> > with ospf6d) and the routable address does show up e.g. "if_newaddr:
> > ifindex 27, addr 2a03::xx:xx::/64" before giving the
> > unnumbered interface error. There is normally no link-local address
> > for wg.
> >
> > If I manually configure a link-local the interface is successfully
> > added.
> >
> > Anyone have an idea what the behaviour should be here? For passive
> > would it make sense to accept an interface without link-local?
> >
>
> RFC 4291 2.1:
>All interfaces are required to have at least one Link-Local unicast
>address.
If you're not using the interface to send or receive OSPF messages this
should not matter. I doubt the RFC authors considered the possibility
of an IPv6-capable interface that doesn't support link-local.
Re: allow KARL with config(8)'d kernels
Robert, Sebastien and Stuart,
Thanks for your constructive and postive feedback. Combined with some
off-list (positive) feedback, it suggests this is at least worth
further consideration.
On Tue, Aug 24, 2021 at 08:05:37PM +0200, Robert Nagy wrote:
| I am happy to see this. All for it. Did you check all the error cases
| to make sure that reorder_kernel will report what needs to be reported?
Well, the thing I checked was that reorder_kernel sets errexit. So if
an error does occur during the config(8) run that gets added with the
diff, it will get reported as usual.
- no /etc/kernel.conf -> works as expected
- proper /etc/kernel.conf -> works as expected
- full partition -> config still is able to change the kernel
- faulty /etc/kernel.conf -> no new kernel, logged to console
On Wed, Aug 25, 2021 at 10:35:19AM +0200, Sebastien Marie wrote:
| - does it integrate well with syspatch ?
|
| yes, syspatch will call /usr/libexec/reorder_kernel (and the
| configuration will be applied)
Yes, I did consider this case and figured it would be fine as syspatch
just runs reorder_kernel (and even checks its exit status).
| - after install or upgrade, does the installed kernel (by installer)
| has the configuration applied ?
|
| it seems not: install.sub has it owns logic and is directly calling
| "make newbsd ; make install" and do not use reorder_kernel script.
Looking just now, install.sub runs in a chroot of the freshly
installed / upgraded system, and issues make newbsd and make
newinstall. Fixing that would be as straightforward as the original
diff. Since there seems to be general interest in my original diff,
I've included such a diff below (not sure if this should be a separate
commit or not).
| I could see reason to avoid it, and reason to requiring it.
|
|
| For install, no problem: the file is controlled (it doesn't
| exist). It doesn't change anything.
Personally, I don't see a reason to avoid it. For install, it could
exist. site.tgz could install an /etc/kernel.conf, for those users
that need to configure their kernels to have them work after the
initial install (this will help automated installs where the operator
already knows in advance that their kernel will need some further
configuration).
| For upgrade, the file could exists. Should the installer using it or
| not ?
|
|
| If using it, it makes the upgrade process dependent of the file: how
| to deal with an invalid file ? should the file ignored (kernel
| installed but not configured) ?
If you have a broken /etc/kernel.conf, it'll never work. A bit like
screwing up your /etc/boot.conf - you get to keep all pieces of your
broken system.
| how to deal with a format change in config(8) (file on disk in old
| format, used config(8) understanding new format) ? but config(8)
| doesn't change often, and could take care of both formats for one
| release, and/or current.html could mention some required changes.
This is a good point, something I didn't consider. But I agree with
your arguments here - seems like something that a) wouldn't happen
frequently and b) can be dealt with when it does.
On Wed, Aug 25, 2021 at 11:32:36AM +0100, Stuart Henderson wrote:
| Somebody had an earlier method for applying kernel config changes
| automatically that IIRC used a bootloader based mechanism passing the
| config to the kernel. I think that might actually be better overall
| as you could bypass it at the boot loader (rather than requiring a
| backup "clean" kernel) though that's more work and I expect difficult
| to do within space constraints on some archs.
I readily agree that that sounds like a better approach to me.
However, that approach is beyond my current skillset, I had an itch to
scratch, and this was my (relatively unintrusive) solution.
The diff below for install.sub has not been tested (yet).
Thanks again,
Paul
Index: install.sub
===
RCS file: /home/OpenBSD/cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1172
diff -u -p -r1.1172 install.sub
--- install.sub 9 Aug 2021 13:56:17 - 1.1172
+++ install.sub 25 Aug 2021 19:42:49 -
@@ -2857,7 +2857,10 @@ finish_up() {
tar -C $_kernel_dir -xzf $_kernel_dir.tgz $_kernel
rm -f $_kernel_dir.tgz
chroot /mnt /bin/ksh -e -c "cd ${_kernel_dir#/mnt}/$_kernel; \
- make newbsd; make newinstall"
+ make newbsd; \
+ [ -e /etc/kernel.conf ] && \
+ config -e -c /etc/kernel.conf -f bsd; \
+ make newinstall"
) >/dev/null 2>&1 && echo " done." || echo " failed."
fi
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: wg(4) ipv6 ospf6d
On 2021-08-25 18:02 +01, Stuart Henderson wrote:
> Trying to announce a network on a wg(4) interface via ospf6d, just
> using passive to pick up the prefix, i.e.
>
> interface wg0 { passive }
>
> It's failing with "/etc/ospf6d.conf:10: unnumbered interface wg0".
>
> With -v I get 'interface with index 27 not found' (this is "normal"
> with ospf6d) and the routable address does show up e.g. "if_newaddr:
> ifindex 27, addr 2a03::xx:xx::/64" before giving the
> unnumbered interface error. There is normally no link-local address
> for wg.
>
> If I manually configure a link-local the interface is successfully
> added.
>
> Anyone have an idea what the behaviour should be here? For passive
> would it make sense to accept an interface without link-local?
>
RFC 4291 2.1:
All interfaces are required to have at least one Link-Local unicast
address.
--
I'm not entirely sure you are real.
[no subject]
Hi,
I sent this to bugs a while back, but it doesn't seem to have been picked up by
anyone.
On both i386 and amd64, the machine boot command in the bootloader has an off
by one bug, which has been present since revision 1.20 in 1998.
The machine boot command is implemented by patching the in-memory copy of the
MBR to set the active partition flag on the selected partition, and reset it on
the other three partitions. The test for part>0 will be false if the first MBR
partition is selected for boot, and in that case no patching of the active
partition flag is performed. The desired behaviour when entering machine boot
hd0a, for example, is that the first partition will be booted regardless of the
state of the flags in the on-disk MBR. However, with the code as it is, the
currently active partition will be booted instead, which may or may not be the
first.
untrusted comment: verify with signify key for exoticsilicon.com
RWRn5d3Yx35u0w51USyxAkjCzjLo99UNE67gXzvuaTGbD9cMlTKdDTOAOe7JA6LV/VLWqmomwo7D9m399vKnra2KyrUn/EYcUgo=
--- arch/amd64/stand/libsa/cmd_i386.c.dist Fri May 10 18:20:43 2019
+++ arch/amd64/stand/libsa/cmd_i386.c Sun Aug 15 23:44:45 2021
@@ -107,7 +107,7 @@
dev += (cmd.argv[1][2] - '0');
part = (cmd.argv[1][3] - 'a');
- if (part > 0)
+ if (part >= 0)
printf("[%x,%d]\n", dev, part);
else
printf("[%x]\n", dev);
@@ -119,7 +119,7 @@
goto bad;
/* Frob boot flag in buffer from HD */
- if ((dev & 0x80) && (part > 0)){
+ if ((dev & 0x80) && (part >= 0)){
int i, j;
for (i = 0, j = DOSPARTOFF; i < 4; i++, j += 16)
--- arch/i386/stand/libsa/cmd_i386.c.dist Fri Jun 10 15:36:06 2016
+++ arch/i386/stand/libsa/cmd_i386.cSun Aug 15 23:44:23 2021
@@ -119,7 +119,7 @@
dev += (cmd.argv[1][2] - '0');
part = (cmd.argv[1][3] - 'a');
- if (part > 0)
+ if (part >= 0)
printf("[%x,%d]\n", dev, part);
else
printf("[%x]\n", dev);
@@ -131,7 +131,7 @@
goto bad;
/* Frob boot flag in buffer from HD */
- if ((dev & 0x80) && (part > 0)){
+ if ((dev & 0x80) && (part >= 0)){
int i, j;
for (i = 0, j = DOSPARTOFF; i < 4; i++, j += 16)
Re: wg(4) ipv6 ospf6d
On Wed, 25 Aug 2021 18:02:11 +0100, Stuart Henderson wrote: > If I manually configure a link-local the interface is successfully > added. > > Anyone have an idea what the behaviour should be here? For passive > would it make sense to accept an interface without link-local? I discussed about that with remi@ a few months ago when I considered using ospf6d, as I had the same cryptic error than you give. I was told: > ospf6d can not work without a link-local address on the interface. > RFC 5340 mandates the use of link-local addresses in section 2.5. And here's a link to the mentioned section: https://datatracker.ietf.org/doc/html/rfc5340#section-2.5 Cheers, Daniel
wg(4) ipv6 ospf6d
Trying to announce a network on a wg(4) interface via ospf6d, just
using passive to pick up the prefix, i.e.
interface wg0 { passive }
It's failing with "/etc/ospf6d.conf:10: unnumbered interface wg0".
With -v I get 'interface with index 27 not found' (this is "normal"
with ospf6d) and the routable address does show up e.g. "if_newaddr:
ifindex 27, addr 2a03::xx:xx::/64" before giving the
unnumbered interface error. There is normally no link-local address
for wg.
If I manually configure a link-local the interface is successfully
added.
Anyone have an idea what the behaviour should be here? For passive
would it make sense to accept an interface without link-local?
[patch] added cwm config property for hiding resize hints
Hello, All;
I've added a property to CWM config to hide the window in the top
left corner of the screen while moving or resizeing a window.
This is my first patch, so feel free to yell at me.
Ben Raskin
diff --git app/cwm/calmwm.h app/cwm/calmwm.h
index a0aeafa8f..3904eeddf 100644
--- app/cwm/calmwm.h
+++ app/cwm/calmwm.h
@@ -293,6 +293,7 @@ struct conf {
int snapdist;
int htile;
int vtile;
+ int wprop;
struct gap gap;
char*color[CWM_COLOR_NITEMS];
char*font;
diff --git app/cwm/conf.c app/cwm/conf.c
index 1e95bd9e1..21d30d184 100644
--- app/cwm/conf.c
+++ app/cwm/conf.c
@@ -283,6 +283,7 @@ conf_init(struct conf *c)
c->mamount = 1;
c->htile = 50;
c->vtile = 50;
+ c->wprop = 1;
c->snapdist = 0;
c->ngroups = 0;
c->nameqlen = 5;
diff --git app/cwm/cwmrc.5 app/cwm/cwmrc.5
index bca861b0b..b511f45fa 100644
--- app/cwm/cwmrc.5
+++ app/cwm/cwmrc.5
@@ -207,6 +207,10 @@ The default behavior for new windows is to not assign any
group.
By enabling sticky group mode,
.Xr cwm 1
will assign new windows to the currently selected group.
+.It Ic wprop Ic yes Ns \&| Ns Ic no
+Toggle showing window size properties in the top left corner of a
+window during moving or resizing.
+The default behaviour is to show window size properties.
.It Ic unbind-key Ar key
Unbind function bound to
.Ar key .
diff --git app/cwm/kbfunc.c app/cwm/kbfunc.c
index 53ec0cffb..c3c27a26f 100644
--- app/cwm/kbfunc.c
+++ app/cwm/kbfunc.c
@@ -167,8 +167,11 @@ kbfunc_client_move_mb(void *ctx, struct cargs *cargs)
CurrentTime) != GrabSuccess)
return;
- screen_prop_win_create(sc, cc->win);
- screen_prop_win_draw(sc, "%+5d%+5d", cc->geom.x, cc->geom.y);
+ if (Conf.wprop) {
+ screen_prop_win_create(sc, cc->win);
+ screen_prop_win_draw(sc, "%+5d%+5d", cc->geom.x,
+ cc->geom.y);
+ }
while (move) {
XMaskEvent(X_Dpy, MOUSEMASK, &ev);
switch (ev.type) {
@@ -191,8 +194,9 @@ kbfunc_client_move_mb(void *ctx, struct cargs *cargs)
cc->geom.y + cc->geom.h + (cc->bwidth * 2),
area.y, area.y + area.h, sc->snapdist);
client_move(cc);
- screen_prop_win_draw(sc,
- "%+5d%+5d", cc->geom.x, cc->geom.y);
+ if (Conf.wprop)
+ screen_prop_win_draw(sc,
+ "%+5d%+5d", cc->geom.x, cc->geom.y);
break;
case ButtonRelease:
move = 0;
@@ -201,7 +205,8 @@ kbfunc_client_move_mb(void *ctx, struct cargs *cargs)
}
if (ltime)
client_move(cc);
- screen_prop_win_destroy(sc);
+ if (Conf.wprop)
+ screen_prop_win_destroy(sc);
XUngrabPointer(X_Dpy, CurrentTime);
}
@@ -256,8 +261,11 @@ kbfunc_client_resize_mb(void *ctx, struct cargs *cargs)
CurrentTime) != GrabSuccess)
return;
- screen_prop_win_create(sc, cc->win);
- screen_prop_win_draw(sc, "%4d x %-4d", cc->dim.w, cc->dim.h);
+ if (Conf.wprop) {
+ screen_prop_win_create(sc, cc->win);
+ screen_prop_win_draw(sc, "%4d x %-4d", cc->dim.w,
+ cc->dim.h);
+ }
while (resize) {
XMaskEvent(X_Dpy, MOUSEMASK, &ev);
switch (ev.type) {
@@ -271,8 +279,10 @@ kbfunc_client_resize_mb(void *ctx, struct cargs *cargs)
cc->geom.h = ev.xmotion.y;
client_apply_sizehints(cc);
client_resize(cc, 1);
- screen_prop_win_draw(sc,
- "%4d x %-4d", cc->dim.w, cc->dim.h);
+ if (Conf.wprop)
+ screen_prop_win_draw(sc,
+ "%4d x %-4d", cc->dim.w,
+ cc->dim.h);
break;
case ButtonRelease:
resize = 0;
@@ -281,7 +291,8 @@ kbfunc_client_resize_mb(void *ctx, struct cargs *cargs)
}
if (ltime)
client_resize(cc, 1);
- screen_prop_win_destroy(sc);
+ if (Conf.wprop)
+ screen_prop_win_destroy(sc);
XUngrabPointer(X_Dpy, CurrentTime);
/* Make sure the pointer stays within the window. */
diff --git app/cwm/parse.y app/cwm/parse.y
index c1bf8c563..0cef1e205 100644
--- app/cwm/parse.y
+++ app/cwm/parse.y
@@ -69,7 +69,7 @@ typedef struct {
%}
%token BINDKEY UNBINDKEY BINDMOUSE UNBINDMOUSE
-%token FONTNAME STICKY GAP
+%token FONTNAME STICKY GAP WPROP
%token AUTO
Re: allow KARL with config(8)'d kernels
On 2021/08/25 10:35, Sebastien Marie wrote: > On Tue, Aug 24, 2021 at 01:53:41PM +0200, Paul de Weerd wrote: > > I have a new machine where I'd like to use IPMI. Of course, doing > > `config -e -f /bsd` will break KARL, so I tried to find a minimal way > > of supporting this. Done by introducing a new config file, > > /etc/kernel.conf, which gets applied to the kernel reorder_kernel > > builds and installs. > > I like it: it is simple. > > but here are some thoughts (with questions and some answers, but it is > open): > > - does it integrate well with syspatch ? > > yes, syspatch will call /usr/libexec/reorder_kernel (and the > configuration will be applied) > > > - after install or upgrade, does the installed kernel (by installer) > has the configuration applied ? > > it seems not: install.sub has it owns logic and is directly calling > "make newbsd ; make install" and do not use reorder_kernel script. > > > I could see reason to avoid it, and reason to requiring it. > > > For install, no problem: the file is controlled (it doesn't > exist). It doesn't change anything. > > For upgrade, the file could exists. Should the installer using it or > not ? > > > If using it, it makes the upgrade process dependent of the file: how > to deal with an invalid file ? should the file ignored (kernel > installed but not configured) ? I don't see a reason why upgrade shouldn't use it. Invalid file handling is no more or less of a problem for upgrades than reboots. > how to deal with a format change in config(8) (file on disk in old > format, used config(8) understanding new format) ? but config(8) > doesn't change often, and could take care of both formats for one > release, and/or current.html could mention some required changes. > > > If not using it, does it is a problem that the first boot will be > different from next boot ? > > I could imagine some changes made to be the machine bootable, so the > first boot could lead to unbootable machine (but it isn't different > from now). > Questions are open: I have no problem which using or not using the > configuration file on upgrade, but I think it should be documented (to > avoid questions and/or surprises). > Somebody had an earlier method for applying kernel config changes automatically that IIRC used a bootloader based mechanism passing the config to the kernel. I think that might actually be better overall as you could bypass it at the boot loader (rather than requiring a backup "clean" kernel) though that's more work and I expect difficult to do within space constraints on some archs. I would be quite happy to have this problem solved one way or another, while a "one size fits all" kernel should be the goal, there are some workarounds needed e.g. for semi-broken hardware and I think that's always likely to be the case.
hkdf.c: Remove unecessary include
Hi Looks like hkdf.c does not need assert.h so remove it. Best, Martin Index: hkdf/hkdf.c === RCS file: /cvs/src/lib/libcrypto/hkdf/hkdf.c,v retrieving revision 1.4 diff -u -p -r1.4 hkdf.c --- hkdf/hkdf.c 21 Nov 2019 20:02:20 - 1.4 +++ hkdf/hkdf.c 25 Aug 2021 09:52:21 - @@ -16,7 +16,6 @@ #include -#include #include #include
Re: allow KARL with config(8)'d kernels
On Tue, Aug 24, 2021 at 01:53:41PM +0200, Paul de Weerd wrote:
> I have a new machine where I'd like to use IPMI. Of course, doing
> `config -e -f /bsd` will break KARL, so I tried to find a minimal way
> of supporting this. Done by introducing a new config file,
> /etc/kernel.conf, which gets applied to the kernel reorder_kernel
> builds and installs.
I like it: it is simple.
but here are some thoughts (with questions and some answers, but it is
open):
- does it integrate well with syspatch ?
yes, syspatch will call /usr/libexec/reorder_kernel (and the
configuration will be applied)
- after install or upgrade, does the installed kernel (by installer)
has the configuration applied ?
it seems not: install.sub has it owns logic and is directly calling
"make newbsd ; make install" and do not use reorder_kernel script.
I could see reason to avoid it, and reason to requiring it.
For install, no problem: the file is controlled (it doesn't
exist). It doesn't change anything.
For upgrade, the file could exists. Should the installer using it or
not ?
If using it, it makes the upgrade process dependent of the file: how
to deal with an invalid file ? should the file ignored (kernel
installed but not configured) ?
how to deal with a format change in config(8) (file on disk in old
format, used config(8) understanding new format) ? but config(8)
doesn't change often, and could take care of both formats for one
release, and/or current.html could mention some required changes.
If not using it, does it is a problem that the first boot will be
different from next boot ?
I could imagine some changes made to be the machine bootable, so the
first boot could lead to unbootable machine (but it isn't different
from now).
Questions are open: I have no problem which using or not using the
configuration file on upgrade, but I think it should be documented (to
avoid questions and/or surprises).
Thanks
--
Sebastien Marie
> Index: reorder_kernel.sh
> ===
> RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/reorder_kernel.sh,v
> retrieving revision 1.9
> diff -u -p -r1.9 reorder_kernel.sh
> --- reorder_kernel.sh 28 Sep 2019 17:30:07 - 1.9
> +++ reorder_kernel.sh 24 Aug 2021 07:01:10 -
> @@ -63,6 +63,7 @@ fi
>
> cd $KERNEL_DIR/$KERNEL
> make newbsd
> +[ -f /etc/kernel.conf ] && config -e -c /etc/kernel.conf -f bsd
> make newinstall
> sync
>
> Index: Makefile
> ===
> RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/Makefile,v
> retrieving revision 1.1
> diff -u -p -r1.1 Makefile
> --- Makefile 21 Aug 2017 21:24:11 - 1.1
> +++ Makefile 24 Aug 2021 07:23:38 -
> @@ -1,6 +1,7 @@
> #$OpenBSD: Makefile,v 1.1 2017/08/21 21:24:11 rpe Exp $
>
> SCRIPT= reorder_kernel.sh
> +MAN= kernel.conf.5
>
> realinstall:
> ${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
> Index: kernel.conf.5
> ===
> RCS file: kernel.conf.5
> diff -N kernel.conf.5
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ kernel.conf.5 24 Aug 2021 07:23:07 -
> @@ -0,0 +1,46 @@
> +.\" $OpenBSD$
> +.\"
> +.\" Copyright (c) 2021 Paul de Weerd
> +.\"
> +.\" Permission to use, copy, modify, and distribute this software for any
> +.\" purpose with or without fee is hereby granted, provided that the above
> +.\" copyright notice and this permission notice appear in all copies.
> +.\"
> +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> +.\"
> +.Dd $Mdocdate: August 24 2021 $
> +.Dt KERNEL.CONF 5
> +.Os
> +.Sh NAME
> +.Nm kernel.conf
> +.Nd kernel configuration file
> +.Sh DESCRIPTION
> +The
> +.Nm
> +file contains configuration information for the kernel.
> +If present, it is used during system startup to configure the kernel
> +that will be running at the next boot.
> +It can be used to enable or disable specific devices in the kernel.
> +.Sh EXAMPLES
> +To enable the
> +.Xr ipmi 4
> +driver, add the following line to
> +.Nm :
> +.Pp
> +.Dl enable ipmi
> +.Pp
> +See
> +.Xr config 8
> +for more details on how to configure the kernel.
> +.Sh FILES
> +.Bl -tag -width /etc/kernel.conf -compact
> +.It Pa /etc/kernel.conf
> +Kernel configuration file.
> +.Sh SEE ALSO
> +.Xr config 8
>
> --
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]
