Re: httpd: fix/consistency cast for ctype function
On Fri, Nov 2, 2018 at 4:14 AM Hiltjo Posthuma wrote: > I noticed many ctype functions (such as isalpha, isdigit, tolower) are > cast to > unsigned char in httpd. This patch changes it also for one remaining check. > Yep. Committed. Thanks! Philip Guenther
Re: pledge xenodm
On Sat, November 3, 2018 7:16 am, Ricardo Mestre wrote: > prodded by deraadt@, here's a rebased diff on xenocara's source root directory, > usually /usr/xenocara. I'm using DisplayManager*autoLogin in xenodm-config and starting xenodm as desired (not at boot) and it logs me in the first time but after ending the X session, when xenodm tries to reset it gets a: xenodm[63122]: pledge "getpw", syscall 33 Turns out, though, this is kind of a bogus use case. I'm trying to exit X. Having it log me right back in again is silly. I like that it kills xenodm. That's actually what I want. :D Tim.
Re: xidle: improve program parsing
On Sun, Nov 04, 2018 at 03:52:06AM +0100, Klemens Nanni wrote:
> - *area = strtol((char *)value.addr, , 10);
> + *area = strtol((char *)value.addr, , 9);
Oops, fat fingered.
New diff without it.
This was of course tested with various progams as well as the default
settings and examples without any issues.
Index: xidle.1
===
RCS file: /cvs/xenocara/app/xidle/xidle.1,v
retrieving revision 1.5
diff -u -p -r1.5 xidle.1
--- xidle.1 6 Sep 2018 07:21:34 - 1.5
+++ xidle.1 4 Nov 2018 01:43:21 -
@@ -23,7 +23,7 @@
.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
.\" OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
-.Dd June 20, 2005
+.Dd $Mdocdate: November 4 2018 $
.Dt XIDLE 1
.Os
.Sh NAME
@@ -36,8 +36,8 @@
.Op Fl delay Ar secs
.Op Fl display Ar display
.Op Fl no | nw | ne | sw | se
-.Op Fl program Ar path
.Op Fl timeout Ar secs
+.Op Ar program Op Ar args
.Ek
.Sh DESCRIPTION
.Nm
@@ -45,6 +45,8 @@ uses the
.Xr XScreenSaver 3
extension to receive inactivity events when a timeout is specified, running
a specific program after the elapsed time.
+The default is
+.Xr xlock 1 .
.Nm
will also run the program if it is sent a
.Dv SIGUSR1
@@ -71,14 +73,6 @@ Set the position to one of none, northwe
respectively.
If no position is specified,
the default is northwest.
-.It Fl program Ar path
-Specify the full pathname of the program to run on any of the
-aforementioned events.
-Arguments to the program may also be specified, separated by whitespace.
-If
-.Fl program
-is not specified, the default is
-.Xr xlock 1 .
.It Fl timeout Ar secs
Set the timeout to the specified number of seconds.
If
@@ -129,8 +123,7 @@ Run
using the flying bats mode if no activity is detected in 300 seconds or the
pointer sits in the southwest corner for more than 5 seconds:
.Bd -literal -offset indent
-$ xidle -delay 5 -sw -program "/usr/X11R6/bin/xlock -mode bat" \e
- -timeout 300
+$ xidle -delay 5 -sw xlock -mode bat -timeout 300
.Ed
.Sh SEE ALSO
.Xr xlock 1 ,
@@ -142,7 +135,3 @@ The
program was written by
.An Federico Schwindt Aq Mt fg...@openbsd.org
as an xautolock replacement.
-.Sh BUGS
-The maximum number of arguments for
-.Fl program ,
-including the executable file, is currently set to 9.
Index: xidle.c
===
RCS file: /cvs/xenocara/app/xidle/xidle.c,v
retrieving revision 1.6
diff -u -p -r1.6 xidle.c
--- xidle.c 6 Sep 2018 07:21:34 - 1.6
+++ xidle.c 4 Nov 2018 03:00:40 -
@@ -75,14 +75,10 @@ struct xinfo {
struct xinfo x;
-static XrmOptionDescRec fopts[] = {
- { "-display", ".display", XrmoptionSepArg,(caddr_t)NULL },
-};
-
static XrmOptionDescRec opts[] = {
{ "-area", ".area",XrmoptionSepArg,(caddr_t)NULL },
{ "-delay", ".delay", XrmoptionSepArg,(caddr_t)NULL },
- { "-program", ".program", XrmoptionSepArg,(caddr_t)NULL },
+ { "-display", ".display", XrmoptionSepArg,(caddr_t)NULL },
{ "-timeout", ".timeout", XrmoptionSepArg,(caddr_t)NULL },
{ "-no",".position",XrmoptionNoArg, (caddr_t)"no" },
@@ -94,13 +90,12 @@ static XrmOptionDescRec opts[] = {
extern char *__progname;
-void action(struct xinfo *, char **);
+void action(struct xinfo *, char *const []);
void close_x(struct xinfo *);
Bool getres(XrmValue *, const XrmDatabase, const char *, const char *);
voidinit_x(struct xinfo *, int, int, int);
void handler(int);
-void parse_opts(int, char **, Display **, int *, int *, int *, int *,
- char **);
+void parse_opts(int, char **[], Display **, int *, int *, int *, int *);
intstr2pos(const char *);
__dead voidusage(void);
@@ -108,9 +103,10 @@ __dead voidusage(void);
__dead void
usage()
{
- fprintf(stderr, "Usage:\n%s %s\n", __progname,
- "[-area pixels] [-delay secs] [-display host:dpy] "
- "[-no | -ne | -nw | -se | -sw]\n [-program path] [-timeout
secs]");
+ fprintf(stderr,
+ "usage:\t%s [-area pixels] [-delay secs] [-display host:dpy]\n"
+ "\t [-no | -ne | -nw | -se | -sw] [-timeout secs] "
+ "[program [args]]\n", __progname);
exit(1);
}
@@ -180,10 +176,8 @@ close_x(struct xinfo *xi)
void
-action(struct xinfo *xi, char **args)
+action(struct xinfo *xi, char *const args[])
{
- int dumb;
-
switch (fork()) {
case -1:
err(1, "fork");
@@ -191,12 +185,12 @@ action(struct xinfo *xi, char **args)
case 0:
setsid();
- execv(*args, args);
+ execvp(*args, args);
exit(1);
/* NOTREACHED */
default:
- wait();
+
xidle: improve program parsing
Lift the current argument limit (see BUGS section) and simplify the
parsing logic by turning `xidle -program "/bin/prog args"' into
`xidle prog args' where normal argv is used instead of an strsep(3)
routine.
Search PATH with execvp(3), drop unused status parameter from wait(2)
while here.
Merge `fopts' and `opts' since there is no need to split `-display'
parsing from the rest, so XrmParseCommand(3) is called once still
handling display setup first.
Users would have to adjust their xidle invocations but the change is
trivial and introduces nice improvements, so that's reasonble; I'd put
a note into current.html.
Feedback? Objections? OK?
PS: This diff applies cleanly against -CURRENT and is independent from
my earlier ones and but will conflict diff-wise.
Index: xidle.1
===
RCS file: /cvs/xenocara/app/xidle/xidle.1,v
retrieving revision 1.5
diff -u -p -r1.5 xidle.1
--- xidle.1 6 Sep 2018 07:21:34 - 1.5
+++ xidle.1 4 Nov 2018 01:43:21 -
@@ -23,7 +23,7 @@
.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
.\" OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
-.Dd June 20, 2005
+.Dd $Mdocdate: November 4 2018 $
.Dt XIDLE 1
.Os
.Sh NAME
@@ -36,8 +36,8 @@
.Op Fl delay Ar secs
.Op Fl display Ar display
.Op Fl no | nw | ne | sw | se
-.Op Fl program Ar path
.Op Fl timeout Ar secs
+.Op Ar program Op Ar args
.Ek
.Sh DESCRIPTION
.Nm
@@ -45,6 +45,8 @@ uses the
.Xr XScreenSaver 3
extension to receive inactivity events when a timeout is specified, running
a specific program after the elapsed time.
+The default is
+.Xr xlock 1 .
.Nm
will also run the program if it is sent a
.Dv SIGUSR1
@@ -71,14 +73,6 @@ Set the position to one of none, northwe
respectively.
If no position is specified,
the default is northwest.
-.It Fl program Ar path
-Specify the full pathname of the program to run on any of the
-aforementioned events.
-Arguments to the program may also be specified, separated by whitespace.
-If
-.Fl program
-is not specified, the default is
-.Xr xlock 1 .
.It Fl timeout Ar secs
Set the timeout to the specified number of seconds.
If
@@ -129,8 +123,7 @@ Run
using the flying bats mode if no activity is detected in 300 seconds or the
pointer sits in the southwest corner for more than 5 seconds:
.Bd -literal -offset indent
-$ xidle -delay 5 -sw -program "/usr/X11R6/bin/xlock -mode bat" \e
- -timeout 300
+$ xidle -delay 5 -sw xlock -mode bat -timeout 300
.Ed
.Sh SEE ALSO
.Xr xlock 1 ,
@@ -142,7 +135,3 @@ The
program was written by
.An Federico Schwindt Aq Mt fg...@openbsd.org
as an xautolock replacement.
-.Sh BUGS
-The maximum number of arguments for
-.Fl program ,
-including the executable file, is currently set to 9.
Index: xidle.c
===
RCS file: /cvs/xenocara/app/xidle/xidle.c,v
retrieving revision 1.6
diff -u -p -r1.6 xidle.c
--- xidle.c 6 Sep 2018 07:21:34 - 1.6
+++ xidle.c 4 Nov 2018 02:46:19 -
@@ -75,14 +75,10 @@ struct xinfo {
struct xinfo x;
-static XrmOptionDescRec fopts[] = {
- { "-display", ".display", XrmoptionSepArg,(caddr_t)NULL },
-};
-
static XrmOptionDescRec opts[] = {
{ "-area", ".area",XrmoptionSepArg,(caddr_t)NULL },
{ "-delay", ".delay", XrmoptionSepArg,(caddr_t)NULL },
- { "-program", ".program", XrmoptionSepArg,(caddr_t)NULL },
+ { "-display", ".display", XrmoptionSepArg,(caddr_t)NULL },
{ "-timeout", ".timeout", XrmoptionSepArg,(caddr_t)NULL },
{ "-no",".position",XrmoptionNoArg, (caddr_t)"no" },
@@ -94,13 +90,12 @@ static XrmOptionDescRec opts[] = {
extern char *__progname;
-void action(struct xinfo *, char **);
+void action(struct xinfo *, char *const []);
void close_x(struct xinfo *);
Bool getres(XrmValue *, const XrmDatabase, const char *, const char *);
voidinit_x(struct xinfo *, int, int, int);
void handler(int);
-void parse_opts(int, char **, Display **, int *, int *, int *, int *,
- char **);
+void parse_opts(int, char **[], Display **, int *, int *, int *, int *);
intstr2pos(const char *);
__dead voidusage(void);
@@ -108,9 +103,10 @@ __dead voidusage(void);
__dead void
usage()
{
- fprintf(stderr, "Usage:\n%s %s\n", __progname,
- "[-area pixels] [-delay secs] [-display host:dpy] "
- "[-no | -ne | -nw | -se | -sw]\n [-program path] [-timeout
secs]");
+ fprintf(stderr,
+ "usage:\t%s [-area pixels] [-delay secs] [-display host:dpy]\n"
+ "\t [-no | -ne | -nw | -se | -sw] [-timeout secs] "
+ "[program [args]]\n", __progname);
exit(1);
}
@@ -180,10 +176,8 @@ close_x(struct xinfo *xi)
void
-action(struct xinfo *xi, char
Adding GPIO support to wbsio(4)
Attached below is a diff that adds GPIO support to wbsio(4) for the Nuvoton
NCT5104D variant which is found on most of the recent PC Engines APU boards,
(I'm personally developing this on an APU4).
I've hit a problem that it causes the kernel to crash when probing for
lm78(4) which can be found on /some/ wbsio(4) chips, but not this particular
variant, so there aren't any to find. If I comment out the "lm* at wbsio?" in
the kernel configuration or comment out the latter `config_found()` call I
added to attach the GPIO bus then the kernel boots fine.
The kernel panic I get is:
...
wbsio0 at isa0 port 0x2e/2: NCT5104D rev 0x53
panic: bus_space_map: bad bus space tag
Stopped at db_enter+0x12: popq%r11
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
* 0 0 0 0x1 0x2000K swapper
db_enter(9a1e376995dc152,100,10,81f6aed8,202,8) at db_enter+0x12
panic(200,81f6b168,1a,8,800a3e58,81cb6a60) at
panic+0x120
bus_space_map(9a45ea3f225ed920,800a3e58,81f6b168,1a,81c93da0,0)
at bus_space_map+0x62
lm_wbsio_match(b99bd94bc1864cf1,81c93da0,81f6b080,1a,81c93da0,81c8fd76)
at lm_wbsio_match+0x4d
mapply(9766dee4470b4208,81c93da0,800a3e00,1a,81f6b080,81c93c18)
at mapply+0xbe
config_search(eef789b22abf,81f6b168,810b7d40,0,800a3e00,81c331f0)
at config_search+0xc0
config_found_sm(7a3bdef80501ee63,2e,0,800a3e00,814b088e,81f6b110)
at config_found_sm+0x2e
wbsio_attach(370b5c3cf5b5f4cc,800a3c00,81f6b558,81c73448,800a3e00,800a3e24)
at wbsio_attach+0x8de
config_attach(d3e35ce7cfd9a5c1,81c93c18,800a3e00,81f6b888,800a3c00,81f6b558)
at config_attach+0x1ee
isascan(370b5c3cf5b5fae4,8155f110,800a3c00,81c8cc01,81c93c18,81c8fdfc)
at isascan+0x1fb
config_scan(51e6e319330389e6,80084b00,81f6bc98,81c8ccf8,800a3c00,800a3c24)
at config_scan+0xb6
config_attach(d3e35ce7cfa11aa1,8008b2c0,8001cf00,81d2ecd8,0,8001cf24)
at config_attach+0x1ee
pcib_callback(b0d20c41cc678cce,30193439aff14287,0,81c740e8,81c33320,81c331f0)
at pcib_callback+0x5b
config_process_deferred_children(d810f4a0da8adfd1,80023100,81f6bd90,81c74730,8001cf00,0)
at config_process_deferred_children+0
x89
end trace frame: 0x81f6bd60, count: 0
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{0}>
So it crashes in lm_wbsio_match() which is in lm78_isa.c. I'm not sure why
bus_space_map() is failing, the GPIO portion doesn't map any I/O space, it's
all driven through the standard chip configuration registers.
Could someone possibly indicate what I've done wrong here? I've based the
GPIO attachment code on the same thing I did when implementing skgpio(4) and
as I mentioned, if I disable lm78(4) then the GPIO driver appears to attach
and function. I suspect I've got some subtlety of autoconf wrong.
Thanks
Matt
diff --git a/sys/arch/amd64/conf/GENERIC b/sys/arch/amd64/conf/GENERIC
index 9a74efca601..5aaa1f55651 100644
--- a/sys/arch/amd64/conf/GENERIC
+++ b/sys/arch/amd64/conf/GENERIC
@@ -123,6 +123,7 @@ schsio* at isa? port 0x164e
wbsio* at isa? port 0x2e # Winbond LPC Super I/O
wbsio* at isa? port 0x4e
lm*at wbsio?
+gpio* at wbsio?
uguru0 at isa? disable port 0xe0 # ABIT uGuru
aps0 at isa? port 0x1600 # ThinkPad Active Protection System
diff --git a/sys/arch/i386/conf/GENERIC b/sys/arch/i386/conf/GENERIC
index 40dc421cf45..e2349208064 100644
--- a/sys/arch/i386/conf/GENERIC
+++ b/sys/arch/i386/conf/GENERIC
@@ -147,6 +147,7 @@ viasio* at isa? port 0x4e flags 0x
wbsio* at isa? port 0x2e # Winbond LPC Super I/O
wbsio* at isa? port 0x4e
lm*at wbsio?
+gpio* at wbsio?
uguru0 at isa? disable port 0xe0 # ABIT uGuru
fins0 at isa? port 0x4e # Fintek F71805 Super I/O
diff --git a/sys/dev/isa/files.isa b/sys/dev/isa/files.isa
index 65877402ccf..f0fe6fc4e37 100644
--- a/sys/dev/isa/files.isa
+++ b/sys/dev/isa/files.isa
@@ -248,7 +248,7 @@ attach lpt at isa with lpt_isa
file dev/isa/lpt_isa.c lpt_isa
# Winbond LPC Super I/O
-device wbsio {}
+device wbsio {} : gpiobus
attach wbsio at isa
file dev/isa/wbsio.c wbsio
diff --git a/sys/dev/isa/wbsio.c b/sys/dev/isa/wbsio.c
index 7147d481732..31ad1cecec0 100644
--- a/sys/dev/isa/wbsio.c
+++ b/sys/dev/isa/wbsio.c
@@ -23,12 +23,15 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
+
#ifdef WBSIO_DEBUG
#define DPRINTF(x) printf x
#else
@@ -40,12 +43,21 @@ struct wbsio_softc {
Re: NMEA: add more gps sensor values (altitude, precision...)
Mark Kettenis wrote: > SENSOR_VELOCITY would make sense. It should be m/s with some > appropriate scaling. We don't need to represent speeds higer than > 299792458 m/s, so micrometers per second would be a good choice. is it reasonable to use mm/s so that distance and velocity are consistent?
[PATCH] [src] usr.sbin/ldapd/btree.3 - style fix
Hi all, Style fix. Regards, Raf Index: usr.sbin/ldapd/btree.3 === RCS file: /cvs/src/usr.sbin/ldapd/btree.3,v retrieving revision 1.4 diff -u -p -r1.4 btree.3 --- usr.sbin/ldapd/btree.3 16 Jul 2013 11:13:33 - 1.4 +++ usr.sbin/ldapd/btree.3 3 Nov 2018 21:45:09 - @@ -43,9 +43,9 @@ .Nm btree_get_path , .Nm btree_cmp , .Nm btval_reset -.Nd Append-only prefix B+Tree database library. +.Nd append-only prefix B+Tree database library .Sh SYNOPSIS -.Fd #include +.In btree.h .Ft "struct btree *" .Fn "btree_open_fd" "int fd" "unsigned int flags" .Ft "struct btree *"
Re: Reuse VM ids.
On Sat, 27 Oct 2018 14:53:16 -0700, Ori Bernstein wrote: > On Fri, 26 Oct 2018 01:57:15 +0200, Reyk Floeter wrote: > > > On Tue, Oct 23, 2018 at 10:21:08PM -0700, Ori Bernstein wrote: > > > On Mon, 8 Oct 2018 07:59:15 -0700, Bob Beck wrote: > > > > > > > works here and I like it. but probably for after unlock > > > > > > > > > > It's after unlock -- pinging for OKs. > > > > > > > Not yet. Please include the VM's uid in the claim, e.g. > > > > claim_vmid(const char *name, uid_t uid) > > > > It is not a strong protection, but it doesn't make sense that other > > users can run a VM with the same name and get the claimed Id. > > > > Reyk > > > > Updated. > > Ok? > Ping? -- Ori Bernstein
Re: Qcow2: Clean up logging/error handling
On Tue, 30 Oct 2018 23:01:50 -0700, Mike Larkin wrote:
> On Tue, Oct 30, 2018 at 10:41:21PM -0700, o...@eigenstate.org wrote:
> > > On Tue, Oct 30, 2018 at 10:32:37PM -0700, Ori Bernstein wrote:
> > >> On Tue, 30 Oct 2018 22:29:01 -0700, Mike Larkin
> > >> wrote:
> > >>
> > >> > > -if (disk->base->clustersz != disk->clustersz) {
> > >> > > -log_warn("%s: all disks must share clustersize",
> > >> > > +fatal("%s: could not open %s", basepath,
> > >> > > __func__);
> > >> >
> > >> > is this right?
> > >> >
> > >> > > +if (qc2_open(disk->base, fds + 1, nfd - 1) == -1)
> > >> > > +fatalx("%s: could not open %s", basepath,
> > >> > > __func__);
> > >> >
> > >> > same
> > >> >
> > >> > > +if (disk->base->clustersz != disk->clustersz)
> > >> > > +fatalx("%s: all disk parts must share
> > >> > > clustersize",
> > >> > > __func__);
> > >> > > -goto error;
> > >> > > -}
> > >> > > -}
> > >>
> > >> Good question. I think from earlier discussion, we wanted to fail if we
> > >> could
> > >> not open a disk image -- especially since these ones are actually
> > >> *parts* of
> > >> a disk image, meaning that we've got a corrupt image.
> > >>
> > >> I can easily change these back to warns + error returns.
> > >>
> > >> --
> > >> Ori Bernstein
> > >
> > > I was referring to the argument order.
> >
> > Oh, that's obviously wrong. Updated.
> >
>
> with that fix, go for it. we can hack on it further in-tree.
>
Anyone want to give me a second ok?
--
Ori Bernstein
Re: add altitude & speed sensor types
On Sat, Nov 03, 2018 at 08:40:33PM +0100, Mark Kettenis wrote: > > Date: Sat, 3 Nov 2018 20:09:32 +0100 > > From: Landry Breuil > > > > On Sat, Nov 03, 2018 at 05:27:03PM +0100, Landry Breuil wrote: > > > Hi, > > > > > > complementary to the previous diff, adds altitude sensor type (in > > > meters) and speed (in m/s, as it seems that's the common denominator and > > > most accepted unit, even if it doesnt 'mean' anything to humans...) > > > i still have to ponder about the decimals & intervals.. > > > > New diff after feedback from kettenis@, this one: > > - adds SENSOR_VELOCITY, internal unit um/s, display unit m/s > > - changes SENSOR_DISTANCE to display as meters, i kept 5 decimals > > That's a strange number. 3 decimals would be more reasonable I'd say. Well that was only in case there's a proximity sensor with sub-millimeter precision... but 3 is fine for me too.
xidle: do not close stdout/err
Closing stdin makes sense, but I still want to see error messages from the program I'm running. Since arbitrary progams can be run, keep both stdout and stderr open so users get a chance to actually notice program failure or maybe even use output for good. In a common setup where xidle(1) is started from ~/.xsession, I'd expect errors to pop up in ~/.xsession-errors. OK? Index: xidle.c === RCS file: /cvs/xenocara/app/xidle/xidle.c,v retrieving revision 1.6 diff -u -p -r1.6 xidle.c --- xidle.c 6 Sep 2018 07:21:34 - 1.6 +++ xidle.c 3 Nov 2018 19:54:41 - @@ -362,12 +362,10 @@ main(int argc, char **argv) signal(SIGTERM, handler); signal(SIGUSR1, handler); - fd = open(_PATH_DEVNULL, O_RDWR, 0); + fd = open(_PATH_DEVNULL, O_RDONLY, 0); if (fd < 0) err(1, _PATH_DEVNULL); dup2(fd, STDIN_FILENO); - dup2(fd, STDOUT_FILENO); - dup2(fd, STDERR_FILENO); if (fd > 2) close(fd);
xidle: use strtonum(3), zap NOTREACHED
Simpler and without ugly `goto fail'. `value.addr` is typed XPointer
which is just a char pointer.
Zap linter hints while here.
OK?
Index: xidle.c
===
RCS file: /cvs/xenocara/app/xidle/xidle.c,v
retrieving revision 1.6
diff -u -p -r1.6 xidle.c
--- xidle.c 6 Sep 2018 07:21:34 - 1.6
+++ xidle.c 3 Nov 2018 19:33:38 -
@@ -187,14 +187,10 @@ action(struct xinfo *xi, char **args)
switch (fork()) {
case -1:
err(1, "fork");
- /* NOTREACHED */
-
case 0:
setsid();
execv(*args, args);
exit(1);
- /* NOTREACHED */
-
default:
wait();
XSync(xi->dpy, True);
@@ -259,6 +255,7 @@ void
parse_opts(int argc, char **argv, Display **dpy, int *area, int *delay,
int *timeout, int *position, char **args)
{
+ const char *errstr;
char **ap, *program = PATH_PROG;
char *display, *p;
XrmDatabase tdb, rdb = NULL;
@@ -276,7 +273,6 @@ parse_opts(int argc, char **argv, Displa
*dpy = XOpenDisplay(display);
if (!*dpy) {
errx(1, "Unable to open display %s", XDisplayName(display));
- /* NOTREACHED */
}
/* Get server resources database. */
@@ -297,29 +293,26 @@ parse_opts(int argc, char **argv, Displa
__progname, , argv);
if (argc > 1) {
usage();
- /* NOTREACHED */
}
if (getres(, rdb, "area", "Area")) {
- *area = strtol((char *)value.addr, , 10);
- if (*p || *area < 1) {
-fail: errx(1, "illegal value -- %s", (char *)value.addr);
- /* NOTREACHED */
- }
+ *area = strtonum(value.addr, 0, INT_MAX, );
+ if (errstr)
+ errx(1, "area is %s: %s", errstr, value.addr);
}
if (getres(, rdb, "delay", "Delay")) {
- *delay = strtol((char *)value.addr, , 10);
- if (*p || *delay < 0)
- goto fail;
+ *delay = strtonum(value.addr, 0, INT_MAX, );
+ if (errstr)
+ errx(1, "delay is %s: %s", errstr, value.addr);
}
if (getres(, rdb, "position", "Position")) {
*position = str2pos((char *)value.addr);
if (!*position)
- goto fail;
+ errx(1, "position is invalid: %s", value.addr);
}
if (getres(, rdb, "timeout", "Timeout")) {
- *timeout = strtol((char *)value.addr, , 10);
- if (*p || *timeout < 0)
- goto fail;
+ *timeout = strtonum(value.addr, 0, INT_MAX, );
+ if (errstr)
+ errx(1, "timeout is %s: %s", errstr, value.addr);
}
if (getres(, rdb, "program", "Program")) {
/* Should be the last :) */
@@ -454,6 +447,4 @@ main(int argc, char **argv)
break;
}
}
-
- /* NOTREACHED */
}
Re: add altitude & speed sensor types
> Date: Sat, 3 Nov 2018 20:09:32 +0100 > From: Landry Breuil > > On Sat, Nov 03, 2018 at 05:27:03PM +0100, Landry Breuil wrote: > > Hi, > > > > complementary to the previous diff, adds altitude sensor type (in > > meters) and speed (in m/s, as it seems that's the common denominator and > > most accepted unit, even if it doesnt 'mean' anything to humans...) > > i still have to ponder about the decimals & intervals.. > > New diff after feedback from kettenis@, this one: > - adds SENSOR_VELOCITY, internal unit um/s, display unit m/s > - changes SENSOR_DISTANCE to display as meters, i kept 5 decimals That's a strange number. 3 decimals would be more reasonable I'd say. > I think my math should be good, but more eyes are always welcome :) Looks reasonable, but I'm not sure about the snmpd stuff.
Re: NMEA: add more gps sensor values (altitude, precision...)
> Date: Sat, 3 Nov 2018 18:12:35 +0100 > From: Landry Breuil > > > Well, altitude really is just a vertical distance, so SENSOR_DISTANCE > > is the right one. You obviously should convert the altitude from > > meters into millimeters. If you think it would be more appropriate to > > display distances in meters, we (you?) can adjust sysctl(8). > > Agreed, from what i understand there's a difference between 'the unit in > which the value is stored internally in the int64_t' and the 'the unit > used when displaying the value'. Correct. The internal unit is chosen to provide a sensible range and precision given that it is stored into an int64_t. How it gets displayed is entirely up to the code that interprets the value.
Re: NMEA: add more gps sensor values (altitude, precision, speed, #satellites...)
On Sat, Nov 03, 2018 at 05:00:47PM +0100, Landry Breuil wrote:
> Hi,
New diff adding speed and # of satellites, uses SENSOR_VELOCITY as
posted in the previous diff, and relies on SENSOR_DISTANCE being shown
as meters. I redid the message type matching to account for
constellation types which was commented out in the previous diff. More
proofreading welcome, especially in the conversions and the handrolled
atoi implem...
That gives:
nmea0.indicator0 OnOKSignal
nmea0.raw0 5 rawOKNb satellites
nmea0.raw1 1 rawOKGPS fix
nmea0.raw2 2030 raw WARNING HDOP
nmea0.raw3 2330 raw WARNING VDOP
nmea0.raw4 3080 raw WARNING PDOP
nmea0.timedelta030.311 msOKGPS autonomous
nmea0.angle0 xx. degreesOKLatitude
nmea0.angle1 z. degreesOKLongitude
nmea0.distance0 381.0 mOKAltitude
nmea0.velocity0 0.319 m/sOKGround speed
I need to do more velocity testing when moving.. as GPS is not reliable
when *not* moving :)
When there's no signal (ie, staying inside without satellite coverage)
nmea0.indicator0 Off CRITICAL Signal
nmea0.raw0 0 rawOKNb satellites
nmea0.raw1 0 raw CRITICAL Invalid
nmea0.raw2 0 raw WARNING HDOP
nmea0.raw3 0 raw WARNING VDOP
nmea0.raw4 0 raw WARNING PDOP
nmea0.timedelta027.195 msOKGPS invalid
nmea0.angle0 xx. degrees WARNING Latitude
nmea0.angle1 z. degrees WARNING Longitude
nmea0.distance0 0.0 m WARNING Altitude
nmea0.velocity0 0.000 m/s WARNING Ground speed
Most statuses should just be CRITICAL, and i think in that case the position
is 'last known'.
Landry
Index: kern/tty_nmea.c
===
RCS file: /cvs/src/sys/kern/tty_nmea.c,v
retrieving revision 1.47
diff -u -r1.47 tty_nmea.c
--- kern/tty_nmea.c 1 Sep 2018 06:09:26 - 1.47
+++ kern/tty_nmea.c 3 Nov 2018 19:08:47 -
@@ -29,6 +29,10 @@
#ifdef NMEA_DEBUG
#define DPRINTFN(n, x) do { if (nmeadebug > (n)) printf x; } while (0)
int nmeadebug = 0;
+/*
+ * 1 = print interesting messages
+ * 2 = print all messages
+ */
#else
#define DPRINTFN(n, x)
#endif
@@ -52,6 +56,13 @@
struct ksensor signal; /* signal status */
struct ksensor latitude;
struct ksensor longitude;
+ struct ksensor altitude;
+ struct ksensor speed;
+ struct ksensor nsat;
+ struct ksensor quality;
+ struct ksensor hdop;
+ struct ksensor vdop;
+ struct ksensor pdop;
struct ksensordev timedev;
struct timespec ts; /* current timestamp */
struct timespec lts;/* timestamp of last '$' seen */
@@ -70,6 +81,8 @@
/* NMEA decoding */
void nmea_scan(struct nmea *, struct tty *);
void nmea_gprmc(struct nmea *, struct tty *, char *fld[], int fldcnt);
+void nmea_decode_gsa(struct nmea *, struct tty *, char *fld[], int fldcnt);
+void nmea_decode_gga(struct nmea *, struct tty *, char *fld[], int fldcnt);
/* date and time conversion */
intnmea_date_to_nano(char *s, int64_t *nano);
@@ -77,6 +90,7 @@
/* longitude and latitude conversion */
intnmea_degrees(int64_t *dst, char *src, int neg);
+intnmea_atoi(int64_t *dst, char *src, int decimal);
/* degrade the timedelta sensor */
void nmea_timeout(void *);
@@ -126,6 +140,55 @@
strlcpy(np->longitude.desc, "Longitude", sizeof(np->longitude.desc));
sensor_attach(>timedev, >longitude);
+ np->altitude.type = SENSOR_DISTANCE;
+ np->altitude.status = SENSOR_S_UNKNOWN;
+ np->altitude.flags = SENSOR_FINVALID;
+ np->altitude.value = 0;
+ strlcpy(np->altitude.desc, "Altitude", sizeof(np->altitude.desc));
+ sensor_attach(>timedev, >altitude);
+
+ np->speed.type = SENSOR_VELOCITY;
+ np->speed.status = SENSOR_S_UNKNOWN;
+ np->speed.flags = SENSOR_FINVALID;
+ np->speed.value = 0;
+ strlcpy(np->speed.desc, "Ground speed", sizeof(np->speed.desc));
+ sensor_attach(>timedev, >speed);
+
+ np->nsat.type = SENSOR_INTEGER;
+ np->nsat.status = SENSOR_S_UNKNOWN;
+ np->nsat.flags = SENSOR_FINVALID;
+ np->nsat.value = 0;
+
Re: add altitude & speed sensor types
On Sat, Nov 03, 2018 at 05:27:03PM +0100, Landry Breuil wrote:
> Hi,
>
> complementary to the previous diff, adds altitude sensor type (in
> meters) and speed (in m/s, as it seems that's the common denominator and
> most accepted unit, even if it doesnt 'mean' anything to humans...)
> i still have to ponder about the decimals & intervals..
New diff after feedback from kettenis@, this one:
- adds SENSOR_VELOCITY, internal unit um/s, display unit m/s
- changes SENSOR_DISTANCE to display as meters, i kept 5 decimals
I think my math should be good, but more eyes are always welcome :)
Landry
Index: sys/sys/sensors.h
===
RCS file: /cvs/src/sys/sys/sensors.h,v
retrieving revision 1.35
diff -u -r1.35 sensors.h
--- sys/sys/sensors.h 8 Apr 2017 04:06:01 - 1.35
+++ sys/sys/sensors.h 3 Nov 2018 18:11:53 -
@@ -52,6 +52,7 @@
SENSOR_DISTANCE,/* distance (uMeter) */
SENSOR_PRESSURE,/* pressure (mPa) */
SENSOR_ACCEL, /* acceleration (u m/s^2) */
+ SENSOR_VELOCITY,/* velocity (u m/s) */
SENSOR_MAX_TYPES
};
@@ -78,6 +79,7 @@
"distance",
"pressure",
"acceleration",
+ "velocity",
"undefined"
};
#endif /* !_KERNEL */
Index: share/snmp/OPENBSD-SENSORS-MIB.txt
===
RCS file: /cvs/src/share/snmp/OPENBSD-SENSORS-MIB.txt,v
retrieving revision 1.6
diff -u -r1.6 OPENBSD-SENSORS-MIB.txt
--- share/snmp/OPENBSD-SENSORS-MIB.txt 2 Sep 2016 12:17:33 - 1.6
+++ share/snmp/OPENBSD-SENSORS-MIB.txt 3 Nov 2018 18:11:53 -
@@ -26,7 +26,7 @@
FROM SNMPv2-CONF;
sensorsMIBObjects MODULE-IDENTITY
- LAST-UPDATED "20120920Z"
+ LAST-UPDATED "20181103Z"
ORGANIZATION "OpenBSD"
CONTACT-INFO
"Editor:Reyk Floeter
@@ -39,6 +39,9 @@
DESCRIPTION
"The MIB module for gathering information from
OpenBSD's kernel sensor framework."
+ REVISION "20181103Z"
+ DESCRIPTION
+ "Add new sensor types."
REVISION "20120920Z"
DESCRIPTION
"Add new sensor types."
@@ -136,7 +139,8 @@
angle(17),
distance(18),
pressure(19),
- accel(20)
+ accel(20),
+ velocity(21)
}
MAX-ACCESS read-only
STATUS current
Index: usr.sbin/snmpd/mib.c
===
RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
retrieving revision 1.85
diff -u -r1.85 mib.c
--- usr.sbin/snmpd/mib.c18 Dec 2017 05:51:53 - 1.85
+++ usr.sbin/snmpd/mib.c3 Nov 2018 18:11:54 -
@@ -2617,7 +2617,7 @@
static const char * const sensor_unit_s[SENSOR_MAX_TYPES + 1] = {
"degC", "RPM", "V DC", "V AC", "Ohm", "W", "A", "Wh", "Ah",
"", "", "%", "lx", "", "sec", "%RH", "Hz", "degree",
- "mm", "Pa", "m/s^2", ""
+ "m", "Pa", "m/s^2", "m/s", ""
};
const char *
@@ -2649,6 +2649,8 @@
case SENSOR_LUX:
case SENSOR_FREQ:
case SENSOR_ACCEL:
+ case SENSOR_VELOCITY:
+ case SENSOR_DISTANCE:
ret = asprintf(, "%.2f", s->value / 100.0);
break;
case SENSOR_INDICATOR:
@@ -2658,7 +2660,6 @@
case SENSOR_HUMIDITY:
ret = asprintf(, "%.2f", s->value / 1000.0);
break;
- case SENSOR_DISTANCE:
case SENSOR_PRESSURE:
ret = asprintf(, "%.2f", s->value / 1000.0);
break;
Index: usr.sbin/sensorsd/sensorsd.c
===
RCS file: /cvs/src/usr.sbin/sensorsd/sensorsd.c,v
retrieving revision 1.62
diff -u -r1.62 sensorsd.c
--- usr.sbin/sensorsd/sensorsd.c22 Oct 2018 16:20:09 - 1.62
+++ usr.sbin/sensorsd/sensorsd.c3 Nov 2018 18:11:55 -
@@ -692,7 +692,7 @@
snprintf(fbuf, RFBUFSIZ, "%lld", value);
break;
case SENSOR_DISTANCE:
- snprintf(fbuf, RFBUFSIZ, "%.2f mm", value / 1000.0);
+ snprintf(fbuf, RFBUFSIZ, "%.5f m", value / 100.0);
break;
case SENSOR_PRESSURE:
snprintf(fbuf, RFBUFSIZ, "%.2f Pa", value / 1000.0);
@@ -700,6 +700,9 @@
case SENSOR_ACCEL:
snprintf(fbuf, RFBUFSIZ, "%2.4f m/s^2", value / 100.0);
break;
+ case SENSOR_VELOCITY:
+ snprintf(fbuf, RFBUFSIZ, "%4.3f m/s", value / 100.0);
+ break;
default:
snprintf(fbuf, RFBUFSIZ, "%lld ???", value);
}
@@ -813,13 +816,14 @@
case SENSOR_LUX:
Re: xenodm: remove unused 'keyFile' resource
OK
xenodm: remove unused 'keyFile' resource
Hi,
The 'keyfile' resource is not used anymore in xenodm (it was used to
specify the secret keys for the XDM-AUTHORIZATION-1 authentication
protocol in xdm with xdmcp).
ok?
Index: config/xenodm-config.in
===
RCS file: /cvs/OpenBSD/xenocara/app/xenodm/config/xenodm-config.in,v
retrieving revision 1.4
diff -u -p -u -r1.4 xenodm-config.in
--- config/xenodm-config.in 5 Sep 2017 17:48:07 - 1.4
+++ config/xenodm-config.in 3 Nov 2018 16:37:43 -
@@ -2,7 +2,6 @@
!
DisplayManager.authDir:@XENODMXAUTHDIR@
DisplayManager.errorLogFile: @XENODMLOGDIR@/xenodm.log
-DisplayManager.keyFile:@XENODMCONFIGDIR@/xenodm-keys
DisplayManager.servers:@XENODMCONFIGDIR@/Xservers
DisplayManager*resources: @XENODMCONFIGDIR@/Xresources
! All displays should use authorization, but we cannot be sure
Index: include/dm.h
===
RCS file: /cvs/OpenBSD/xenocara/app/xenodm/include/dm.h,v
retrieving revision 1.13
diff -u -p -u -r1.13 dm.h
--- include/dm.h10 Jul 2018 14:20:42 - 1.13
+++ include/dm.h3 Nov 2018 16:35:48 -
@@ -182,7 +182,6 @@ extern int daemonMode;
extern char*authDir;
extern int autoRescan;
extern int removeDomainname;
-extern char*keyFile;
extern char**exportList;
extern struct display *FindDisplayByName (char *name),
Index: xenodm/resource.c
===
RCS file: /cvs/OpenBSD/xenocara/app/xenodm/xenodm/resource.c,v
retrieving revision 1.4
diff -u -p -u -r1.4 resource.c
--- xenodm/resource.c 10 Jul 2018 15:32:27 - 1.4
+++ xenodm/resource.c 3 Nov 2018 16:36:16 -
@@ -50,7 +50,6 @@ int sourceAddress;
char *authDir;
intautoRescan;
intremoveDomainname;
-char *keyFile;
char **exportList;
#define DM_STRING 0
@@ -95,9 +94,6 @@ char **exportList;
#ifndef DEF_USER_AUTH_DIR
# define DEF_USER_AUTH_DIR "/tmp"
#endif
-#ifndef DEF_KEY_FILE
-# define DEF_KEY_FILE ""
-#endif
#ifndef DEF_ACCESS_FILE
# define DEF_ACCESS_FILE ""
#endif
@@ -122,8 +118,6 @@ struct dmResources {
"true"} ,
{ "removeDomainname","RemoveDomainname",DM_BOOL,(char **) ,
"true"} ,
-{ "keyFile", "KeyFile", DM_STRING, ,
- DEF_KEY_FILE} ,
{ "exportList","ExportList", DM_ARGV,(char **) ,
""} ,
{ "sourceAddress","SourceAddress",DM_BOOL, (char **) ,
--
Matthieu Herrb
Re: NMEA: add more gps sensor values (altitude, precision...)
On Sat, Nov 03, 2018 at 05:42:26PM +0100, Mark Kettenis wrote: > > Date: Sat, 3 Nov 2018 17:00:47 +0100 > > From: Landry Breuil > > > > two problems with this display: > > - DOPs are usually decimal values, ie 1.3, 1.53.. but raw sensors only > > support integers, hence *1000. > > We could add a SENSOR_FIXEDPOINT if we can come up with a reasonable > representation. Probably should be binary, and maybe we'd simply put > the radix point smack in the middle. But I'm not convinced DUP is a > good enough reason to introduce this. Same, so that might stay this way for now. The DOPs are interesting, but a bit abstract to me.. > > - GGA messages provide altitude as '355.5' in meters (i *think* the unit > > is fixed in the protocol, because altitude in feets is provided by > > PGRMZ) - and we only have a SENSOR_DISTANCE type in mm (which doesnt > > seem used by any driver..). Thus altitude shown in milimeters.. > > This sensor types were added in > > https://github.com/openbsd/src/commit/d95200b806051887b8c69294833e22dad6302828 > > but no driver apparently makes use of it. > > Well, altitude really is just a vertical distance, so SENSOR_DISTANCE > is the right one. You obviously should convert the altitude from > meters into millimeters. If you think it would be more appropriate to > display distances in meters, we (you?) can adjust sysctl(8). Agreed, from what i understand there's a difference between 'the unit in which the value is stored internally in the int64_t' and the 'the unit used when displaying the value'. As nothing uses SENSOR_DISTANCE for now, we can decide to switch all 'users' to show it as meter right now, don't change the current internal storage unit (ie, uMeter per the sensors.h comment ?) and if there's a proximity sensor someday (with its native unit being millimeters) it will be displayed as '0.00022 m' for 0.22mm, right ? > > >From that point, questions: > > - should i add more 'interesting' sensor values, like amount of satellites > > seen/used ? > > Number of satellites is probably interesting. Ok, will add that one. I dont necessarly want to clutter the hw tree with all sensors/values available, only keep the relevant ones.. > > - i want to add speed value (as RMC has it in knots?, and VTG in various > > units, per http://aprs.gids.nl/nmea/#vtg), but we only have > > SENSOR_ACCEL type in m.s-2 (which is only used by asmc(4)). Should we > > add a 'speed' sensor type ? in m/s ? in km/h ? knots ? > > SENSOR_VELOCITY would make sense. It should be m/s with some > appropriate scaling. We don't need to represent speeds higer than > 299792458 m/s, so micrometers per second would be a good choice. In that case, if i understand it right, that would be 'store internally as micrometers per second' then 'display to user as meter per second' ? > > - should i add a SENSOR_ALTITUDE type in meters ? > > I don't think so. Ok, will withdraw that part, add SENSOR_VELOCITY and reuse SENSOR_DISTANCE. Thanks for your comments !
Re: NMEA: add more gps sensor values (altitude, precision...)
On Sat, Nov 03, 2018 at 05:00:47PM +0100, Landry Breuil wrote: > Hi, > > here's a diff to add 5 new sensor values to nmea: altitude, quality, > hdop, vdop & pdop. altitude and quality are provided by GGA messages: > http://aprs.gids.nl/nmea/#gga, quality is either 0 (no fix), 1 (gps fix) > or 2 (dgps fix). > > The last 3 are 'Dilution of precision' values, respectively horizontal, > vertical & positional (ie 3d), cf > https://en.wikipedia.org/wiki/Dilution_of_precision_(navigation) & > http://www.trakgps.com/en/index.php/information/gps-articles-information/65-gps-accuracy > and are provided by GSA messages: http://aprs.gids.nl/nmea/#gsa it is > generally considered good precision when the DOP is below 2, so i've set > the sensor status warning accordingly. > > this provides for example (angle values hidden for 'privacy', just after > the gps got a fix): > nmea0.indicator0 OnOKSignal > nmea0.raw0 1 rawOKGPS fix > nmea0.raw1 1920 rawOKHDOP > nmea0.raw2 2520 raw WARNING VDOP > nmea0.raw3 3170 raw WARNING PDOP > nmea0.timedelta024.867 msOKGPS autonomous > nmea0.angle0 xx. degreesOKLatitude > nmea0.angle1 z. degreesOKLongitude > nmea0.distance0 371.50 mmOKAltitude > > and after a while, when precision improved: > nmea0.indicator0 OnOKSignal > nmea0.raw0 1 rawOKGPS fix > nmea0.raw1800 rawOKHDOP > nmea0.raw2 1300 rawOKVDOP > nmea0.raw3 1530 rawOKPDOP > nmea0.timedelta0 -296.499 msOKGPS autonomous > nmea0.angle0 xx. degreesOKLatitude > nmea0.angle1 z. degreesOKLongitude > nmea0.distance0 355.50 mmOKAltitude > > two problems with this display: > - DOPs are usually decimal values, ie 1.3, 1.53.. but raw sensors only > support integers, hence *1000. > > - GGA messages provide altitude as '355.5' in meters (i *think* the unit > is fixed in the protocol, because altitude in feets is provided by > PGRMZ) - and we only have a SENSOR_DISTANCE type in mm (which doesnt > seem used by any driver..). Thus altitude shown in milimeters.. > This sensor types were added in > https://github.com/openbsd/src/commit/d95200b806051887b8c69294833e22dad6302828 > but no driver apparently makes use of it. > > From that point, questions: > - should i add more 'interesting' sensor values, like amount of satellites > seen/used ? Yes, num sats is as quality indicator to show how much error is in the gps fix. > > - i want to add speed value (as RMC has it in knots?, and VTG in various > units, per http://aprs.gids.nl/nmea/#vtg), but we only have > SENSOR_ACCEL type in m.s-2 (which is only used by asmc(4)). Should we > add a 'speed' sensor type ? in m/s ? in km/h ? knots ? Hmmm...what's the common case for movement: are we walking (m/s), driving (km/h), or on a boat (knots)? > > - should i add a SENSOR_ALTITUDE type in meters ? Yes. > > - is there any interest in all this, from the sensors framework POV ? I think it'll be niffty to be able to trigger on events via sensord. +--+ Carlos > Otherwise i can leave it as is and just use gpsd in userspace, which > works 100% fine... > > All this done with an > umodem0 at uhub1 port 1 configuration 1 interface 0 "u-blox AG - > www.u-blox.com u-blox GNSS receiver" rev 1.10/2.01 addr 3 > > which works fine with ldattach & gpsd, ie i run doas gpsd -N -D2 $(doas > ldattach -p nmea /dev/cuaU0) and gpsmon shows me the msgs received by > the device, sent to the kernel via ldattach, and forwarded to gpsd. > > comments welcome, diff not to be commited as is of course (nmea_atoi is > *horrible*, i know..) > > Landry
Re: NMEA: add more gps sensor values (altitude, precision...)
> Date: Sat, 3 Nov 2018 17:00:47 +0100 > From: Landry Breuil > > Hi, > > here's a diff to add 5 new sensor values to nmea: altitude, quality, > hdop, vdop & pdop. altitude and quality are provided by GGA messages: > http://aprs.gids.nl/nmea/#gga, quality is either 0 (no fix), 1 (gps fix) > or 2 (dgps fix). > > The last 3 are 'Dilution of precision' values, respectively horizontal, > vertical & positional (ie 3d), cf > https://en.wikipedia.org/wiki/Dilution_of_precision_(navigation) & > http://www.trakgps.com/en/index.php/information/gps-articles-information/65-gps-accuracy > and are provided by GSA messages: http://aprs.gids.nl/nmea/#gsa it is > generally considered good precision when the DOP is below 2, so i've set > the sensor status warning accordingly. > > this provides for example (angle values hidden for 'privacy', just after > the gps got a fix): > nmea0.indicator0 OnOKSignal > nmea0.raw0 1 rawOKGPS fix > nmea0.raw1 1920 rawOKHDOP > nmea0.raw2 2520 raw WARNING VDOP > nmea0.raw3 3170 raw WARNING PDOP > nmea0.timedelta024.867 msOKGPS autonomous > nmea0.angle0 xx. degreesOKLatitude > nmea0.angle1 z. degreesOKLongitude > nmea0.distance0 371.50 mmOKAltitude > > and after a while, when precision improved: > nmea0.indicator0 OnOKSignal > nmea0.raw0 1 rawOKGPS fix > nmea0.raw1800 rawOKHDOP > nmea0.raw2 1300 rawOKVDOP > nmea0.raw3 1530 rawOKPDOP > nmea0.timedelta0 -296.499 msOKGPS autonomous > nmea0.angle0 xx. degreesOKLatitude > nmea0.angle1 z. degreesOKLongitude > nmea0.distance0 355.50 mmOKAltitude > > two problems with this display: > - DOPs are usually decimal values, ie 1.3, 1.53.. but raw sensors only > support integers, hence *1000. We could add a SENSOR_FIXEDPOINT if we can come up with a reasonable representation. Probably should be binary, and maybe we'd simply put the radix point smack in the middle. But I'm not convinced DUP is a good enough reason to introduce this. > - GGA messages provide altitude as '355.5' in meters (i *think* the unit > is fixed in the protocol, because altitude in feets is provided by > PGRMZ) - and we only have a SENSOR_DISTANCE type in mm (which doesnt > seem used by any driver..). Thus altitude shown in milimeters.. > This sensor types were added in > https://github.com/openbsd/src/commit/d95200b806051887b8c69294833e22dad6302828 > but no driver apparently makes use of it. Well, altitude really is just a vertical distance, so SENSOR_DISTANCE is the right one. You obviously should convert the altitude from meters into millimeters. If you think it would be more appropriate to display distances in meters, we (you?) can adjust sysctl(8). > >From that point, questions: > - should i add more 'interesting' sensor values, like amount of satellites > seen/used ? Number of satellites is probably interesting. > - i want to add speed value (as RMC has it in knots?, and VTG in various > units, per http://aprs.gids.nl/nmea/#vtg), but we only have > SENSOR_ACCEL type in m.s-2 (which is only used by asmc(4)). Should we > add a 'speed' sensor type ? in m/s ? in km/h ? knots ? SENSOR_VELOCITY would make sense. It should be m/s with some appropriate scaling. We don't need to represent speeds higer than 299792458 m/s, so micrometers per second would be a good choice. > - should i add a SENSOR_ALTITUDE type in meters ? I don't think so. > - is there any interest in all this, from the sensors framework POV ? > Otherwise i can leave it as is and just use gpsd in userspace, which > works 100% fine... Having the position and some quality indicators available makes sense to me. > All this done with an > umodem0 at uhub1 port 1 configuration 1 interface 0 "u-blox AG - > www.u-blox.com u-blox GNSS receiver" rev 1.10/2.01 addr 3 > > which works fine with ldattach & gpsd, ie i run doas gpsd -N -D2 $(doas > ldattach -p nmea /dev/cuaU0) and gpsmon shows me the msgs received by > the device, sent to the kernel via ldattach, and forwarded to gpsd. > > comments welcome, diff not to be commited as is of course (nmea_atoi is > *horrible*, i know..) > > Landry
add altitude & speed sensor types
Hi,
complementary to the previous diff, adds altitude sensor type (in
meters) and speed (in m/s, as it seems that's the common denominator and
most accepted unit, even if it doesnt 'mean' anything to humans...)
i still have to ponder about the decimals & intervals..
builds, not used yet.
Landry
Index: share/snmp/OPENBSD-SENSORS-MIB.txt
===
RCS file: /cvs/src/share/snmp/OPENBSD-SENSORS-MIB.txt,v
retrieving revision 1.6
diff -u -r1.6 OPENBSD-SENSORS-MIB.txt
--- share/snmp/OPENBSD-SENSORS-MIB.txt 2 Sep 2016 12:17:33 - 1.6
+++ share/snmp/OPENBSD-SENSORS-MIB.txt 3 Nov 2018 16:23:57 -
@@ -39,6 +39,9 @@
DESCRIPTION
"The MIB module for gathering information from
OpenBSD's kernel sensor framework."
+ REVISION "20181103Z"
+ DESCRIPTION
+ "Add new sensor types."
REVISION "20120920Z"
DESCRIPTION
"Add new sensor types."
@@ -136,7 +139,9 @@
angle(17),
distance(18),
pressure(19),
- accel(20)
+ accel(20),
+ altitude(21),
+ speed(22)
}
MAX-ACCESS read-only
STATUS current
Index: usr.sbin/snmpd/mib.c
===
RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
retrieving revision 1.85
diff -u -r1.85 mib.c
--- usr.sbin/snmpd/mib.c18 Dec 2017 05:51:53 - 1.85
+++ usr.sbin/snmpd/mib.c3 Nov 2018 16:23:59 -
@@ -2617,7 +2617,7 @@
static const char * const sensor_unit_s[SENSOR_MAX_TYPES + 1] = {
"degC", "RPM", "V DC", "V AC", "Ohm", "W", "A", "Wh", "Ah",
"", "", "%", "lx", "", "sec", "%RH", "Hz", "degree",
- "mm", "Pa", "m/s^2", ""
+ "mm", "Pa", "m/s^2", "m", "m/s", ""
};
const char *
@@ -2659,6 +2659,8 @@
ret = asprintf(, "%.2f", s->value / 1000.0);
break;
case SENSOR_DISTANCE:
+ case SENSOR_ALTITUDE:
+ case SENSOR_SPEED:
case SENSOR_PRESSURE:
ret = asprintf(, "%.2f", s->value / 1000.0);
break;
Index: usr.sbin/sensorsd/sensorsd.c
===
RCS file: /cvs/src/usr.sbin/sensorsd/sensorsd.c,v
retrieving revision 1.62
diff -u -r1.62 sensorsd.c
--- usr.sbin/sensorsd/sensorsd.c22 Oct 2018 16:20:09 - 1.62
+++ usr.sbin/sensorsd/sensorsd.c3 Nov 2018 16:24:01 -
@@ -700,6 +700,12 @@
case SENSOR_ACCEL:
snprintf(fbuf, RFBUFSIZ, "%2.4f m/s^2", value / 100.0);
break;
+ case SENSOR_ALTITUDE:
+ snprintf(fbuf, RFBUFSIZ, "%4.3f m", value / 1000.0);
+ break;
+ case SENSOR_SPEED:
+ snprintf(fbuf, RFBUFSIZ, "%4.3f m/s", value / 1000.0);
+ break;
default:
snprintf(fbuf, RFBUFSIZ, "%lld ???", value);
}
@@ -821,6 +827,8 @@
case SENSOR_HUMIDITY:
case SENSOR_DISTANCE:
case SENSOR_PRESSURE:
+ case SENSOR_ALTITUDE:
+ case SENSOR_SPEED:
rval = val * 1000.0;
break;
default:
Index: sbin/sysctl/sysctl.c
===
RCS file: /cvs/src/sbin/sysctl/sysctl.c,v
retrieving revision 1.237
diff -u -r1.237 sysctl.c
--- sbin/sysctl/sysctl.c29 Sep 2018 04:29:48 - 1.237
+++ sbin/sysctl/sysctl.c3 Nov 2018 16:24:02 -
@@ -2661,6 +2661,12 @@
case SENSOR_ACCEL:
printf("%2.4f m/s^2", s->value / 100.0);
break;
+ case SENSOR_ALTITUDE:
+ printf("%4.3f m", s->value / 1000.0);
+ break;
+ case SENSOR_SPEED:
+ printf("%4.3f m/s", s->value / 1000.0);
+ break;
default:
printf("unknown");
}
Index: usr.bin/systat/sensors.c
===
RCS file: /cvs/src/usr.bin/systat/sensors.c,v
retrieving revision 1.30
diff -u -r1.30 sensors.c
--- usr.bin/systat/sensors.c16 Jan 2015 00:03:38 - 1.30
+++ usr.bin/systat/sensors.c3 Nov 2018 16:24:02 -
@@ -288,6 +288,12 @@
case SENSOR_ACCEL:
tbprintf("%2.4f m/s^2", s->sn_value / 100.0);
break;
+ case SENSOR_ALTITUDE:
+ tbprintf("%4.3f m", s->sn_value / 1000.0);
+ break;
+ case SENSOR_SPEED:
+ tbprintf("%4.3f m/s", s->sn_value / 1000.0);
+ break;
default:
tbprintf("%10lld", s->sn_value);
NMEA: add more gps sensor values (altitude, precision...)
Hi,
here's a diff to add 5 new sensor values to nmea: altitude, quality,
hdop, vdop & pdop. altitude and quality are provided by GGA messages:
http://aprs.gids.nl/nmea/#gga, quality is either 0 (no fix), 1 (gps fix)
or 2 (dgps fix).
The last 3 are 'Dilution of precision' values, respectively horizontal,
vertical & positional (ie 3d), cf
https://en.wikipedia.org/wiki/Dilution_of_precision_(navigation) &
http://www.trakgps.com/en/index.php/information/gps-articles-information/65-gps-accuracy
and are provided by GSA messages: http://aprs.gids.nl/nmea/#gsa it is
generally considered good precision when the DOP is below 2, so i've set
the sensor status warning accordingly.
this provides for example (angle values hidden for 'privacy', just after
the gps got a fix):
nmea0.indicator0 OnOKSignal
nmea0.raw0 1 rawOKGPS fix
nmea0.raw1 1920 rawOKHDOP
nmea0.raw2 2520 raw WARNING VDOP
nmea0.raw3 3170 raw WARNING PDOP
nmea0.timedelta024.867 msOKGPS autonomous
nmea0.angle0 xx. degreesOKLatitude
nmea0.angle1 z. degreesOKLongitude
nmea0.distance0 371.50 mmOKAltitude
and after a while, when precision improved:
nmea0.indicator0 OnOKSignal
nmea0.raw0 1 rawOKGPS fix
nmea0.raw1800 rawOKHDOP
nmea0.raw2 1300 rawOKVDOP
nmea0.raw3 1530 rawOKPDOP
nmea0.timedelta0 -296.499 msOKGPS autonomous
nmea0.angle0 xx. degreesOKLatitude
nmea0.angle1 z. degreesOKLongitude
nmea0.distance0 355.50 mmOKAltitude
two problems with this display:
- DOPs are usually decimal values, ie 1.3, 1.53.. but raw sensors only
support integers, hence *1000.
- GGA messages provide altitude as '355.5' in meters (i *think* the unit
is fixed in the protocol, because altitude in feets is provided by
PGRMZ) - and we only have a SENSOR_DISTANCE type in mm (which doesnt
seem used by any driver..). Thus altitude shown in milimeters..
This sensor types were added in
https://github.com/openbsd/src/commit/d95200b806051887b8c69294833e22dad6302828
but no driver apparently makes use of it.
>From that point, questions:
- should i add more 'interesting' sensor values, like amount of satellites
seen/used ?
- i want to add speed value (as RMC has it in knots?, and VTG in various
units, per http://aprs.gids.nl/nmea/#vtg), but we only have
SENSOR_ACCEL type in m.s-2 (which is only used by asmc(4)). Should we
add a 'speed' sensor type ? in m/s ? in km/h ? knots ?
- should i add a SENSOR_ALTITUDE type in meters ?
- is there any interest in all this, from the sensors framework POV ?
Otherwise i can leave it as is and just use gpsd in userspace, which
works 100% fine...
All this done with an
umodem0 at uhub1 port 1 configuration 1 interface 0 "u-blox AG - www.u-blox.com
u-blox GNSS receiver" rev 1.10/2.01 addr 3
which works fine with ldattach & gpsd, ie i run doas gpsd -N -D2 $(doas
ldattach -p nmea /dev/cuaU0) and gpsmon shows me the msgs received by
the device, sent to the kernel via ldattach, and forwarded to gpsd.
comments welcome, diff not to be commited as is of course (nmea_atoi is
*horrible*, i know..)
Landry
Index: tty_nmea.c
===
RCS file: /cvs/src/sys/kern/tty_nmea.c,v
retrieving revision 1.47
diff -u -r1.47 tty_nmea.c
--- tty_nmea.c 1 Sep 2018 06:09:26 - 1.47
+++ tty_nmea.c 3 Nov 2018 15:28:11 -
@@ -29,6 +29,11 @@
#ifdef NMEA_DEBUG
#define DPRINTFN(n, x) do { if (nmeadebug > (n)) printf x; } while (0)
int nmeadebug = 0;
+/*
+ * 1 = print interesting messages
+ * 2 = print all messages
+int nmeadebug = 2;
+ */
#else
#define DPRINTFN(n, x)
#endif
@@ -52,6 +57,11 @@
struct ksensor signal; /* signal status */
struct ksensor latitude;
struct ksensor longitude;
+ struct ksensor altitude;
+ struct ksensor quality;
+ struct ksensor hdop;
+ struct ksensor vdop;
+ struct ksensor pdop;
struct ksensordev timedev;
struct timespec ts; /* current timestamp */
struct timespec lts;/* timestamp of last '$' seen */
@@ -70,6 +80,8 @@
/* NMEA decoding */
void nmea_scan(struct nmea *, struct tty *);
void nmea_gprmc(struct nmea *, struct tty *, char *fld[], int fldcnt);
+void
Remove debug options in hppa GENERIC
The hppa GENERIC kernel contains various debug options for pcmcia and cardbus code. None of the other platforms enables these options in GENERIC. Index: sys/arch/hppa/conf/GENERIC === RCS file: /OpenBSD/src/sys/arch/hppa/conf/GENERIC,v retrieving revision 1.177 diff -u -p -u -p -r1.177 GENERIC --- sys/arch/hppa/conf/GENERIC 22 Aug 2018 15:38:46 - 1.177 +++ sys/arch/hppa/conf/GENERIC 3 Nov 2018 13:54:34 - @@ -78,9 +78,8 @@ lpt0 at ssio? # CardBus bus support cbb* at pci? cardslot* at cbb? -option CARDBUS_DEBUG,CARDSLOT_DEBUG,CARDBUS_MAP_DEBUG cardbus* at cardslot? -option PCMCIADEBUG,PCMCIAVERBOSE +option PCMCIAVERBOSE pcmcia*at cardslot? # PCI USB Controllers
Re: pledge xenodm
this is actually good, I made it as minimal as possible so that it
wouldn't break for me, if it breaks for you we can start from there.
On 13:41 Sat 03 Nov , Matthieu Herrb wrote:
> On Fri, Nov 02, 2018 at 07:03:11PM +, Ricardo Mestre wrote:
> > Hi,
> >
> > Looking at pledging xenodm a little bit more I was able to run it with
> > the diff below across X restarts, with stock configuration.
> >
> > Please test it, if you have special configs better since most likely
> > this will break it but we need to know where and why and with that maybe
> > trim xenodm's bloat.
>
> Hi,
>
> xenodm crashes if one logs out from the first session that was
> created. the pldege() call in StartDisplay is too strict.
>
> I've not had time to fully figure out if this can be fixed. Iirc I
> tried when I did the initial work on adding pledge to xenodm and it's
> not possible because of the code that creates the auth cookie and
> chown()s it to _x11.
>
> I didn't have time yet to do a more serious testing of the session
> pledge.
>
> >
> > DisplayManager:
> > rpath: open(2) /etc/X11/xenodm/xenodm-config
> > cpath: unlink(2) d->authFile
> > proc: kill(2)
> >
> > Session:
> > rpath: open(2) /etc/fbtab
> > wpath/cpath: open(2) d->authFile
> > fattr: chmod(2) d->authFile
> > dns: sysctl(2) for name resolution
> > proc: kill(2)
> > exec: execve(2) /etc/X11/xenodm/TakeConsole
> > id: setuid(2)
> >
> > Index: dm.c
> > ===
> > RCS file: /cvs/xenocara/app/xenodm/xenodm/dm.c,v
> > retrieving revision 1.6
> > diff -u -p -u -r1.6 dm.c
> > --- dm.c11 Jul 2018 16:57:04 - 1.6
> > +++ dm.c31 Oct 2018 15:15:49 -
> > @@ -604,6 +604,10 @@ StartDisplay (struct display *d)
> > Debug ("pid: %d\n", pid);
> > d->pid = pid;
> > d->status = running;
> > +
> > + if (pledge("stdio rpath cpath proc", NULL) == -1)
> > + exit(OPENFAILED_DISPLAY);
> > +
> > break;
> > }
> > }
> > Index: session.c
> > ===
> > RCS file: /cvs/xenocara/app/xenodm/xenodm/session.c,v
> > retrieving revision 1.12
> > diff -u -p -u -r1.12 session.c
> > --- session.c 11 Jul 2018 20:28:41 - 1.12
> > +++ session.c 31 Oct 2018 15:15:49 -
> > @@ -378,6 +378,10 @@ StartClient (
> > default:
> > Debug ("StartSession, fork succeeded %d\n", pid);
> > *pidp = pid;
> > +
> > + if (pledge("stdio rpath wpath cpath fattr dns proc exec id", NULL) ==
> > -1)
> > + exit(25);
> > +
> > return 1;
> > }
> > }
> >
> > - End forwarded message -
>
> --
> Matthieu Herrb
>
Re: bgpd, Adj-RIB-Out support
On Wed, Oct 31, 2018 at 09:02:16PM +0100, Denis Fondras wrote:
> On Wed, Oct 31, 2018 at 04:24:49PM +0100, Claudio Jeker wrote:
> > This diff introduces a real Adj-RIB-Out. It is the minimal change to
> > introduce the new RIB. This removes the update_rib introduced before 6.4
> > lock because that is now replaced with a real RIB.
> > The code used by bgpctl show rib is now a fair amount easier since now one
> > RIB runner can be used for all cases.
> > path_update() is now returning if a prefix was not modified which is
> > needed in the update path to suppress unneeded updates.
> > The softreconfig out case becomes simpler because there is no more the
> > need to run with both filters and check results.
> > Last the shutdown code of the RDE had to be adjusted a bit to still work
> > with the Adj-RIB-Out.
> >
> > This may cause memory consumption to go up but my testing has shown that
> > the result is actually not significant. Needs the commits from earlier
> > today to apply.
>
[zip]
> I need to test it on a router with a fullview.
>
OK denis@
> Comments below.
>
> > --
> > :wq Claudio
> >
> > Index: rde.c
> > ===
> > RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
> > retrieving revision 1.444
> > diff -u -p -r1.444 rde.c
> > --- rde.c 31 Oct 2018 14:50:07 - 1.444
> > +++ rde.c 31 Oct 2018 15:09:39 -
> > @@ -1395,7 +1395,7 @@ rde_update_update(struct rde_peer *peer,
> >
> > /* add original path to the Adj-RIB-In */
> > if (path_update([RIB_ADJ_IN].rib, peer, in, prefix, prefixlen,
> > - vstate))
> > + vstate) == 1)
> > peer->prefix_cnt++;
> >
> > /* max prefix checker */
> > @@ -2124,16 +2124,17 @@ rde_reflector(struct rde_peer *peer, str
> > * control specific functions
> > */
> > static void
> > -rde_dump_rib_as(struct prefix *p, struct rde_aspath *asp,
> > -struct nexthop *nexthop, pid_t pid, int flags)
> > +rde_dump_rib_as(struct prefix *p, struct rde_aspath *asp, pid_t pid, int
> > flags)
> > {
> > struct ctl_show_rib rib;
> > struct ibuf *wbuf;
> > struct attr *a;
> > + struct nexthop *nexthop;
> > void*bp;
> > time_t staletime;
> > u_int8_t l;
> >
> > + nexthop = prefix_nexthop(p);
> > bzero(, sizeof(rib));
> > rib.lastchange = p->lastchange;
> > rib.local_pref = asp->lpref;
> > @@ -2208,70 +2209,37 @@ rde_dump_rib_as(struct prefix *p, struct
> > }
> >
> > static void
> > -rde_dump_filterout(struct rde_peer *peer, struct prefix *p,
> > -struct ctl_show_rib_request *req)
> > -{
> > - struct filterstate state;
> > - enum filter_actions a;
> > -
> > - if (up_test_update(peer, p) != 1)
> > - return;
> > -
> > - rde_filterstate_prep(, prefix_aspath(p), prefix_nexthop(p),
> > - prefix_nhflags(p));
> > - a = rde_filter(out_rules, peer, p, );
> > -
> > - if (a == ACTION_ALLOW)
> > - rde_dump_rib_as(p, , state.nexthop, req->pid,
> > - req->flags);
> > -
> > - rde_filterstate_clean();
> > -}
> > -
> > -static void
> > rde_dump_filter(struct prefix *p, struct ctl_show_rib_request *req)
> > {
> > - struct rde_peer *peer;
> > struct rde_aspath *asp;
> >
> > - if (req->flags & F_CTL_ADJ_OUT) {
> > - if (p->re->active != p)
> > - /* only consider active prefix */
> > - return;
> > - if (req->peerid) {
> > - if ((peer = peer_get(req->peerid)) != NULL)
> > - rde_dump_filterout(peer, p, req);
> > - return;
> > - }
> > - } else {
> > - asp = prefix_aspath(p);
> > - if (req->peerid && req->peerid != prefix_peer(p)->conf.id)
> > - return;
> > - if ((req->flags & F_CTL_ACTIVE) && p->re->active != p)
> > - return;
> > - if ((req->flags & F_CTL_INVALID) &&
> > - (asp->flags & F_ATTR_PARSE_ERR) == 0)
> > - return;
> > - if (req->type == IMSG_CTL_SHOW_RIB_AS &&
> > - !aspath_match(asp->aspath->data, asp->aspath->len,
> > - >as, 0))
> > - return;
> > - if (req->type == IMSG_CTL_SHOW_RIB_COMMUNITY &&
> > - !community_match(asp, req->community.as,
> > - req->community.type))
> > - return;
> > - if (req->type == IMSG_CTL_SHOW_RIB_EXTCOMMUNITY &&
> > - !community_ext_match(asp, >extcommunity, 0))
> > - return;
> > - if (req->type == IMSG_CTL_SHOW_RIB_LARGECOMMUNITY &&
> > - !community_large_match(asp, req->large_community.as,
> > - req->large_community.ld1, req->large_community.ld2))
> > - return;
> > - if
Patch to support AR816x/AR817x chipsets in alc(4)
Hi all,
I'm piggybacking on post from Jason Hunt
https://marc.info/?l=openbsd-tech=146881042926430=2
Please find attached diff for alc(4) synced with FreeBSD alc(4).
In addition to original diff this one adds support to E2200, E2400
and E2500 cards made by Attansic. I am running it for around a month
with E2400 model I have in my laptop without any issues.
If that's OK, would be great to have it merged.
$ dmesg | grep alc
alc0 at pci5 dev 0 function 0 "Attansic Technology Killer E2400 Gigabit
Ethernet" rev 0x10: msi, address d4:81:d7:8a:01:27
atphy0 at alc0 phy 0: AR8035 10/100/1000 PHY, rev. 9
diff --git a/sys/dev/pci/if_alc.c b/sys/dev/pci/if_alc.c
index 7b5e628ef..958146053 100644
--- a/sys/dev/pci/if_alc.c
+++ b/sys/dev/pci/if_alc.c
@@ -26,7 +26,7 @@
* SUCH DAMAGE.
*/
-/* Driver for Atheros AR8131/AR8132 PCIe Ethernet. */
+/* Driver for Atheros AR813x/AR815x/AR816x/AR817x PCIe Ethernet. */
#include "bpfilter.h"
#include "vlan.h"
@@ -76,12 +76,17 @@ voidalc_watchdog(struct ifnet *);
intalc_mediachange(struct ifnet *);
void alc_mediastatus(struct ifnet *, struct ifmediareq *);
-void alc_aspm(struct alc_softc *, uint64_t);
+void alc_aspm(struct alc_softc *, int, uint64_t);
+void alc_aspm_813x(struct alc_softc *, uint64_t);
+void alc_aspm_816x(struct alc_softc *, int);
void alc_disable_l0s_l1(struct alc_softc *);
intalc_dma_alloc(struct alc_softc *);
void alc_dma_free(struct alc_softc *);
intalc_encap(struct alc_softc *, struct mbuf *);
void alc_get_macaddr(struct alc_softc *);
+void alc_get_macaddr_813x(struct alc_softc *);
+void alc_get_macaddr_816x(struct alc_softc *);
+void alc_get_macaddr_par(struct alc_softc *);
void alc_init_cmb(struct alc_softc *);
void alc_init_rr_ring(struct alc_softc *);
intalc_init_rx_ring(struct alc_softc *);
@@ -89,9 +94,23 @@ void alc_init_smb(struct alc_softc *);
void alc_init_tx_ring(struct alc_softc *);
intalc_intr(void *);
void alc_mac_config(struct alc_softc *);
+uint32_t alc_mii_readreg_813x(struct alc_softc *, int, int);
+uint32_t alc_mii_readreg_816x(struct alc_softc *, int, int);
+uint32_t alc_mii_writereg_813x(struct alc_softc *, int, int, int);
+uint32_t alc_mii_writereg_816x(struct alc_softc *, int, int, int);
+void alc_dsp_fixup(struct alc_softc *, int);
intalc_miibus_readreg(struct device *, int, int);
void alc_miibus_statchg(struct device *);
+intalc_miibus_writeregr(struct device *, int, int, int);
void alc_miibus_writereg(struct device *, int, int, int);
+uint32_t alc_miidbg_readreg(struct alc_softc *, int);
+uint32_t alc_miidbg_writereg(struct alc_softc *, int, int);
+uint32_t alc_miiext_readreg(struct alc_softc *, int, int);
+uint32_t alc_miiext_writereg(struct alc_softc *, int, int, int);
+void alc_phy_reset_813x(struct alc_softc *);
+void alc_phy_reset_816x(struct alc_softc *);
+void alc_setwol_813x(struct alc_softc *);
+void alc_setwol_816x(struct alc_softc *);
intalc_newbuf(struct alc_softc *, struct alc_rxdesc *);
void alc_phy_down(struct alc_softc *);
void alc_phy_reset(struct alc_softc *);
@@ -108,6 +127,12 @@ void alc_stop_mac(struct alc_softc *);
void alc_stop_queue(struct alc_softc *);
void alc_tick(void *);
void alc_txeof(struct alc_softc *);
+void alc_init_pcie(struct alc_softc *, int);
+void alc_config_msi(struct alc_softc *);
+intalc_dma_alloc(struct alc_softc *);
+void alc_dma_free(struct alc_softc *);
+intalc_encap(struct alc_softc *, struct mbuf *);
+void alc_osc_reset(struct alc_softc *);
uint32_t alc_dma_burst[] = { 128, 256, 512, 1024, 2048, 4096, 0 };
@@ -117,11 +142,18 @@ const struct pci_matchid alc_devices[] = {
{ PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_L1D },
{ PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_L1D_1 },
{ PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_L2C_1 },
- { PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_L2C_2 }
+ { PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_L2C_2 },
+ { PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_AR8161 },
+ { PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_AR8162 },
+ { PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_AR8171 },
+ { PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_AR8172 },
+ { PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_E2200 },
+ { PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_E2400 },
+ { PCI_VENDOR_ATTANSIC, PCI_PRODUCT_ATTANSIC_E2500 }
};
struct cfattach alc_ca = {
- sizeof (struct alc_softc), alc_match, alc_attach, NULL,
+ sizeof (struct alc_softc), alc_match, alc_attach, alc_detach,
alc_activate
};
@@ -138,6 +170,22 @@ int
alc_miibus_readreg(struct device *dev, int phy, int reg)
{
struct alc_softc *sc = (struct alc_softc *)dev;
+ uint32_t v = 0;
+
+ if (phy != sc->alc_phyaddr)
+ return (0);
+
+ if ((sc->alc_flags & ALC_FLAG_AR816X_FAMILY) != 0)
+ v
Re: pledge xenodm
On Fri, Nov 02, 2018 at 07:03:11PM +, Ricardo Mestre wrote:
> Hi,
>
> Looking at pledging xenodm a little bit more I was able to run it with
> the diff below across X restarts, with stock configuration.
>
> Please test it, if you have special configs better since most likely
> this will break it but we need to know where and why and with that maybe
> trim xenodm's bloat.
Hi,
xenodm crashes if one logs out from the first session that was
created. the pldege() call in StartDisplay is too strict.
I've not had time to fully figure out if this can be fixed. Iirc I
tried when I did the initial work on adding pledge to xenodm and it's
not possible because of the code that creates the auth cookie and
chown()s it to _x11.
I didn't have time yet to do a more serious testing of the session
pledge.
>
> DisplayManager:
> rpath: open(2) /etc/X11/xenodm/xenodm-config
> cpath: unlink(2) d->authFile
> proc: kill(2)
>
> Session:
> rpath: open(2) /etc/fbtab
> wpath/cpath: open(2) d->authFile
> fattr: chmod(2) d->authFile
> dns: sysctl(2) for name resolution
> proc: kill(2)
> exec: execve(2) /etc/X11/xenodm/TakeConsole
> id: setuid(2)
>
> Index: dm.c
> ===
> RCS file: /cvs/xenocara/app/xenodm/xenodm/dm.c,v
> retrieving revision 1.6
> diff -u -p -u -r1.6 dm.c
> --- dm.c 11 Jul 2018 16:57:04 - 1.6
> +++ dm.c 31 Oct 2018 15:15:49 -
> @@ -604,6 +604,10 @@ StartDisplay (struct display *d)
> Debug ("pid: %d\n", pid);
> d->pid = pid;
> d->status = running;
> +
> + if (pledge("stdio rpath cpath proc", NULL) == -1)
> + exit(OPENFAILED_DISPLAY);
> +
> break;
> }
> }
> Index: session.c
> ===
> RCS file: /cvs/xenocara/app/xenodm/xenodm/session.c,v
> retrieving revision 1.12
> diff -u -p -u -r1.12 session.c
> --- session.c 11 Jul 2018 20:28:41 - 1.12
> +++ session.c 31 Oct 2018 15:15:49 -
> @@ -378,6 +378,10 @@ StartClient (
> default:
> Debug ("StartSession, fork succeeded %d\n", pid);
> *pidp = pid;
> +
> + if (pledge("stdio rpath wpath cpath fattr dns proc exec id", NULL) ==
> -1)
> + exit(25);
> +
> return 1;
> }
> }
>
> - End forwarded message -
--
Matthieu Herrb
Re: pledge xenodm
prodded by deraadt@, here's a rebased diff on xenocara's source root directory,
usually /usr/xenocara.
Index: app/xenodm/xenodm/dm.c
===
RCS file: /cvs/xenocara/app/xenodm/xenodm/dm.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 dm.c
--- app/xenodm/xenodm/dm.c 11 Jul 2018 16:57:04 - 1.6
+++ app/xenodm/xenodm/dm.c 3 Nov 2018 11:10:06 -
@@ -604,6 +604,10 @@ StartDisplay (struct display *d)
Debug ("pid: %d\n", pid);
d->pid = pid;
d->status = running;
+
+ if (pledge("stdio rpath cpath proc", NULL) == -1)
+ exit(OPENFAILED_DISPLAY);
+
break;
}
}
Index: app/xenodm/xenodm/session.c
===
RCS file: /cvs/xenocara/app/xenodm/xenodm/session.c,v
retrieving revision 1.12
diff -u -p -u -r1.12 session.c
--- app/xenodm/xenodm/session.c 11 Jul 2018 20:28:41 - 1.12
+++ app/xenodm/xenodm/session.c 3 Nov 2018 11:10:06 -
@@ -378,6 +378,10 @@ StartClient (
default:
Debug ("StartSession, fork succeeded %d\n", pid);
*pidp = pid;
+
+ if (pledge("stdio rpath wpath cpath fattr dns proc exec id", NULL) ==
-1)
+ exit(25);
+
return 1;
}
}
Re: disable fs access on ripd
reads OK for me as well
On 10:28 Sat 03 Nov , Claudio Jeker wrote:
> On Sat, Nov 03, 2018 at 10:24:23AM +0100, Remi Locherer wrote:
> > On Tue, Oct 30, 2018 at 05:31:04PM +, Ricardo Mestre wrote:
> > > clearly an oversight due to looking at too many daemons at the same
> > > time. since the only thing ripd needs to do is unlink the socket I think
> > > we can remove control_cleanup, even though I'd rather do this
> > > introducing pledge, but for now it's a great compromise.
> > >
> >
> > In addition to your diff this pledges the rde and ripe.
> >
> > OK?
>
> Reads OK. Not sure about the ripe pledge but looking at ospfd I think it
> should be right. Can't test right now.
>
> > Index: control.c
> > ===
> > RCS file: /cvs/src/usr.sbin/ripd/control.c,v
> > retrieving revision 1.25
> > diff -u -p -r1.25 control.c
> > --- control.c 17 Jan 2017 22:10:56 - 1.25
> > +++ control.c 3 Nov 2018 09:11:39 -
> > @@ -100,14 +100,6 @@ control_listen(void)
> > return (0);
> > }
> >
> > -void
> > -control_cleanup(char *path)
> > -{
> > - event_del(_state.ev);
> > - event_del(_state.evt);
> > - unlink(path);
> > -}
> > -
> > /* ARGSUSED */
> > void
> > control_accept(int listenfd, short event, void *bula)
> > Index: control.h
> > ===
> > RCS file: /cvs/src/usr.sbin/ripd/control.h,v
> > retrieving revision 1.5
> > diff -u -p -r1.5 control.h
> > --- control.h 2 Aug 2016 16:05:32 - 1.5
> > +++ control.h 3 Nov 2018 09:11:20 -
> > @@ -39,6 +39,5 @@ int control_listen(void);
> > void control_accept(int, short, void *);
> > void control_dispatch_imsg(int, short, void *);
> > intcontrol_imsg_relay(struct imsg *);
> > -void control_cleanup(char *);
> >
> > #endif /* _CONTROL_H_ */
> > Index: rde.c
> > ===
> > RCS file: /cvs/src/usr.sbin/ripd/rde.c,v
> > retrieving revision 1.21
> > diff -u -p -r1.21 rde.c
> > --- rde.c 3 Sep 2016 10:28:08 - 1.21
> > +++ rde.c 3 Nov 2018 07:38:41 -
> > @@ -109,6 +109,9 @@ rde(struct ripd_conf *xconf, int pipe_pa
> > setresuid(pw->pw_uid, pw->pw_uid, pw->pw_uid))
> > fatal("can't drop privileges");
> >
> > + if (pledge("stdio", NULL) == -1)
> > + fatal("pledge");
> > +
> > event_init();
> >
> > /* setup signal handler */
> > Index: ripd.c
> > ===
> > RCS file: /cvs/src/usr.sbin/ripd/ripd.c,v
> > retrieving revision 1.30
> > diff -u -p -r1.30 ripd.c
> > --- ripd.c 3 Sep 2016 10:28:08 - 1.30
> > +++ ripd.c 3 Nov 2018 09:14:38 -
> > @@ -211,6 +211,11 @@ main(int argc, char *argv[])
> > rde_pid = rde(conf, pipe_parent2rde, pipe_ripe2rde, pipe_parent2ripe);
> > ripe_pid = ripe(conf, pipe_parent2ripe, pipe_ripe2rde, pipe_parent2rde);
> >
> > + if (unveil("/", "") == -1)
> > + fatal("unveil");
> > + if (unveil(NULL, NULL) == -1)
> > + fatal("unveil");
> > +
> > event_init();
> >
> > /* setup signal handler */
> > @@ -276,7 +281,6 @@ ripd_shutdown(void)
> > if_del(i);
> > }
> >
> > - control_cleanup(conf->csock);
> > kr_shutdown();
> >
> > log_debug("waiting for children to terminate");
> > Index: ripe.c
> > ===
> > RCS file: /cvs/src/usr.sbin/ripd/ripe.c,v
> > retrieving revision 1.22
> > diff -u -p -r1.22 ripe.c
> > --- ripe.c 3 Sep 2016 10:28:08 - 1.22
> > +++ ripe.c 3 Nov 2018 09:07:24 -
> > @@ -196,6 +196,9 @@ ripe(struct ripd_conf *xconf, int pipe_p
> > iface->name);
> > }
> >
> > + if (pledge("stdio inet mcast", NULL) == -1)
> > + fatal("pledge");
> > +
> > evtimer_set(>report_timer, report_timer, oeconf);
> > start_report_timer();
> >
>
> --
> :wq Claudio
Re: disable fs access on ripd
On Sat, Nov 03, 2018 at 10:24:23AM +0100, Remi Locherer wrote:
> On Tue, Oct 30, 2018 at 05:31:04PM +, Ricardo Mestre wrote:
> > clearly an oversight due to looking at too many daemons at the same
> > time. since the only thing ripd needs to do is unlink the socket I think
> > we can remove control_cleanup, even though I'd rather do this
> > introducing pledge, but for now it's a great compromise.
> >
>
> In addition to your diff this pledges the rde and ripe.
>
> OK?
Reads OK. Not sure about the ripe pledge but looking at ospfd I think it
should be right. Can't test right now.
> Index: control.c
> ===
> RCS file: /cvs/src/usr.sbin/ripd/control.c,v
> retrieving revision 1.25
> diff -u -p -r1.25 control.c
> --- control.c 17 Jan 2017 22:10:56 - 1.25
> +++ control.c 3 Nov 2018 09:11:39 -
> @@ -100,14 +100,6 @@ control_listen(void)
> return (0);
> }
>
> -void
> -control_cleanup(char *path)
> -{
> - event_del(_state.ev);
> - event_del(_state.evt);
> - unlink(path);
> -}
> -
> /* ARGSUSED */
> void
> control_accept(int listenfd, short event, void *bula)
> Index: control.h
> ===
> RCS file: /cvs/src/usr.sbin/ripd/control.h,v
> retrieving revision 1.5
> diff -u -p -r1.5 control.h
> --- control.h 2 Aug 2016 16:05:32 - 1.5
> +++ control.h 3 Nov 2018 09:11:20 -
> @@ -39,6 +39,5 @@ int control_listen(void);
> void control_accept(int, short, void *);
> void control_dispatch_imsg(int, short, void *);
> int control_imsg_relay(struct imsg *);
> -void control_cleanup(char *);
>
> #endif /* _CONTROL_H_ */
> Index: rde.c
> ===
> RCS file: /cvs/src/usr.sbin/ripd/rde.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 rde.c
> --- rde.c 3 Sep 2016 10:28:08 - 1.21
> +++ rde.c 3 Nov 2018 07:38:41 -
> @@ -109,6 +109,9 @@ rde(struct ripd_conf *xconf, int pipe_pa
> setresuid(pw->pw_uid, pw->pw_uid, pw->pw_uid))
> fatal("can't drop privileges");
>
> + if (pledge("stdio", NULL) == -1)
> + fatal("pledge");
> +
> event_init();
>
> /* setup signal handler */
> Index: ripd.c
> ===
> RCS file: /cvs/src/usr.sbin/ripd/ripd.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 ripd.c
> --- ripd.c3 Sep 2016 10:28:08 - 1.30
> +++ ripd.c3 Nov 2018 09:14:38 -
> @@ -211,6 +211,11 @@ main(int argc, char *argv[])
> rde_pid = rde(conf, pipe_parent2rde, pipe_ripe2rde, pipe_parent2ripe);
> ripe_pid = ripe(conf, pipe_parent2ripe, pipe_ripe2rde, pipe_parent2rde);
>
> + if (unveil("/", "") == -1)
> + fatal("unveil");
> + if (unveil(NULL, NULL) == -1)
> + fatal("unveil");
> +
> event_init();
>
> /* setup signal handler */
> @@ -276,7 +281,6 @@ ripd_shutdown(void)
> if_del(i);
> }
>
> - control_cleanup(conf->csock);
> kr_shutdown();
>
> log_debug("waiting for children to terminate");
> Index: ripe.c
> ===
> RCS file: /cvs/src/usr.sbin/ripd/ripe.c,v
> retrieving revision 1.22
> diff -u -p -r1.22 ripe.c
> --- ripe.c3 Sep 2016 10:28:08 - 1.22
> +++ ripe.c3 Nov 2018 09:07:24 -
> @@ -196,6 +196,9 @@ ripe(struct ripd_conf *xconf, int pipe_p
> iface->name);
> }
>
> + if (pledge("stdio inet mcast", NULL) == -1)
> + fatal("pledge");
> +
> evtimer_set(>report_timer, report_timer, oeconf);
> start_report_timer();
>
--
:wq Claudio
Re: disable fs access on ripd
On Tue, Oct 30, 2018 at 05:31:04PM +, Ricardo Mestre wrote:
> clearly an oversight due to looking at too many daemons at the same
> time. since the only thing ripd needs to do is unlink the socket I think
> we can remove control_cleanup, even though I'd rather do this
> introducing pledge, but for now it's a great compromise.
>
In addition to your diff this pledges the rde and ripe.
OK?
Index: control.c
===
RCS file: /cvs/src/usr.sbin/ripd/control.c,v
retrieving revision 1.25
diff -u -p -r1.25 control.c
--- control.c 17 Jan 2017 22:10:56 - 1.25
+++ control.c 3 Nov 2018 09:11:39 -
@@ -100,14 +100,6 @@ control_listen(void)
return (0);
}
-void
-control_cleanup(char *path)
-{
- event_del(_state.ev);
- event_del(_state.evt);
- unlink(path);
-}
-
/* ARGSUSED */
void
control_accept(int listenfd, short event, void *bula)
Index: control.h
===
RCS file: /cvs/src/usr.sbin/ripd/control.h,v
retrieving revision 1.5
diff -u -p -r1.5 control.h
--- control.h 2 Aug 2016 16:05:32 - 1.5
+++ control.h 3 Nov 2018 09:11:20 -
@@ -39,6 +39,5 @@ int control_listen(void);
void control_accept(int, short, void *);
void control_dispatch_imsg(int, short, void *);
intcontrol_imsg_relay(struct imsg *);
-void control_cleanup(char *);
#endif /* _CONTROL_H_ */
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/ripd/rde.c,v
retrieving revision 1.21
diff -u -p -r1.21 rde.c
--- rde.c 3 Sep 2016 10:28:08 - 1.21
+++ rde.c 3 Nov 2018 07:38:41 -
@@ -109,6 +109,9 @@ rde(struct ripd_conf *xconf, int pipe_pa
setresuid(pw->pw_uid, pw->pw_uid, pw->pw_uid))
fatal("can't drop privileges");
+ if (pledge("stdio", NULL) == -1)
+ fatal("pledge");
+
event_init();
/* setup signal handler */
Index: ripd.c
===
RCS file: /cvs/src/usr.sbin/ripd/ripd.c,v
retrieving revision 1.30
diff -u -p -r1.30 ripd.c
--- ripd.c 3 Sep 2016 10:28:08 - 1.30
+++ ripd.c 3 Nov 2018 09:14:38 -
@@ -211,6 +211,11 @@ main(int argc, char *argv[])
rde_pid = rde(conf, pipe_parent2rde, pipe_ripe2rde, pipe_parent2ripe);
ripe_pid = ripe(conf, pipe_parent2ripe, pipe_ripe2rde, pipe_parent2rde);
+ if (unveil("/", "") == -1)
+ fatal("unveil");
+ if (unveil(NULL, NULL) == -1)
+ fatal("unveil");
+
event_init();
/* setup signal handler */
@@ -276,7 +281,6 @@ ripd_shutdown(void)
if_del(i);
}
- control_cleanup(conf->csock);
kr_shutdown();
log_debug("waiting for children to terminate");
Index: ripe.c
===
RCS file: /cvs/src/usr.sbin/ripd/ripe.c,v
retrieving revision 1.22
diff -u -p -r1.22 ripe.c
--- ripe.c 3 Sep 2016 10:28:08 - 1.22
+++ ripe.c 3 Nov 2018 09:07:24 -
@@ -196,6 +196,9 @@ ripe(struct ripd_conf *xconf, int pipe_p
iface->name);
}
+ if (pledge("stdio inet mcast", NULL) == -1)
+ fatal("pledge");
+
evtimer_set(>report_timer, report_timer, oeconf);
start_report_timer();
