wsmouse(4): allow independent touchpad tap gesture configuration
Right now, there is a single master toggle for enabling all touchpad tap
gestures (mouse.tp.tapping). This patch splits this parameter into three
for independent control of one-finger, two-finger, and three-finger tap
gestures. This allows users to mix and match which gestures they prefer
for the ideal touchpad experience.
Index: sbin/wsconsctl/mousecfg.c
===
RCS file: /cvs/src/sbin/wsconsctl/mousecfg.c,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 mousecfg.c
--- sbin/wsconsctl/mousecfg.c 2 Apr 2020 17:17:04 - 1.7
+++ sbin/wsconsctl/mousecfg.c 9 Feb 2021 00:17:14 -
@@ -40,7 +40,7 @@
#define TP_FILTER_FIRSTWSMOUSECFG_DX_MAX
#define TP_FILTER_LAST WSMOUSECFG_SMOOTHING
#define TP_FEATURES_FIRST WSMOUSECFG_SOFTBUTTONS
-#define TP_FEATURES_LAST WSMOUSECFG_TAPPING
+#define TP_FEATURES_LAST WSMOUSECFG_THREEFINGERTAPPING
#define TP_SETUP_FIRST WSMOUSECFG_LEFT_EDGE
#define TP_SETUP_LAST WSMOUSECFG_TAP_LOCKTIME
#define LOG_FIRST WSMOUSECFG_LOG_INPUT
@@ -71,8 +71,10 @@ static const int touchpad_types[] = {
struct wsmouse_parameters cfg_tapping = {
(struct wsmouse_param[]) {
- { WSMOUSECFG_TAPPING, 0 }, },
- 1
+ { WSMOUSECFG_ONEFINGERTAPPING, 0 },
+ { WSMOUSECFG_TWOFINGERTAPPING, 0 },
+ { WSMOUSECFG_THREEFINGERTAPPING, 0 }, },
+ 3
};
struct wsmouse_parameters cfg_scaling = {
Index: share/man/man4/wsmouse.4
===
RCS file: /cvs/src/share/man/man4/wsmouse.4,v
retrieving revision 1.20
diff -u -p -u -p -r1.20 wsmouse.4
--- share/man/man4/wsmouse.44 Feb 2018 20:29:59 - 1.20
+++ share/man/man4/wsmouse.49 Feb 2021 00:17:14 -
@@ -26,7 +26,7 @@
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
-.Dd $Mdocdate: February 4 2018 $
+.Dd $Mdocdate: February 8 2021 $
.Dt WSMOUSE 4
.Os
.Sh NAME
@@ -87,14 +87,22 @@ is omitted, commands apply to
.Pa /dev/wsmouse0 .
.Bl -tag -width Ds
.It Cm mouse.tp.tapping
-Setting this parameter to a non-zero value enables tap gestures.
+This list of three parameters sets the enabled tap gestures, in the order:
+.Bd -literal -offset indent
+.Sm off
+.Ar one-finger , two-finger , three-finger
+.Sm on
+.Ed
+.Pp
+Setting a parameter to a non-zero value enables that tap gesture.
Contacts on the touchpad that are immediately released again
-trigger click events.
+trigger click events only if the corresponding tap gesture is enabled.
One-finger, two-finger, and three-finger taps generate left-button,
right-button, and middle-button clicks, respectively.
If, within a short time interval, a second touch follows a one-finger
tap, the button-up event is not issued until that touch ends
.Pq Dq tap-and-drag .
+This requires the one-finger tap gesture to be enabled.
.It Cm mouse.tp.scaling
The value is a scale coefficient that is applied to the relative
coordinates.
Index: sys/dev/wscons/wsconsio.h
===
RCS file: /cvs/src/sys/dev/wscons/wsconsio.h,v
retrieving revision 1.95
diff -u -p -u -p -r1.95 wsconsio.h
--- sys/dev/wscons/wsconsio.h 1 Oct 2020 17:28:14 - 1.95
+++ sys/dev/wscons/wsconsio.h 9 Feb 2021 00:17:17 -
@@ -319,7 +319,9 @@ enum wsmousecfg {
WSMOUSECFG_SWAPSIDES, /* invert soft-button/scroll areas */
WSMOUSECFG_DISABLE, /* disable all output except for
clicks in the top-button area */
- WSMOUSECFG_TAPPING, /* enable tapping */
+ WSMOUSECFG_ONEFINGERTAPPING,/* enable one-finger tapping */
+ WSMOUSECFG_TWOFINGERTAPPING,/* enable two-finger tapping */
+ WSMOUSECFG_THREEFINGERTAPPING, /* enable three-finger tapping */
/*
* Touchpad options
@@ -345,7 +347,7 @@ enum wsmousecfg {
WSMOUSECFG_LOG_INPUT = 256,
WSMOUSECFG_LOG_EVENTS,
};
-#define WSMOUSECFG_MAX 39 /* max size of param array per ioctl */
+#define WSMOUSECFG_MAX 41 /* max size of param array per ioctl */
struct wsmouse_param {
enum wsmousecfg key;
Index: sys/dev/wscons/wstpad.c
===
RCS file: /cvs/src/sys/dev/wscons/wstpad.c,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 wstpad.c
--- sys/dev/wscons/wstpad.c 13 Sep 2020 10:05:46 - 1.26
+++ sys/dev/wscons/wstpad.c 9 Feb 2021 00:17:17 -
@@ -139,18 +139,19 @@ struct tpad_touch {
/*
* wstpad.features
*/
-#define WSTPAD_SOFTBUTTONS (1 << 0)
-#define WSTPAD_SOFTMBTN(1 << 1)
-#define WSTPAD_TOPBUTTONS (1 << 2)
-#define WSTPAD_TWOFINGERSCROLL (1 << 3)
-#define WSTPAD_EDGESCROLL (1 << 4)
-#define WSTPAD_HORIZSCROLL (1 << 5)
-#define WSTPAD_SWAPSIDES (1 <
Re: /bin/cp: overwrite symlink with file pointed to by symlink
Hi Quentin,
Thank you for having a look.
I know I'm very late, but I still like your patch. So ok chrisz@ if you
want to commit it.
Christopher
On Fri, Nov 01, 2019 at 08:46:51PM +0100, Quentin Rameau wrote:
If you're interested in adapting to POSIX, here's a proposition patch:
Index: bin/cp//cp.1
===
RCS file: /var/cvs/src/bin/cp/cp.1,v
retrieving revision 1.40
diff -u -r1.40 cp.1
--- bin/cp//cp.128 Jan 2019 18:58:42 - 1.40
+++ bin/cp//cp.11 Nov 2019 19:41:26 -
@@ -79,9 +79,8 @@
Same as
.Fl RpP .
.It Fl f
-For each existing destination pathname, remove it and
-create a new file, without prompting for confirmation,
-regardless of its permissions.
+For each existing destination pathname which cannot be opened, remove
+it and create a new file, without prompting for confirmation.
The
.Fl f
option overrides any previous
Index: bin/cp//utils.c
===
RCS file: /var/cvs/src/bin/cp/utils.c,v
retrieving revision 1.47
diff -u -r1.47 utils.c
--- bin/cp//utils.c 28 Jan 2019 18:58:42 - 1.47
+++ bin/cp//utils.c 1 Nov 2019 19:25:02 -
@@ -55,7 +55,7 @@
static char *buf;
static char *zeroes;
struct stat to_stat, *fs;
- int from_fd, rcount, rval, to_fd, wcount;
+ int from_fd, rcount, rval, to_fd, wcount, create = 1;
#ifdef VM_AND_BUFFER_CACHE_SYNCHRONIZED
char *p;
#endif
@@ -79,26 +79,24 @@
fs = entp->fts_statp;
/*
-* In -f (force) mode, we always unlink the destination first
-* if it exists. Note that -i and -f are mutually exclusive.
-*/
- if (exists && fflag)
- (void)unlink(to.p_path);
-
- /*
* If the file DNE, set the mode to be the from file, minus setuid
* bits, modified by the umask; arguably wrong, but it makes copying
* executables work right and it's been that way forever. (The
* other choice is 666 or'ed with the execute bits on the from file
* modified by the umask.)
*/
- if (exists && !fflag) {
- if (!copy_overwrite()) {
+ if (exists) {
+ /* Note that -i and -f are mutually exclusive. */
+ if (!fflag && !copy_overwrite()) {
(void)close(from_fd);
return 2;
}
to_fd = open(to.p_path, O_WRONLY | O_TRUNC, 0);
- } else
+ if (to_fd != -1 || fflag && unlink(to.p_path) == -1)
+ create = 0;
+ }
+
+ if (create)
to_fd = open(to.p_path, O_WRONLY | O_TRUNC | O_CREAT,
fs->st_mode & ~(S_ISTXT | S_ISUID | S_ISGID));
--
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1
Re: random manual pages
On Thu, Feb 11, 2021 at 10:40:07PM -0700, Theo de Raadt wrote: >[...] > +original development, is underspecified, and should not be relied up to "relied up to" should probably be "relied upon to" (twice). Ross
random manual pages
Reading a recent junk-thread, I realized the algorithms for rand and random have changed numerous times since the late 80's. As such you cannot trust that a seed given 20 years ago, produces the same sequence today. I did a rough study of the commits to our versions. Other operating systems changed their algorithms at different times. I think rand and random algorithm changed about 5 times (combined). But wait there is MORE! These functions mix "long" and "int", and rely upon wraparound, so 32-bit vs 64-bit behaviour occur. I'm wondering if the following wording will disuade people from playing this stupid deterministic game, or arguing that these specific functions serve such a purpose. I suppose the two lessons are: - if you need determinism, write your own. - do not rely upon an external function which will make your seed produce a different result approximately every 8 years. People keep talking about the value of determinism, and in particular for these specific function names, so I'm hoping to put the argument to rest. I stopped short by avoiding the phrase "undefined behaviour". Index: stdlib/rand.3 === RCS file: /cvs/src/lib/libc/stdlib/rand.3,v retrieving revision 1.19 diff -u -p -u -r1.19 rand.3 --- stdlib/rand.3 9 Dec 2014 21:55:39 - 1.19 +++ stdlib/rand.3 12 Feb 2021 05:36:52 - @@ -78,6 +78,9 @@ can be substituted for then subsequent .Fn rand calls will return results using the deterministic algorithm. +The deterministic sequence algorithm changed a number of times since +original development, is underspecified, and should not be relied up to +remain consistant between platforms and over time. .Pp The .Fn rand Index: stdlib/random.3 === RCS file: /cvs/src/lib/libc/stdlib/random.3,v retrieving revision 1.28 diff -u -p -u -r1.28 random.3 --- stdlib/random.3 9 Dec 2014 21:55:39 - 1.28 +++ stdlib/random.3 12 Feb 2021 05:36:52 - @@ -96,6 +96,9 @@ a default table of size 31 long integers numbers in the range from 0 to (2**31)\-1. The period of this random number generator is very large, approximately 16*((2**31)\-1), but the results are a deterministic sequence from the seed. +The deterministic sequence algorithm changed a number of times since +original development, is underspecified, and should not be relied up to +remain consistant between platforms and over time. .Pp The .Fn initstate
Re: route sockets: simplify route_attach() error path
On Wed, Feb 10, 2021 at 10:51:52PM +0300, Vitaliy Makkoveev wrote:
> Do soreserve() before `rop' allocation. It doesn't require protocol
> control block be attached to socket. Also we always call `pr_attach' in
> thread context so we always have `curproc'.
While I found one pr_attach() from TCP input context, route_attach()
is only called from process context.
> ok?
OK bluhm@
> Index: sys/net/rtsock.c
> ===
> RCS file: /cvs/src/sys/net/rtsock.c,v
> retrieving revision 1.304
> diff -u -p -r1.304 rtsock.c
> --- sys/net/rtsock.c 7 Nov 2020 09:51:40 - 1.304
> +++ sys/net/rtsock.c 10 Feb 2021 19:43:52 -
> @@ -301,6 +301,9 @@ route_attach(struct socket *so, int prot
> struct rtpcb*rop;
> int error;
>
> + error = soreserve(so, ROUTESNDQ, ROUTERCVQ);
> + if (error)
> + return (error);
> /*
>* use the rawcb but allocate a rtpcb, this
>* code does not care about the additional fields
> @@ -311,15 +314,6 @@ route_attach(struct socket *so, int prot
> /* Init the timeout structure */
> timeout_set(&rop->rop_timeout, rtm_senddesync_timer, so);
> refcnt_init(&rop->rop_refcnt);
> -
> - if (curproc == NULL)
> - error = EACCES;
> - else
> - error = soreserve(so, ROUTESNDQ, ROUTERCVQ);
> - if (error) {
> - pool_put(&rtpcb_pool, rop);
> - return (error);
> - }
>
> rop->rop_socket = so;
> rop->rop_proto = proto;
Re: ssl(8) tweaks, mostly for ecdsa
On 2021/02/11 22:22, Theo Buehler wrote: > On Thu, Feb 11, 2021 at 08:55:55PM +, Stuart Henderson wrote: > > acme-client works with ecdsa certificates, but if there's no existing > > key, it has no way to tell whether you want ec or rsa so it can't > > actually generate a new ec key. (even if it did, acme-client's default > > secp384r1 isn't accepted by buypass). > > > > here are a few changes for ssl(8) that i think are helpful. > > it uses the single command that generates params and a key together, > > which is the only step needed if you're using it with acme-client, > > and then generates a csr separately (as is already done for rsa). > > > > i've included some small changes for rsa as well (not everyone wants > > such a long key as acme-client uses by default, especially if they > > are handling high connection rates). > > > > any comments? > > This makes sense to me. I like the streamlining of the ECDSA case except > for one detail: the eccert.key is no longer saved into /etc/ssl/private > (probably to avoid line wraps). It is assumed to be there in the last > command before SEE ALSO. The intent may be obvious to a user who has > read the RSA section but it may lead to errors for those who didn't. > > I don't remember the rules for SEE ALSO. Should acme-client have an Xr > there? Both good points. I think SEE ALSOs in both directions probably make sense. (There is a remaining point that acme-client suggests it can generate an ec key itself, and has some code for this, but I don't see how it can work - I am ignoring that for now ;) Index: usr.sbin/acme-client/acme-client.1 === RCS file: /cvs/src/usr.sbin/acme-client/acme-client.1,v retrieving revision 1.39 diff -u -p -r1.39 acme-client.1 --- usr.sbin/acme-client/acme-client.1 2 Jan 2021 19:04:21 - 1.39 +++ usr.sbin/acme-client/acme-client.1 11 Feb 2021 21:36:04 - @@ -130,7 +130,8 @@ is reloaded: .Sh SEE ALSO .Xr openssl 1 , .Xr acme-client.conf 5 , -.Xr httpd.conf 5 +.Xr httpd.conf 5 , +.Xr ssl 8 .Sh STANDARDS .Rs .%A R. Barnes Index: share/man/man8/ssl.8 === RCS file: /cvs/src/share/man/man8/ssl.8,v retrieving revision 1.68 diff -u -p -r1.68 ssl.8 --- share/man/man8/ssl.810 May 2019 12:41:49 - 1.68 +++ share/man/man8/ssl.811 Feb 2021 21:36:04 - @@ -64,6 +64,7 @@ key file is kept secure. To support HTTPS transactions in .Xr httpd 8 you will need to generate an RSA certificate. +Start by creating a private key of the desired length: .Bd -literal -offset indent # openssl genrsa -out /etc/ssl/private/server.key 4096 .Ed @@ -74,8 +75,13 @@ have to type in when starting servers # openssl genrsa -aes256 -out /etc/ssl/private/server.key 4096 .Ed .Pp -The next step is to generate a Certificate Signing Request (CSR) which is -used to get a Certificate Authority (CA) to sign your certificate. +If you are only generating a private key to use with +.Xr acme-client 1 +(for example, with a non-default key length) +you may stop here. +.Pp +Otherwise, the next step is to generate a Certificate Signing Request (CSR) +which is used to get a Certificate Authority (CA) to sign your certificate. To do this use the command: .Bd -literal -offset indent # openssl req -new -key /etc/ssl/private/server.key \e @@ -123,25 +129,25 @@ with the certificate signed by your Cert restarting .Xr httpd 8 . .Sh GENERATING ECDSA SERVER CERTIFICATES -First, generate parameters for ECDSA keys. +First, generate a private ECDSA key. The following command will use a NIST/SECG curve over a 384-bit prime field: .Bd -literal -offset indent -# openssl ecparam -out ec-secp384r1.pem -name secp384r1 +# openssl ecparam -name secp384r1 -genkey \e + -noout -out /etc/ssl/private/eccert.key .Ed .Pp -Once you have the ECDSA parameters generated, you can generate a -CSR and unencrypted private key using the command: -.Bd -literal -offset indent -# openssl req -nodes -newkey ec:ec-secp384r1.pem \e - -keyout /etc/ssl/private/eccert.key -new \e - -out /etc/ssl/private/eccert.csr -.Ed +Note that some Certificate Authorities will only issue certificates for +keys generated using prime256v1 parameters. .Pp -To generate an encrypted private key, you would use: +If you are only generating a private key to use with +.Xr acme-client 1 , +you may stop here. +Otherwise, the next step is to generate a Certificate Signing Request (CSR) +which is used to get a Certificate Authority (CA) to sign your certificate. +To do this use the command: .Bd -literal -offset indent -# openssl req -newkey ec:ec-secp384r1.pem \e - -keyout /etc/ssl/private/eccert.key -new \e +# openssl req -key /etc/ssl/private/eccert.key -new \e -out /etc/ssl/private/eccert.csr .Ed .Pp @@ -157,6 +163,7 @@ You can also sign the key yourself, usin -out /etc/ssl/eccert.crt .Ed .Sh SEE ALSO +.Xr acme-client 1 , .Xr openssl 1 , .Xr s
Re: ssl(8) tweaks, mostly for ecdsa
On Thu, Feb 11, 2021 at 08:55:55PM +, Stuart Henderson wrote: > acme-client works with ecdsa certificates, but if there's no existing > key, it has no way to tell whether you want ec or rsa so it can't > actually generate a new ec key. (even if it did, acme-client's default > secp384r1 isn't accepted by buypass). > > here are a few changes for ssl(8) that i think are helpful. > it uses the single command that generates params and a key together, > which is the only step needed if you're using it with acme-client, > and then generates a csr separately (as is already done for rsa). > > i've included some small changes for rsa as well (not everyone wants > such a long key as acme-client uses by default, especially if they > are handling high connection rates). > > any comments? This makes sense to me. I like the streamlining of the ECDSA case except for one detail: the eccert.key is no longer saved into /etc/ssl/private (probably to avoid line wraps). It is assumed to be there in the last command before SEE ALSO. The intent may be obvious to a user who has read the RSA section but it may lead to errors for those who didn't. I don't remember the rules for SEE ALSO. Should acme-client have an Xr there?
ssl(8) tweaks, mostly for ecdsa
acme-client works with ecdsa certificates, but if there's no existing key, it has no way to tell whether you want ec or rsa so it can't actually generate a new ec key. (even if it did, acme-client's default secp384r1 isn't accepted by buypass). here are a few changes for ssl(8) that i think are helpful. it uses the single command that generates params and a key together, which is the only step needed if you're using it with acme-client, and then generates a csr separately (as is already done for rsa). i've included some small changes for rsa as well (not everyone wants such a long key as acme-client uses by default, especially if they are handling high connection rates). any comments? ok? Index: ssl.8 === RCS file: /cvs/src/share/man/man8/ssl.8,v retrieving revision 1.68 diff -u -p -r1.68 ssl.8 --- ssl.8 10 May 2019 12:41:49 - 1.68 +++ ssl.8 11 Feb 2021 20:48:27 - @@ -64,6 +64,7 @@ key file is kept secure. To support HTTPS transactions in .Xr httpd 8 you will need to generate an RSA certificate. +Start by creating a private key of the desired length: .Bd -literal -offset indent # openssl genrsa -out /etc/ssl/private/server.key 4096 .Ed @@ -74,8 +75,13 @@ have to type in when starting servers # openssl genrsa -aes256 -out /etc/ssl/private/server.key 4096 .Ed .Pp -The next step is to generate a Certificate Signing Request (CSR) which is -used to get a Certificate Authority (CA) to sign your certificate. +If you are only generating a private key to use with +.Xr acme-client 1 +(for example, with a non-default key length) +you may stop here. +.Pp +Otherwise, the next step is to generate a Certificate Signing Request (CSR) +which is used to get a Certificate Authority (CA) to sign your certificate. To do this use the command: .Bd -literal -offset indent # openssl req -new -key /etc/ssl/private/server.key \e @@ -123,26 +129,24 @@ with the certificate signed by your Cert restarting .Xr httpd 8 . .Sh GENERATING ECDSA SERVER CERTIFICATES -First, generate parameters for ECDSA keys. +First, generate a private ECDSA key. The following command will use a NIST/SECG curve over a 384-bit prime field: .Bd -literal -offset indent -# openssl ecparam -out ec-secp384r1.pem -name secp384r1 +# openssl ecparam -name secp384r1 -genkey -noout -out eccert.key .Ed .Pp -Once you have the ECDSA parameters generated, you can generate a -CSR and unencrypted private key using the command: -.Bd -literal -offset indent -# openssl req -nodes -newkey ec:ec-secp384r1.pem \e - -keyout /etc/ssl/private/eccert.key -new \e - -out /etc/ssl/private/eccert.csr -.Ed +Note that some Certificate Authorities will only issue certificates for +keys generated using prime256v1 parameters. .Pp -To generate an encrypted private key, you would use: +If you are only generating a private key to use with +.Xr acme-client 1 , +you may stop here. +Otherwise, the next step is to generate a Certificate Signing Request (CSR) +which is used to get a Certificate Authority (CA) to sign your certificate. +To do this use the command: .Bd -literal -offset indent -# openssl req -newkey ec:ec-secp384r1.pem \e - -keyout /etc/ssl/private/eccert.key -new \e - -out /etc/ssl/private/eccert.csr +# openssl req -key eccert.key -new -out /etc/ssl/private/eccert.csr .Ed .Pp This
Re: Add missing break statement on if_rge.c
On Thu, Feb 11, 2021 at 12:24:37PM +, Ricardo Mestre wrote: > > Hi, > > Add missing break statement. OK? ok kevlo@. stsp@ has informed me earlier and has the same diff, I think he will be committing it later today. > CID 1501710 > > Index: if_rge.c > === > RCS file: /cvs/src/sys/dev/pci/if_rge.c,v > retrieving revision 1.11 > diff -u -p -c -u -r1.11 if_rge.c > --- if_rge.c 24 Dec 2020 06:34:03 - 1.11 > +++ if_rge.c 11 Feb 2021 12:21:33 - > @@ -311,6 +311,7 @@ rge_activate(struct device *self, int ac > #ifndef SMALL_KERNEL > rge_wol_power(sc); > #endif > + break; > default: > rv = config_activate_children(self, act); > break;
Re: apu2e4
My boot.conf was renamed to boot.conf.off in the PXE server. Idiot. Thanks tb@ for the hint :-) Sorry for the noise. On Thu, Feb 11, 2021 at 04:07:02PM +0100, Marcus Glocker wrote: > Is there anyone out there using an apu2e4? > > I just received an APU2E4 / GX-412TC 4GB > > https://www.pcengines.ch/apu2e4.htm > > I can't boot any recent kernel on it, not through USB nor through > PXEBOOT. I tried amd64/i386, snapshot, 6.8, 6.6, and all cause the apu > to reboot after the entry point message. E.g.: > > net0: 00:0d:b9:5a:13:00 using i210-2 on PCI01:00.0 (open) > [Link:up, TX:0 TXE:0 RX:0 RXE:0] > Configuring (net0 00:0d:b9:5a:13:00).. ok > net0: 192.168.1.26/255.255.255.0 gw 192.168.1.1 > Next server: 192.168.1.1 > Filename: pxeboot > tftp://192.168.1.1/pxeboot... ok > pxeboot : 101284 bytes [PXE-NBP] > probing: pc0 com0 com1 pxe![2.1] mem[624K 62M 3518M 116K 496M a20=on] > disk: > net: mac 00:0d:b9:5a:13:00, ip 192.168.1.26, server 192.168.1.1 > >> OpenBSD/amd64 PXEBOOT 3.53 > boot> > booting tftp:/bsd: 3814093+1586176+3882456+0+704512=0x988360 > entry point at 0x81001000 > > > > Funnily on the mSATA disk which I had spare, an old 5.3-i386 was still > installed which boots fine.
apu2e4
Is there anyone out there using an apu2e4? I just received an APU2E4 / GX-412TC 4GB https://www.pcengines.ch/apu2e4.htm I can't boot any recent kernel on it, not through USB nor through PXEBOOT. I tried amd64/i386, snapshot, 6.8, 6.6, and all cause the apu to reboot after the entry point message. E.g.: net0: 00:0d:b9:5a:13:00 using i210-2 on PCI01:00.0 (open) [Link:up, TX:0 TXE:0 RX:0 RXE:0] Configuring (net0 00:0d:b9:5a:13:00).. ok net0: 192.168.1.26/255.255.255.0 gw 192.168.1.1 Next server: 192.168.1.1 Filename: pxeboot tftp://192.168.1.1/pxeboot... ok pxeboot : 101284 bytes [PXE-NBP] probing: pc0 com0 com1 pxe![2.1] mem[624K 62M 3518M 116K 496M a20=on] disk: net: mac 00:0d:b9:5a:13:00, ip 192.168.1.26, server 192.168.1.1 >> OpenBSD/amd64 PXEBOOT 3.53 boot> booting tftp:/bsd: 3814093+1586176+3882456+0+704512=0x988360 entry point at 0x81001000 Funnily on the mSATA disk which I had spare, an old 5.3-i386 was still installed which boots fine.
Re: Add missing break statement on if_rge.c
Am Thu, Feb 11, 2021 at 12:24:37PM + schrieb Ricardo Mestre: > Hi, > > Add missing break statement. OK? makes sense to me, ok patrick@ > CID 1501710 > > Index: if_rge.c > === > RCS file: /cvs/src/sys/dev/pci/if_rge.c,v > retrieving revision 1.11 > diff -u -p -c -u -r1.11 if_rge.c > --- if_rge.c 24 Dec 2020 06:34:03 - 1.11 > +++ if_rge.c 11 Feb 2021 12:21:33 - > @@ -311,6 +311,7 @@ rge_activate(struct device *self, int ac > #ifndef SMALL_KERNEL > rge_wol_power(sc); > #endif > + break; > default: > rv = config_activate_children(self, act); > break; >
Add missing break statement on if_rge.c
Hi, Add missing break statement. OK? CID 1501710 Index: if_rge.c === RCS file: /cvs/src/sys/dev/pci/if_rge.c,v retrieving revision 1.11 diff -u -p -c -u -r1.11 if_rge.c --- if_rge.c24 Dec 2020 06:34:03 - 1.11 +++ if_rge.c11 Feb 2021 12:21:33 - @@ -311,6 +311,7 @@ rge_activate(struct device *self, int ac #ifndef SMALL_KERNEL rge_wol_power(sc); #endif + break; default: rv = config_activate_children(self, act); break;
Re: Uninitialized var in dev/pv/vmt.c
On Thu, Feb 11, 2021 at 11:41:24AM +, Ricardo Mestre wrote: > Hi, > > Uninitialized var and it's used in a condition != NULL a little bit > afterwards. > CID 1501713 > > OK? yes, ok jmatthew@ > > Index: vmt.c > === > RCS file: /cvs/src/sys/dev/pv/vmt.c,v > retrieving revision 1.22 > diff -u -p -u -r1.22 vmt.c > --- vmt.c 15 Jan 2021 06:14:41 - 1.22 > +++ vmt.c 11 Feb 2021 11:35:41 - > @@ -1289,7 +1289,7 @@ vmt_xdr_nic_info(char *data) > struct ifnet *iface; > struct vm_nicinfo_nic_list nl; > size_t total, nictotal; > - char *listdata; > + char *listdata = NULL; > int nics; > > NET_ASSERT_LOCKED();
Uninitialized var in dev/pv/vmt.c
Hi, Uninitialized var and it's used in a condition != NULL a little bit afterwards. CID 1501713 OK? Index: vmt.c === RCS file: /cvs/src/sys/dev/pv/vmt.c,v retrieving revision 1.22 diff -u -p -u -r1.22 vmt.c --- vmt.c 15 Jan 2021 06:14:41 - 1.22 +++ vmt.c 11 Feb 2021 11:35:41 - @@ -1289,7 +1289,7 @@ vmt_xdr_nic_info(char *data) struct ifnet *iface; struct vm_nicinfo_nic_list nl; size_t total, nictotal; - char *listdata; + char *listdata = NULL; int nics; NET_ASSERT_LOCKED();
Re: isakmpd link dynamically
Am Thu, Feb 11, 2021 at 11:29:58AM +0100 schrieb Alexander Bluhm: > - recommit in /usr/src/usr.sbin -> we loose history I know no one cares about git, but if the move was committed in a "single cvs commit", git would understand it's simply a move of files. So yeah, cvs wouldn't cope, but git would.
Re: Swapped arguments on stoeplitz_ip{4,6}port
forget about it, patrick@ was way faster and it's already commited :)
Re: Swapped arguments on stoeplitz_ip{4,6}port
Already committed as of 7 minutes ago, heh!
Am Thu, Feb 11, 2021 at 10:48:16AM + schrieb Ricardo Mestre:
> Hi,
>
> It seems this got the args swapped as described in CID 1501717.
>
> stoeplitz_ip6port being a macro for stoeplitz_hash_ip6port and the arguments
> placed as shown below. Similarly stoeplitz_ip4port also has the same problem
> most likely due to copypasto.
>
> Comments? OK?
>
> 173 uint16_t
> 174 stoeplitz_hash_ip6port(const struct stoeplitz_cache *scache,
> 175 const struct in6_addr *faddr6, const struct in6_addr *laddr6,
> 176 in_port_t fport, in_port_t lport)
>
> Index: netinet/in_pcb.c
> ===
> RCS file: /cvs/src/sys/netinet/in_pcb.c,v
> retrieving revision 1.253
> diff -u -p -u -r1.253 in_pcb.c
> --- netinet/in_pcb.c 25 Jan 2021 03:40:46 - 1.253
> +++ netinet/in_pcb.c 11 Feb 2021 10:34:50 -
> @@ -522,8 +522,8 @@ in_pcbconnect(struct inpcb *inp, struct
> inp->inp_fport = sin->sin_port;
> in_pcbrehash(inp);
> #if NSTOEPLITZ > 0
> - inp->inp_flowid = stoeplitz_ip4port(inp->inp_laddr.s_addr,
> - inp->inp_faddr.s_addr, inp->inp_lport, inp->inp_fport);
> + inp->inp_flowid = stoeplitz_ip4port(inp->inp_faddr.s_addr,
> + inp->inp_laddr.s_addr, inp->inp_fport, inp->inp_lport);
> #endif
> #ifdef IPSEC
> {
> Index: netinet6/in6_pcb.c
> ===
> RCS file: /cvs/src/sys/netinet6/in6_pcb.c,v
> retrieving revision 1.111
> diff -u -p -u -r1.111 in6_pcb.c
> --- netinet6/in6_pcb.c25 Jan 2021 03:40:47 - 1.111
> +++ netinet6/in6_pcb.c11 Feb 2021 10:34:50 -
> @@ -303,8 +303,8 @@ in6_pcbconnect(struct inpcb *inp, struct
> inp->inp_flowinfo |=
> (htonl(ip6_randomflowlabel()) & IPV6_FLOWLABEL_MASK);
> #if NSTOEPLITZ > 0
> - inp->inp_flowid = stoeplitz_ip6port(&inp->inp_laddr6,
> - &inp->inp_faddr6, inp->inp_lport, inp->inp_fport);
> + inp->inp_flowid = stoeplitz_ip6port(&inp->inp_faddr6,
> + &inp->inp_laddr6, inp->inp_fport, inp->inp_lport);
> #endif
> in_pcbrehash(inp);
> return (0);
>
Swapped arguments on stoeplitz_ip{4,6}port
Hi,
It seems this got the args swapped as described in CID 1501717.
stoeplitz_ip6port being a macro for stoeplitz_hash_ip6port and the arguments
placed as shown below. Similarly stoeplitz_ip4port also has the same problem
most likely due to copypasto.
Comments? OK?
173 uint16_t
174 stoeplitz_hash_ip6port(const struct stoeplitz_cache *scache,
175 const struct in6_addr *faddr6, const struct in6_addr *laddr6,
176 in_port_t fport, in_port_t lport)
Index: netinet/in_pcb.c
===
RCS file: /cvs/src/sys/netinet/in_pcb.c,v
retrieving revision 1.253
diff -u -p -u -r1.253 in_pcb.c
--- netinet/in_pcb.c25 Jan 2021 03:40:46 - 1.253
+++ netinet/in_pcb.c11 Feb 2021 10:34:50 -
@@ -522,8 +522,8 @@ in_pcbconnect(struct inpcb *inp, struct
inp->inp_fport = sin->sin_port;
in_pcbrehash(inp);
#if NSTOEPLITZ > 0
- inp->inp_flowid = stoeplitz_ip4port(inp->inp_laddr.s_addr,
- inp->inp_faddr.s_addr, inp->inp_lport, inp->inp_fport);
+ inp->inp_flowid = stoeplitz_ip4port(inp->inp_faddr.s_addr,
+ inp->inp_laddr.s_addr, inp->inp_fport, inp->inp_lport);
#endif
#ifdef IPSEC
{
Index: netinet6/in6_pcb.c
===
RCS file: /cvs/src/sys/netinet6/in6_pcb.c,v
retrieving revision 1.111
diff -u -p -u -r1.111 in6_pcb.c
--- netinet6/in6_pcb.c 25 Jan 2021 03:40:47 - 1.111
+++ netinet6/in6_pcb.c 11 Feb 2021 10:34:50 -
@@ -303,8 +303,8 @@ in6_pcbconnect(struct inpcb *inp, struct
inp->inp_flowinfo |=
(htonl(ip6_randomflowlabel()) & IPV6_FLOWLABEL_MASK);
#if NSTOEPLITZ > 0
- inp->inp_flowid = stoeplitz_ip6port(&inp->inp_laddr6,
- &inp->inp_faddr6, inp->inp_lport, inp->inp_fport);
+ inp->inp_flowid = stoeplitz_ip6port(&inp->inp_faddr6,
+ &inp->inp_laddr6, inp->inp_fport, inp->inp_lport);
#endif
in_pcbrehash(inp);
return (0);
Re: isakmpd link dynamically
On Wed, Feb 10, 2021 at 04:16:10PM -0700, Theo de Raadt wrote: > When I re-ordered rc in Slovenia many years ago, I got it right. NFS /usr over IPsec cannot work. Without IPsec it is fine. 1. mount -s /usr >/dev/null 2>&1 2. start_daemon syslogd ldattach pflogd nsd unbound ntpd 3. start_daemon iscsid isakmpd iked sasyncd ldapd npppd > So, I think we should move these two daemons. What do you mean with "move"? - install them in /usr/sbin -> inconsistent with usr.sbin source tree - recommit in /usr/src/usr.sbin -> we loose history - move the history to /cvs/src/usr.sbin -> someone said no more cvs surgery I would like to commit my static linking diff as is. Moving looks more complex to me. bluhm
