Re: Small binutils tweak
On Fri, Aug 23, 2013 at 10:40:22PM +0200, Landry Breuil wrote: > On Sun, Apr 21, 2013 at 10:42:09AM -0400, Brian Callahan wrote: > > On 04/21/13 03:21, Jonathan Gray wrote: > > >On Sat, Mar 02, 2013 at 10:36:50AM -0500, Brian Callahan wrote: > > >>Hi tech -- > > >> > > >>While doing some ports testing with clang, I came across the > > >>binutils bug mentioned here: > > >>http://lists.gnu.org/archive/html/bug-binutils/2004-07/msg0.html > > >> > > >>Below is a backport of the commit mentioned later in the thread. It > > >>fixes the issue. > > >>I was able to rebuild working kernels and do a full 'make build' on > > >>amd64, loongson, and macppc with this patch. But since it affects > > >>all archs, testing on the archs I don't have access to will be > > >>needed. > > >> > > >>OK? > > >This patch does not apply, it seems your mail client is wrapping lines. > > > > > > > > > > Below. Also attached as a tarball, in case Thunderbird really just hates me. > > > > miod told me about a month and a half ago to focus on moving to > > binutils-2.17 and not backport things to 2.15 so I never bothered to > > ping this. > > Bringing this back , since i'm facing issues with mozilla / icu linking > with ld/building with clang. In my limited testing, instead of the big > patch you were referring to, just using elflink.c r1.76 was enough to > fix my issue. > > See https://bugzilla.mozilla.org/show_bug.cgi?id=908080 for the whole > story, and > http://www.sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elflink.c.diff?cvsroot=src&r1=1.75&r2=1.76 > for the much smaller fix. > > Whatever was the reason for backing this out (iirc, xenocara blowed on > ppc), this needs to be reconsidered, since we're not going to move to > binutils 2.17 right now. I know it still breaks stuff subtly on powerpc, but i stumbled upon this again when trying to build mozilla trunk on i386 with clang. If we still want to build next firefoxes (26 or 27, dont remember) with clang, something has to move around this. Landry
Re: tedu old PKG_PREFIX
On Tue, Dec 31, 2013 at 01:19:32PM +0100, Marc Espie wrote: > I think I put this in for compatibility with the old tools years ago. > I don't think anyone still uses this, so this can probably die. > > (I have run a grep thru the ports tree and the man pages, no reference at all) > > okay ? I think i sent you a very similar diff years ago that got forgotten, so obviously ok. Landry
Re: panic: __mp_lock_held(&sched_lock) 2013-DEC-27 snapshot
On Tue, Jan 28, 2014 at 09:02:31PM -0800, Philip Guenther wrote: > On Tue, Jan 28, 2014 at 4:55 PM, patrick keshishian > wrote: > > > Side note 2: > > I see gdb crash quite often on subsequent run of app being > > debugged. I've noticed this on a bunch of snapshots dating > > some months back. Never reported it cause, I don't have a > > simple test-case to submit, and things have been moving > > fast with what you guys are doing. > > gdb has had many bugs in the past. Many are fixed in versions newer > than the version that are shipped with OpenBSD, but licensing keeps us > from including them in general. :-/ Anyone care to hack on gdb (no > copying GPLv3 source!)? Note that a recent gdb is available in ports, devel/gdb which installs the binary as egdb. Maybe it doesnt know/have tweaks for all our specificities, but it's there. For having tried it on firefox, it didnt fare much better than the base one.. Landry
Re: release(8) patch
On Wed, Feb 12, 2014 at 08:47:29AM +, Stuart Henderson wrote: > On 2014/02/12 08:16, Mark Kettenis wrote: > > Just make sure you set $ARCH in your .profile. > > I used to do that, but it can cause some confusion when working > on the ports tree. yes, i ran with $ARCH set for a while, and this caused all kind of funky side effects when building stuff. Since then i've use $MYARCH... Landry
Re: SQLite 3.8.3.1
On Sun, Feb 16, 2014 at 06:01:43PM -0500, James Turner wrote: > The attached diff updates the in-tree version of SQLite to 3.8.3.1. This > is of course for after unlock but for those interested feel free to > start giving it a try. > > Tested on amd64 and loongson with a small selection of ports. Fwiw, this has been tested on macppc/sparc64/amd64 with firefox 28.0betas, and also went in a bulk build on amd64 without fallout, with -DSQLITE_ENABLE_FTS3_PARENTHESIS added to FEATURE_FLAGS as proposed by okan@. So please get this in as soon as the tree fully unlocks.. Landry
Re: assembler fix
On Mon, Feb 17, 2014 at 12:02:15AM -0800, Philip Guenther wrote: > On Sun, Feb 16, 2014 at 2:57 AM, Mark Kettenis > wrote: > > This adds support for a few more instruction patterns that are > > apparentl needed by gcc 4.8. Taken from binutils 2.17. Not sure if > > adding NoRex64 to the existing patterns is really necessary, but it > > shouldn't hurt. > > This arose because AMD screwed up and specifed "movd" instead of > "movq" for the "mov r/m64 mm" opcodes, right? If we're going to pull > in the movq changes from binutils 2.17, I think we should pull in the > matching movd changes (including that wonderful comment). > > Looks like even binutils 2.17's disassembler shows this as movd > instead of movq. They must have changed that later. Darn. What has happened to this diff ? It is required to fix the build of the upcoming version of webkit, which requires gcc 4.8 Landry
Re: heads-up: your ports *will break*
On Tue, Apr 08, 2014 at 03:33:52PM +0200, Marc Espie wrote: > Got fed up of the nth report "flavors are broken". > > The cause is always the same: for packages to build correctly, your setup > *must* propagate some env variables thru sudo during the fake/packaging stage. > > So, I finally added up a variable that's there just to trigger an error in > case your setup is not squeaky clean. > > Accordingly, be sure to integrate the latest sudoers modification (coming > to a snapshot + sysmerge near you soon), and you get a fairly explicit > clue from bsd.port.mk now... In practical terms, that means that to build ports as user, you _need_ to be in wsrc group. Or use SUDO=/usr/bin/sudo -E in mk.conf. Landry
Re: PATCH: acpibat - expose "capacity" as sensor
On Sat, May 17, 2014 at 06:32:10PM +0200, Fabian Raetz wrote: > Hi, > > i want to expose "capacity" (full capacity design) > as a sensor like the rest. > > This sensor will be used in an upcoming diff to upower to > expose "energy-full-design" and "capacity" properties if > this patch gets merged. > > Both patches together will fix wrong notifications about > broken batteries in KDE4. Interesting - i've done a similar thing in the past to enable the 'lid open' sysctl status, so i'd welcome this kind of patch. Can you also show the diff for upower, and exactly what it fixes for KDE4 ? For example, the difference in upower -d output with and without that patch ? What's the exact difference between energy-full-design and capacity for upower ? Landry
Re: PATCH: acpibat - expose "capacity" as sensor
On Sun, May 18, 2014 at 08:56:15AM +0200, Landry Breuil wrote: > On Sat, May 17, 2014 at 06:32:10PM +0200, Fabian Raetz wrote: > > Hi, > > > > i want to expose "capacity" (full capacity design) > > as a sensor like the rest. > > > > This sensor will be used in an upcoming diff to upower to > > expose "energy-full-design" and "capacity" properties if > > this patch gets merged. > > > > Both patches together will fix wrong notifications about > > broken batteries in KDE4. > > Interesting - i've done a similar thing in the past to enable the 'lid > open' sysctl status, so i'd welcome this kind of patch. Can you also > show the diff for upower, and exactly what it fixes for KDE4 ? For > example, the difference in upower -d output with and without that patch > ? What's the exact difference between energy-full-design and capacity > for upower ? i've successfully tested this on i386 (5 years old msi wind U100 netbook) and amd64 (x200s), with sensors and the upower patch, and i think this provides valuable information on the device status. Mike, Mark, can you have a look at it ? I'd okay this but that's not my area. amd64: hw.sensors.acpibtn0.indicator0=On (lid open) hw.sensors.acpibat0.power0=19.28 W (rate) hw.sensors.acpibat0.watthour0=64.07 Wh (last full capacity) hw.sensors.acpibat0.watthour1=3.20 Wh (warning capacity) hw.sensors.acpibat0.watthour2=0.20 Wh (low capacity) hw.sensors.acpibat0.watthour3=59.04 Wh (remaining capacity), OK hw.sensors.acpibat0.watthour4=84.24 Wh (capacity) hw.sensors.acpibat0.raw0=2 (battery charging), OK hw.sensors.acpiac0.indicator0=On (power supply) (upower -d) energy: 61.06 Wh energy-empty:0.2 Wh energy-full: 64.07 Wh energy-full-design: 84.24 Wh energy-rate: 16.273 W voltage: 12.48 V percentage: 95% capacity:76.0565% i386: hw.sensors.acpiac0.indicator0=On (power supply) hw.sensors.acpibat0.current0=0.56 A (rate) hw.sensors.acpibat0.amphour0=2.03 Ah (last full capacity) hw.sensors.acpibat0.amphour1=0.00 Ah (warning capacity) hw.sensors.acpibat0.amphour2=0.00 Ah (low capacity) hw.sensors.acpibat0.amphour3=1.71 Ah (remaining capacity), OK hw.sensors.acpibat0.amphour4=4.40 Ah (capacity) hw.sensors.acpibat0.raw0=2 (battery charging), OK hw.sensors.acpibtn0.indicator0=On (lid open) (upower -d) state: fully-charged warning-level: none energy: 25.335 Wh energy-empty:0 Wh energy-full: 25.3599 Wh energy-full-design: 54.8592 Wh energy-rate: 0 W voltage: 12.468 V percentage: 99% capacity:46.2273%
Re: PATCH: acpibat - expose "capacity" as sensor
On Tue, May 20, 2014 at 01:19:44PM +0400, Vadim Zhukov wrote:
> 17.05.2014 20:32 "Fabian Raetz"
>
> ??:
> >
> > Hi,
> >
> > i want to expose "capacity" (full capacity design)
> > as a sensor like the rest.
> >
> > This sensor will be used in an upcoming diff to upower to
> > expose "energy-full-design" and "capacity" properties if
> > this patch gets merged.
> >
> > Both patches together will fix wrong notifications about
> > broken batteries in KDE4.
> >
> > Cheers,
> > Fabian
> >
> >
> > Index: acpidev.h
> > ===
> > RCS file: /cvs/src/sys/dev/acpi/acpidev.h,v
> > retrieving revision 1.33
> > diff -u -p -r1.33 acpidev.h
> > --- acpidev.h 13 Jul 2012 10:37:40 - 1.33
> > +++ acpidev.h 17 May 2014 15:51:29 -
> > @@ -278,7 +278,7 @@ struct acpibat_softc {
> > struct acpibat_bst sc_bst;
> > volatile intsc_bat_present;
> >
> > - struct ksensor sc_sens[8];
> > + struct ksensor sc_sens[9];
> > struct ksensordev sc_sensdev;
> > };
> >
> > Index: acpibat.c
> > ===
> > RCS file: /cvs/src/sys/dev/acpi/acpibat.c,v
> > retrieving revision 1.59
> > diff -u -p -r1.59 acpibat.c
> > --- acpibat.c 16 Oct 2011 11:59:21 - 1.59
> > +++ acpibat.c 17 May 2014 15:51:29 -
> > @@ -163,6 +163,12 @@ acpibat_monitor(struct acpibat_softc *sc
> > sensor_attach(&sc->sc_sensdev, &sc->sc_sens[7]);
> > sc->sc_sens[7].value = sc->sc_bst.bst_voltage * 1000;
> >
> > + strlcpy(sc->sc_sens[8].desc, "capacity",
> > + sizeof(sc->sc_sens[8].desc));
> > + sc->sc_sens[8].type = type;
> > + sensor_attach(&sc->sc_sensdev, &sc->sc_sens[8]);
> > + sc->sc_sens[8].value = sc->sc_bif.bif_capacity * 1000;
>
> It looks like a missing check for BIF_UNKNOWN, like in acpibat_refresh().
> Otherwise okay zhuk@.
If you look at the surrounding code in acpibat_monitor(), none of the
assignments check for *UNKNOWN values, so i dont think we should bother.
I agree that 'design capacity' might be better than "capacity" too..
todd, can you put this in snaps so that we know if there's some fallout
?
Landry
Re: lynx: disable old protocols
On Sat, Jul 12, 2014 at 06:11:16AM -0500, Shawn K. Quinn wrote: > On Fri, 2014-07-11 at 03:03 -0600, Theo de Raadt wrote: > > If lynx was removed from base, and only available in ports... how many of > > you would even know of it's existance and use it? > > Not only would I know of its existence and go install it to use, I would > wonder out loud why the hell it's not in base. > > Furthermore, if it had been intentionally crippled to exclude rare but > definitely used protocols like gopher that are part of "stock" Lynx as > released by the current maintainers, I would wonder what kind of whacked > out hallucinogenics someone had to have been on to do such a thing. > (It's something I'd expect from Firefox developers, but definitely not > from OpenBSD maintaners.) Beware with such statements, some have both hats. Landry
Re: audioctl: drop useless fields
On Thu, Sep 11, 2014 at 11:54:08AM +0200, Alexander Hall wrote: > On 09/11/14 09:58, Alexandre Ratchov wrote: > >On Wed, Sep 10, 2014 at 07:31:17PM +0200, Alexandre Ratchov wrote: > >>audioctl output is full of useless, misleading and/or unreliable > >>fields. Let's keep the usable ones only. The plan is to remove them > >>from the kernel as well. > >> > >>OK? > > > >I've been asked in private to explain the reason I think these > >fields are useless/misleading, see comments inlined below. > > I love it. Now, when is mixerctl becoming grokable? ;-) Just use audio/cmixer :p Landry
Re: update: sqlite-3.8.6
On Mon, Sep 15, 2014 at 09:17:27AM -0400, James Turner wrote: > Attached you will find a diff that updates SQLite to the latest 3.8.6. > Tested on amd64 with the fossil port. landry@ is going to see if he can > get it in a bulk but other testing is also helpful. Thanks. Went into an amd64 bulk build without fallout, thanks for the update! Landry
Re: [PATCH] Option for mount_tmpfs to populate the volume after creation.
On Thu, Sep 18, 2014 at 08:40:44AM +0100, bytevolc...@safe-mail.net wrote:
> This patch adds an option "-t template" to mount_tmpfs, which
> populates the new tmpfs volume with a directory
> immediately after creation.
>
> Man page update included for explanation.
>
> Much of the code was grafted from newfs
> which implements this for mount_mfs ("-P" option).
>
> Suggestions, fixes, criticism, etc. welcome.
In the mount_tmpfs.8 diff, you talk about mfs... :)
Landry
Re: update: sqlite-3.8.6
On Tue, Sep 16, 2014 at 06:34:37PM +0200, Landry Breuil wrote: > On Mon, Sep 15, 2014 at 09:17:27AM -0400, James Turner wrote: > > Attached you will find a diff that updates SQLite to the latest 3.8.6. > > Tested on amd64 with the fossil port. landry@ is going to see if he can > > get it in a bulk but other testing is also helpful. Thanks. > > Went into an amd64 bulk build without fallout, thanks for the update! Did anyone had a look at this ? This will be needed if at some point we want firefox 33. Landry
Re: armv7: banana pi, Allwinner A20 board
On Thu, Oct 02, 2014 at 10:01:59PM +, Alexey Suslikov wrote: > SASANO Takayoshi mx5.nisiq.net> writes: > > > > Try this[1] kernel and have a look if it has the same issue or not. > > > > Kernel did not started... U-Boot says checksum is ok, so maybe > > .umg file is not corrupted. > > When using > > OpenBSD 5.6 (RAMDISK-SUNXI) #3: Sun Aug 31 18:46:49 EDT 2014 > > could you drop into config (pass -c to boot) and try to "disable echi"? ITYM 'disable ehci' there.. Landry
Re: make release fails if SUDO is set in mk.conf
On Fri, Oct 24, 2014 at 02:34:54AM -0400, thev...@openmailbox.org wrote: > with SUDO set in /etc/mk.conf: > if make release is run as root it will not proceed. > if run as a regular user it gets further, but fails on permissions. > > without SUDO in /etc/mk.conf (and i presume the environment) it works fine. > > is there any way around this allowing /etc/mk.conf (which is useful for > ports)? > i can always move it temporarily, add it to my automated scripts, but is there > a better way? > > > $ cat /etc/mk.conf > SUDO=/usr/bin/sudo I think (and this is probably somewhere in the docs) you should use sudo -E. without it (and if you're not in wsrc) DESTDIR and RELEASEDIR are removed. check the default sudoers, and sudo manpage for details. Landry.
Re: make release fails if SUDO is set in mk.conf
On Fri, Oct 24, 2014 at 05:09:36AM -0400, thev...@openmailbox.org wrote: > On Fri, 24 Oct 2014 08:35:40 +0200 Landry Breuil > wrote: > > On Fri, Oct 24, 2014 at 02:34:54AM -0400, thev...@openmailbox.org wrote: > > > with SUDO set in /etc/mk.conf: > > > if make release is run as root it will not proceed. > > > if run as a regular user it gets further, but fails on permissions. > > > > > > without SUDO in /etc/mk.conf (and i presume the environment) it works > > > fine. > > > > > > is there any way around this allowing /etc/mk.conf (which is useful for > > > ports)? > > > i can always move it temporarily, add it to my automated scripts, but is > > > there > > > a better way? > > > > > > > > > $ cat /etc/mk.conf > > > SUDO=/usr/bin/sudo > > > > I think (and this is probably somewhere in the docs) you should use sudo -E. > > without it (and if you're not in wsrc) DESTDIR and RELEASEDIR are > > removed. check the default sudoers, and sudo manpage for details. > > > > Landry. > > > > if you are talking about this: > > $ sudo env DESTDIR=/usr/dst RELEASEDIR=/usr/release make release > exec /usr/bin/sudo make distribution-etc-root-var > setenv DESTDIR before doing that! > *** Error 1 in /usr/src/etc (Makefile:77 'distribution-etc-root-var': @false) > *** Error 1 in /usr/src/etc (Makefile:228 'distribution') > > that is the reason for this error, since root is not in group wsrc, and sudo > is getting invoked twice, once by me and then again by make. You're mixing stuff here. IF the user doing sudo is in wsrc, DESTDIR and RELEASEDIR should be passed through to the underlying process. and you shouldnt need two sudo invocations. export DESTDIR=/usr/dst export RELEASEDIR=/usr/release $make release (as user iirc, if you're in wsrc and use the default sudoers that's supposed to work. (btw, i never build releases, so i might be wrong) Landry
Re: libevent evutil.h
On Thu, Oct 30, 2014 at 08:14:35AM +, Nicholas Marriott wrote:
> I'd like to see evutil.h go so I'm happy with this idea but yes you will
> need to make sure it doesn't break ports, there are still quite a few
> ports that depend on the base libevent.
I'll run a bulk build with that. Apply diff to event.h, remove
/usr/include/evutil.h, and that's enough, right ?
Landry
> On Thu, Oct 30, 2014 at 02:43:32AM +0100, Alexander Bluhm wrote:
> > Hi,
> >
> > libevent has compatibilty wrappers in evutil. Our tree does not
> > use them anymore, but they are still part of libevent's interface.
> >
> > I don't want to include them automatically, so I suggest to remove
> > evutil.h from event.h. A version bump should not be necessary as
> > the library itself does not change.
> >
> > Does my idea make sense?
> > Is a full ports build needed with this diff?
> >
> > bluhm
> >
> > Index: lib/libevent/event.h
> > ===
> > RCS file: /data/mirror/openbsd/cvs/src/lib/libevent/event.h,v
> > retrieving revision 1.27
> > diff -u -p -r1.27 event.h
> > --- lib/libevent/event.h8 Oct 2014 20:14:19 - 1.27
> > +++ lib/libevent/event.h29 Oct 2014 23:42:45 -
> > @@ -168,8 +168,11 @@ extern "C" {
> > #include
> > #include
> >
> > -/* For int types. */
> > -#include
> > +#define ev_uint64_t uint64_t
> > +#define ev_int64_t int64_t
> > +#define ev_uint32_t uint32_t
> > +#define ev_uint16_t uint16_t
> > +#define ev_uint8_t uint8_t
> >
> > #define EVLIST_TIMEOUT 0x01
> > #define EVLIST_INSERTED0x02
> >
>
Re: libevent evutil.h
On Thu, Oct 30, 2014 at 08:28:56AM +, Nicholas Marriott wrote:
> No I think we are keeping the evutil.h file for now, the idea is just to
> stop event.h including it.
OKay, bulk started with just the event.h diff.
Landry
> On Thu, Oct 30, 2014 at 09:20:49AM +0100, Landry Breuil wrote:
> > On Thu, Oct 30, 2014 at 08:14:35AM +, Nicholas Marriott wrote:
> > > I'd like to see evutil.h go so I'm happy with this idea but yes you will
> > > need to make sure it doesn't break ports, there are still quite a few
> > > ports that depend on the base libevent.
> >
> > I'll run a bulk build with that. Apply diff to event.h, remove
> > /usr/include/evutil.h, and that's enough, right ?
> >
> > Landry
> >
> > > On Thu, Oct 30, 2014 at 02:43:32AM +0100, Alexander Bluhm wrote:
> > > > Hi,
> > > >
> > > > libevent has compatibilty wrappers in evutil. Our tree does not
> > > > use them anymore, but they are still part of libevent's interface.
> > > >
> > > > I don't want to include them automatically, so I suggest to remove
> > > > evutil.h from event.h. A version bump should not be necessary as
> > > > the library itself does not change.
> > > >
> > > > Does my idea make sense?
> > > > Is a full ports build needed with this diff?
> > > >
> > > > bluhm
> > > >
> > > > Index: lib/libevent/event.h
> > > > ===
> > > > RCS file: /data/mirror/openbsd/cvs/src/lib/libevent/event.h,v
> > > > retrieving revision 1.27
> > > > diff -u -p -r1.27 event.h
> > > > --- lib/libevent/event.h8 Oct 2014 20:14:19 - 1.27
> > > > +++ lib/libevent/event.h29 Oct 2014 23:42:45 -
> > > > @@ -168,8 +168,11 @@ extern "C" {
> > > > #include
> > > > #include
> > > >
> > > > -/* For int types. */
> > > > -#include
> > > > +#define ev_uint64_t uint64_t
> > > > +#define ev_int64_t int64_t
> > > > +#define ev_uint32_t uint32_t
> > > > +#define ev_uint16_t uint16_t
> > > > +#define ev_uint8_t uint8_t
> > > >
> > > > #define EVLIST_TIMEOUT 0x01
> > > > #define EVLIST_INSERTED0x02
> > > >
> > >
> >
>
Re: libevent evutil.h
On Thu, Oct 30, 2014 at 02:43:32AM +0100, Alexander Bluhm wrote: > Hi, > > libevent has compatibilty wrappers in evutil. Our tree does not > use them anymore, but they are still part of libevent's interface. > > I don't want to include them automatically, so I suggest to remove > evutil.h from event.h. A version bump should not be necessary as > the library itself does not change. > > Does my idea make sense? > Is a full ports build needed with this diff? No fallout in a bulk build. Landry
Re: Status on porting Rust to OpenBSD
On Wed, Nov 19, 2014 at 07:46:27PM -0800, Dave Huseby wrote: > Hi everybody, > > In my free time over the last few weeks I have been attempting to > cross-compile the rust compiler using the same method that was used to > add support for Dragonfly BSD. I started with the scripts from the > Dragonfly effort and fixed them up to work with OpenBSD and Linux. > All of my code and documentation is here: > > https://github.com/dhuseby/rust-cross-openbsd > > Currently, I'm stuck on stage 3. The part where all of the object > files from both OpenBSD and Linux need to be linked together into an > OpenBSD executable. I'm pretty certain the reason stage 3 doesn't > complete is because of the old linker on OpenBSD. At the bottom of > the README.md file I discuss some options on what to try next. I have > also included build logs of all stages so that other people can see > the output without jumping through all of the hoops I did. > > My options at this point are this: > > 1. Use the same version compiler/assembler/linker on Linux and OpenBSD > so that the object files will be more compatible. Hopefully this will > allow stage 3 to finish linking. > > 2. Apply my OpenBSD target patches to Rust and build a Linux rust > compiler that knows how to target OpenBSD. Then I use Linux emulation > on OpenBSD to run it to compile itself from scratch. Linux emul only works on OpenBSD/i386 iirc.. Did you try communicating with the dfly developer to exchange ideas on the issues you encounter, and the upstream developers ? Anyway, your effort is appreciated. I'll port servo on top as soon as rust is working :) Landry pgpj96M1eCILW.pgp Description: PGP signature
Re: [PATCH] bsd.port.mk - make relation between GH_TAGNAME & GH_COMMIT more apparent (prevent actual bug regression)
On Sat, Apr 04, 2015 at 11:07:11PM +0200, Adam Wolk wrote:
> Hi tech@
>
> I'm the maintainer of www/otter-browser and I got caught while packaging
> otter-browser 0.9.04. Upstream asked us to point at a different commit
> then the tagged revision so we did:
>
> GH_TAGNAME = v0.9.04
> # This is the actual tagged revision
> # GH_COMMIT = 869d29d19719b3057e137a79d4a10025d2c920f6
> # but we were asked by upstream to release from the following commit
> # as it's considered an important fix affecting the majority of users
> GH_COMMIT =23d7ee6f9cd636e750687a01975b177c1c9c2e53
>
> This port was reviewed with an ok by two people and underwent further
> changes later on.
>
> I didn't notice that the port actually packaged GH_TAGNAME contents
> instead of GH_COMMIT.
GH_COMMIT is meaningless in terms of "package version", which expects a
correctly structured version, hence GH_TAGNAME being usually used in
combination with GH_PROJECT.
Look, you even set it yourself for otter-browser:
DISTNAME = ${GH_PROJECT}-${GH_TAGNAME:C/^v//}
(and PKGNAME is derived from DISTNAME)
Here, since you go forward in git history, you have the choice of
bumping REVISION, or using .MMDD suffixes, or using the special
'pre' / 'rc' / 'beta' keywords in the version, see packages-specs(7).
S i'm not sure the documentation is at fault here :)
Landry
Re: Compiling ports tree on older architecture question
On Sun, Apr 05, 2015 at 12:23:38AM -0400, ian kremlin wrote: > Hello tech! > > A friend is borrowing one of my machines to build the entire pkgsrc > tree, a task that entails compiling more than 15k individual programs. > This has taken 3 days, even on my modern and prepared amd64 machine! (to > my surprise). This has me curious: > > > Every OpenBSD release includes an immediately-accessible source for > prebuilt binary packages, meaning a similar feat involving building an > entire tree of ports must be performed. How is this handled on platforms > like vax or hppa? How long does it take using ostensibly decades-old > machines? Pending hardware & kernel reliability.. have some numbers: macppc: 3 hosts (Xserve G4, 2 MP running SP), around 15 days for ~8400 pkgs alpha: 2 hosts (DS20L MP running SP + DS10L), around 18/20 days for ~6900 pkgs sparc64: 3 SP hosts (2 v210 +, 1 v215), around 17 days for ~8300 pkgs hppa: 2 MP hosts (J6000 + J6700), around 9/10 days for ~6700 pkgs Landry
Re: man, man.conf and /usr/ports/infrastructure/man
On Sun, Apr 12, 2015 at 04:43:31PM -0400, dan mclaughlin wrote: > it seems that /usr/ports/infrastructure/man is not searched by default, and > there is no example in man.conf for it. given that some pages like dpb(1) > are there, and referenced thruout a number of pages (eg bsd.port.mk), this > seems an oversight. > > on a releated note, it also seems that ports/infrastructure/man/mandoc.db > is also not created by default. > > the diff below adds a manpath to man.conf, but that still doesn't fix the > issue of ports/infrastructure/man not being searched. perhaps this should > be taken out of examples? or at least some note should be made in ports(7) > or the FAQ that one should add this? many regular manpages reference it, > and 'man dpb' never works by default. It was the case before but was removed in src/etc/man.conf r1.22. Landry
Re: jail_bin_add: script to add binary and libs to chroot
On Mon, Jun 08, 2015 at 02:59:28PM +0200, Marc Espie wrote: > On Mon, Jun 08, 2015 at 01:46:17AM -0400, dan mclaughlin wrote: > > i figure this should be useful to some. > > any nits welcome. > > Unfortunately, this will become increasingly useless in > gtk-land. > > Compare ldd firefox vs a ktrace of the running binary... :( Totally pointless example - firefox is a very specific case, in that case you want ldd /usr/local/lib/firefox-*/libxul.so.* i dont know of many gtk applications doing this (bundling everything in a dlopen'ed library with tons of linking hacks to improve startup times...) Landry
[libressl] Improve XMPP protocol support for starttls on s_client
Hi,
i'm not an ssl hacker at all, but while debugging openssl -starttls
issues against an xmpp server, i stumbled upon
https://rt.openssl.org/Ticket/Display.html?id=2860&user=guest&pass=guest
which fixes some issue with -starttls xmpp and adds the possibility to
use -xmpphost in case there's some virtualhost. Backported the patch to
libressl and applied style(9), works fine here in basic testing against
prosody, before -starttls xmpp host was just stalling. I havent touched
the documentation chunks since i dont really know if we still use the
pod format or...
comments/feedback welcome.
Landry
Index: s_client.c
===
RCS file: /cvs/src/usr.bin/openssl/s_client.c,v
retrieving revision 1.13
diff -u -r1.13 s_client.c
--- s_client.c 14 Apr 2015 12:56:36 - 1.13
+++ s_client.c 6 Jul 2015 11:36:07 -
@@ -335,6 +335,7 @@
char *port = PORT_STR;
int full_log = 1;
char *host = SSL_HOST_NAME;
+ char *xmpphost = NULL;
char *proxy = NULL, *connect = NULL;
char *cert_file = NULL, *key_file = NULL;
int cert_format = FORMAT_PEM, key_format = FORMAT_PEM;
@@ -415,6 +416,10 @@
if (--argc < 1)
goto bad;
proxy = *(++argv);
+ } else if (strcmp(*argv,"-xmpphost") == 0) {
+ if (--argc < 1)
+ goto bad;
+ xmpphost= *(++argv);
} else if (strcmp(*argv, "-verify") == 0) {
verify = SSL_VERIFY_PEER;
if (--argc < 1)
@@ -985,13 +990,16 @@
int seen = 0;
BIO_printf(sbio, "", host);
+ "xmlns='jabber:client' to='%s' version='1.0'>", xmpphost?
xmpphost:host);
seen = BIO_read(sbio, mbuf, BUFSIZZ);
mbuf[seen] = 0;
- while (!strstr(mbuf, ""))
- goto shut;
+ while (!strstr(mbuf, "");
Re: [libressl] Improve XMPP protocol support for starttls on s_client
On Tue, Jul 07, 2015 at 01:35:00PM +0100, Stuart Henderson wrote:
> On 2015/07/06 13:40, Landry Breuil wrote:
> > Hi,
> >
> > i'm not an ssl hacker at all, but while debugging openssl -starttls
> > issues against an xmpp server, i stumbled upon
> > https://rt.openssl.org/Ticket/Display.html?id=2860&user=guest&pass=guest
> > which fixes some issue with -starttls xmpp and adds the possibility to
> > use -xmpphost in case there's some virtualhost. Backported the patch to
> > libressl and applied style(9), works fine here in basic testing against
> > prosody, before -starttls xmpp host was just stalling. I havent touched
> > the documentation chunks since i dont really know if we still use the
> > pod format or...
>
> Seems useful to me, some of the starttls-based protocols can be a
> pain to diagnose without a tool like this.
>
> It definitely needs the documentation chunk for -xmpphost though,
> it should go in src/usr.bin/openssl/openssl.1, and I think probably
> adding to sc_usage() in s_client.c.
New version with manpage & usage amended.
Landry
Index: openssl.1
===
RCS file: /cvs/src/usr.bin/openssl/openssl.1,v
retrieving revision 1.15
diff -u -r1.15 openssl.1
--- openssl.1 20 Jun 2015 01:07:25 - 1.15
+++ openssl.1 8 Jul 2015 04:42:04 -
@@ -7137,6 +7137,13 @@
command for more information.
.It Fl connect Ar host : Ns Ar port
This specifies the host and optional port to connect to.
+.It Fl xmpphost Ar hostname
+This option, when used with
+.Fl starttls Ar xmpp,
+specifies the host for the "to" attribute of the stream element.
+If this option is not specified, then the host specified with
+.Fl connect
+will be used.
.It Fl key Ar keyfile
The private key to use.
If not specified, the certificate file will be used.
Index: s_client.c
===
RCS file: /cvs/src/usr.bin/openssl/s_client.c,v
retrieving revision 1.13
diff -u -r1.13 s_client.c
--- s_client.c 14 Apr 2015 12:56:36 - 1.13
+++ s_client.c 8 Jul 2015 04:42:04 -
@@ -238,6 +238,7 @@
BIO_printf(bio_err, " 'prot' defines which one to
assume. Currently,\n");
BIO_printf(bio_err, " only \"smtp\", \"lmtp\",
\"pop3\", \"imap\", \"ftp\" and \"xmpp\"\n");
BIO_printf(bio_err, " are supported.\n");
+ BIO_printf(bio_err, " -xmpphost host - connect to this virtual host on
the xmpp server\n");
#ifndef OPENSSL_NO_ENGINE
BIO_printf(bio_err, " -engine id- Initialise and use the specified
engine\n");
#endif
@@ -335,6 +336,7 @@
char *port = PORT_STR;
int full_log = 1;
char *host = SSL_HOST_NAME;
+ char *xmpphost = NULL;
char *proxy = NULL, *connect = NULL;
char *cert_file = NULL, *key_file = NULL;
int cert_format = FORMAT_PEM, key_format = FORMAT_PEM;
@@ -415,6 +417,10 @@
if (--argc < 1)
goto bad;
proxy = *(++argv);
+ } else if (strcmp(*argv,"-xmpphost") == 0) {
+ if (--argc < 1)
+ goto bad;
+ xmpphost= *(++argv);
} else if (strcmp(*argv, "-verify") == 0) {
verify = SSL_VERIFY_PEER;
if (--argc < 1)
@@ -985,13 +991,16 @@
int seen = 0;
BIO_printf(sbio, "", host);
+ "xmlns='jabber:client' to='%s' version='1.0'>", xmpphost?
xmpphost:host);
seen = BIO_read(sbio, mbuf, BUFSIZZ);
mbuf[seen] = 0;
- while (!strstr(mbuf, ""))
- goto shut;
+ while (!strstr(mbuf, "");
Re: allow usermod to remove user from secondary groups
On Fri, Apr 08, 2011 at 07:53:51PM +0200, Frank Brodbeck wrote: > Hi, > > lately I was reading on misc@ [1] that there's no way to remove a user > from secondary groups but by hand. I also searched for a PR but couldn't > find one. The attached diff remedies the problem: > > # id test > uid=1001(test) gid=10(users) groups=10(users), 9(wsrc), 69(network), > 117(dialer) > # usermod -G wsrc,network test > # id test > uid=1001(test) gid=10(users) groups=10(users), 9(wsrc), 69(network) > # usermod -G wsrc,network,dialer test > # id test > uid=1001(test) gid=10(users) groups=10(users), 9(wsrc), 69(network), > 117(dialer) Hmm.. please no. Don't know if it's a bug or not, but i'm very used to -G to _add_ groups to the existing group list for a user. If i understand your diff correctly, one has to list all the groups it wants the user to be in, whereas now you just list the groups you want to add. So say i just installed a machine, i'm in users+wheel, i want to add myself to wsrc, if i do usermod -G wsrc like im used to, that'll remove me from users/wheel. Bye bye sudo etc. That happens to me everytime i use usermod on linux. Linux usermod has a '-a' flag to say 'the list after -G is the list of group i want to add', but i never remember it, and each time it removes the bazillion of default group a user needs to be in (audio, dev, video, etc etc) So please don't change that behaviour. If you want to remove a group for a user, you can still edit /etc/group. Landry
Re: man.conf, pick up ports manpages by default
On Mon, Apr 11, 2011 at 10:28:49AM +0200, Jasper Lievisse Adriaanse wrote: > On Mon, Apr 11, 2011 at 09:19:57AM +0100, Stuart Henderson wrote: > > it's useful for ports developers to be able to read the infrastructure > > manpages (dpb, pkg_subst, update-patches, etc) without making changes > > to the default configuration. > > > > as with X11R6, this fails cleanly if the relevant directories are not > > present. > > > > ok? > Certainly OK with me, this would be one less local modification for me. > Please get another OK too though. ok too, and thanks! Landry
Re: wprintf and friends
On Fri, Apr 22, 2011 at 04:04:29PM +0200, Mark Kettenis wrote: > > With that change, the diff is ok kettenis@, assuming this is all done > in coordination with the ports people Since we did the bulk builds and stefan proactively fixed the affected ports, that's ok on porters' side... Landry
Re: Filesystem Hierarchy Standard (FHS) and OpenBSD
On Mon, May 09, 2011 at 11:33:27PM -0400, Jeff Licquia wrote: > (Sorry if this isn't the proper list for this discussion. If not, > please point me in the right direction.) > > The Linux Foundation's LSB workgroup has taken over maintenance of > the Filesystem Hierarchy Standard, and is working on a number of > updates needed since its last release in 2004. > > Despite all the "Linux" in the names above, we're wanting to make > sure that the FHS remains independent of any particular UNIX > implementation, and continues to be useful to non-Linux UNIXes. > > My question to you is: do you consider the FHS to be relevant to > current and future development of OpenBSD? If not, is this simply > due to lack of maintenance; would your interest in the FHS be > greater with more consistent updates? Some parts of FHS won't apply on OpenBSD, like /srv, /opt, /libXX and /media. I'm not even speaking of the /run promoted by systemd/fedora. /boot is a file on OpenBSD, not a dir. And as pointed out, OpenBSD makes a clear distinction between /usr (the basesystem) and /usr/local (the apps installed by the package tools). Other than that, it looks similar to our own FHS/mtree. If FHS spec is changed to move those entries to the linux-specific Operating System Specific Annex section, then it might make sense. Other than that, i don't see much point. OpenBSD won't change its FHS for the pleasure of LSB... Landry
Re: X configuration changes for synaptics - please test
On Sat, Jun 18, 2011 at 08:25:19AM -0600, Aaron Bieber wrote: > Hi, > > I applied these patches to -current on my lenovo t410. > > The trackpad works as expected for for a few minutes, and then seems to > "lock up" ( not allowing me to move the pointer, or click the two > buttons under it ). I've experienced it twice on my msi wind u100, with the very latest synaptics.v2.diff.. vt switching 'fixes it'. Alas, nothing special in Xorg.0.log nor dmesg. Landry
Re: more old stuff
On Wed, Aug 24, 2011 at 12:39:07PM +0200, Marc Espie wrote: > Apparently, nobody cares about fat packages. > > Not surprisingly, killing that code simplifies a few things. > Especially since the necessity of passing arch around was only due to > the possibility of fat packages... I don't see the relation between fat package and arch.. was one of the planned usecase 'build a single package containing a pkg for each archs' ? Or rather a way to install/bundle several packages together (like a gnome metapackage ? :) Landry
Re: bge(4): enable TCP/UDP checksum offload
On Sun, Nov 04, 2012 at 12:22:31AM +0100, Christian Weisgerber wrote: > Brad Smith: > > > Here is another revision but disabling the UDP checksum offload. > > There is a bug that results in some UDP packets having a 0 checksum. > > Oh, right. I assume you are referencing this FreeBSD commit? > http://svnweb.freebsd.org/base/head/sys/dev/bge/if_bge.c?r1=211595&r2=211596&diff_format=u > > In that case I suggest we also copy the relevant portion of the comment: > > + * It seems all Broadcom controllers have a bug that can generate UDP > + * datagrams with checksum value 0 when TX UDP checksum offloading is > + * enabled. Generating UDP checksum value 0 is RFC 768 violation. Seems to work fine on sparc64*.p with : bge0 at pci7 dev 4 function 0 "Broadcom BCM5714" rev 0xa3, BCM5715 A3 (0x9003) bge3 at pci3 dev 2 function 1 "Broadcom BCM5704C" rev 0x00, BCM5704 B0 (0x2100) Landry
sqlite3 3.7.14.1
Hi, here's a 250k diff to update our base sqlite3 to the latest 3.7.14.1 : http://rhaalovely.net/~landry/shared/sqlite-3.7.14.1.diff I hope i got the diff right, iirc no local modifications were made to the actual code. Mozilla 18 branch depends on it (for no good reason as usual) so i'd like to get it in in the coming weeks. Bumped major to 21.0, builds fine on amd64. No more testing than that.. i'll do a bulk build with it. Can we run the regress tests from databases/sqlite3 on the base sqlite ? Nothing fancy in the 3.7.14 and .1 releases : http://www.sqlite.org/changes.html Landry
Re: drm@macppc, please test
On Thu, Dec 06, 2012 at 05:53:05PM +0100, Martin Pieuchot wrote: > Hey, > > I've just committed the last part of the work I started during g2k12 and > I would really appreciate some more tests before enabling drm(4) on > macppc. > > - First of all you need a machine with a G3 or G4 processor and a Radeon > graphic card. > > - Then update your source tree to -current and make sure it is current > enough (you must have /sys/dev/agp.c rev 1.36). > > - If you don't have them already, make sure to create /dev/agp0 and > /dev/drm0 using the appropriate MAKEDEV(8). > > - Start by building a GENERIC kernel and make sure it works as expected. > > - If everything went fine, you can now muild a custom kernel with: > > #option DRMDEBUG > radeondrm* at vgafb? # ATI Radeon DRM driver > drm*at radeondrm? Still works fine for me on macppc mini & ibook g4, this time without xorg.conf forcing the BusType to PCI # ibook memc0 at mainbus0: uni-n rev 0xd2 appleagp0 at pchb0 agp0 at appleagp0: aperture at 0x0, size 0x1000 vgafb0 at pci0 dev 16 function 0 "ATI Radeon Mobility 9200" rev 0x01, mmio radeondrm0 at vgafb0: irq 48 drm0 at radeondrm0 20:44] gail:~/ $DISPLAY=:0 xdriinfo Screen 0: r200 [20:44] gail:~/ $DISPLAY=:0 glxgears -info GL_RENDERER = Mesa DRI R200 (RV280 5C63) AGP 4x TCL # mini memc0 at mainbus0: uni-n rev 0xd2 appleagp0 at pchb0 agp0 at appleagp0: aperture at 0x0, size 0x1000 vgafb0 at pci0 dev 16 function 0 "ATI Radeon 9200" rev 0x01, mmio radeondrm0 at vgafb0: irq 48 drm0 at radeondrm0 20:46] mikey:~/ $DISPLAY=:0 xdriinfo Screen 0: r200 [20:46] mikey:~/ $DISPLAY=:0 glxgears -info GL_RENDERER = Mesa DRI R200 (RV280 5962) AGP 4x TCL Full dmesg/xorg.0.log available if needed. You've just tripled the amount of boxes drm-enabled here, thx! Landry
Re: binary integer constants in gcc
On Fri, Jun 21, 2013 at 10:20:01AM +0200, Mark Kettenis wrote: > > Date: Fri, 21 Jun 2013 17:31:39 +1000 > > From: Jonathan Gray > > > > Both gcc and clang have an extension for binary integer constants. > > In gcc's case this has been around since 4.3. > > > > The mesa backend for newer intel parts (i965) assumes this extension > > is present in recent versions. > > Sigh... Can't these people just write portable C? > > > Below is a diff to add support for this to our in tree gcc4. While the > > i965 backend is only built on gcc4 archs the concern is that abuse > > of this extension in ports or other places may make gcc3/gcc2 archs > > worse off unless similiar patches can be done... > > Well, lots of ports stuff is compiled with newer gcc versions anyway. Actually, not so many: $echo "select count(*) from modules where value='gcc4';" | sqlite3/usr/local/share/sqlports 34 And if you rip out all the subpackages, the actual list is: audio/mscore editors/libreoffice lang/classpath lang/luajit net/rtorrent print/cups-filters textproc/pdftk www/mozilla-firefox www/seamonkey www/squid Landry
Re: binary integer constants in gcc
On Fri, Jun 21, 2013 at 10:50:42AM +0200, Landry Breuil wrote: > On Fri, Jun 21, 2013 at 10:20:01AM +0200, Mark Kettenis wrote: > > > Date: Fri, 21 Jun 2013 17:31:39 +1000 > > > From: Jonathan Gray > > > > > > Both gcc and clang have an extension for binary integer constants. > > > In gcc's case this has been around since 4.3. > > > > > > The mesa backend for newer intel parts (i965) assumes this extension > > > is present in recent versions. > > > > Sigh... Can't these people just write portable C? > > > > > Below is a diff to add support for this to our in tree gcc4. While the > > > i965 backend is only built on gcc4 archs the concern is that abuse > > > of this extension in ports or other places may make gcc3/gcc2 archs > > > worse off unless similiar patches can be done... > > > > Well, lots of ports stuff is compiled with newer gcc versions anyway. > > Actually, not so many: > > $echo "select count(*) from modules where value='gcc4';" | > sqlite3/usr/local/share/sqlports > 34 > > And if you rip out all the subpackages, the actual list is: > > audio/mscore > editors/libreoffice > lang/classpath > lang/luajit > net/rtorrent > print/cups-filters > textproc/pdftk > www/mozilla-firefox > www/seamonkey > www/squid Oh and of course as soon as we enable webkit2 api, www/webkit will also need recent gcc/clang for c++11 stuff. And mail/mozilla-thunderbird too in 3 months when the 24 branch is released. Landry
Re: awk(1) update
On Sun, Jul 14, 2013 at 09:41:28AM +0200, Jérémie Courrèges-Anglas wrote: > > This diff updates awk to the 20121220 upstream version, with a few > fixups. This caused no direct fallout in a ports bulk build. Landry
Re: add nl(1)
On Sun, Jul 14, 2013 at 04:30:48PM +0200, Jérémie Courrèges-Anglas wrote: > "Todd C. Miller" writes: > > > On Mon, 20 May 2013 12:43:19 +0300, Arto Jonsson wrote: > > > >> Updated diff. I removed the int width handling and modified the > >> separator printing based on your comment. > > > > That looks good to me. > > > > - todd > > I propose to import it. ok? > (+ a note about NetBSD and OpenBSD 5.4 in the manpage.) That version caused no fallout in a ports bulk build. Landry
Re: MSIs for re(4)
On Sat, Aug 03, 2013 at 02:15:16PM +0200, Mark Kettenis wrote: > Theo and I predicted this would happen. When Windows would start > using message signalled interrupts (MSIs), support for APIC interrupts > in BIOSen for new machines would get broken. On a HP Pavillion > Sleekbook 15 I have here the ACPI tables claim the network controller > is connected to pin 16 on the APIC, but in reality it is connected to > pin 17. Funnily enough the BIOS also defines a table with the right > mappings, but nothing is referencing that table. Telltale signs of > shoddy engineering and a total lack of quality control. OK, this was > pretty much the cheapest laptop I could find last June. > > Anyway, I expect to see more and more issues like these as time goes > by. The solution is to be more aggressive with using MSIs in our > drivers. So here is a diff that switches re(4) over to use MSIs on > the RTL8101E "fast" Ethernet variants. These chips are fairly new so > there isn't a gazillion different variants of them, so it's very > likely that MSI will work on all of them. We can take a look at the > other variants later. Fwiw, works fine on my MSI Wind U100 : re0 at pci1 dev 0 function 0 "Realtek 8101E" rev 0x02: RTL8102E (0x3480), apic 2 int 16, address 00:21:85:e2:8f:8f rlphy0 at re0 phy 7: RTL8201L 10/100 PHY, rev. 1 => re0 at pci1 dev 0 function 0 "Realtek 8101E" rev 0x02: RTL8102E (0x3480), msi, address 00:21:85:e2:8f:8f rlphy0 at re0 phy 7: RTL8201L 10/100 PHY, rev. 1 Landry
add lid status sensor to acpibtn
Hi, this diff adds a sensor for acpibtn to show lid status. This allows userland to monitor/react on lid close/open events, in case one is not using machdep.lidsuspend. I know sysutils/upower can make use of this, i just need to add the corresponding code there. comments ? I wonder if/how the case when aml_evalinteger() fails should be handled in acpibtn_attach().. Tests of course welcome, only tested on i386/MSI Wind U100 here where LID is acpibtn0. Landry
Re: add lid status sensor to acpibtn
On Mon, Aug 12, 2013 at 06:01:25PM +0200, David Coppa wrote:
> On Mon, Aug 12, 2013 at 5:40 PM, Landry Breuil wrote:
> > Hi,
> >
> > this diff adds a sensor for acpibtn to show lid status. This allows
> > userland to monitor/react on lid close/open events, in case one is not
> > using machdep.lidsuspend. I know sysutils/upower can make use of this, i
> > just need to add the corresponding code there.
> >
> > comments ? I wonder if/how the case when aml_evalinteger() fails should
> > be handled in acpibtn_attach()..
>
> Where's the diff?
>
Err.. here it is.
Index: acpibtn.c
===
RCS file: /cvs/src/sys/dev/acpi/acpibtn.c,v
retrieving revision 1.34
diff -u -r1.34 acpibtn.c
--- acpibtn.c 2 Jan 2011 04:56:57 - 1.34
+++ acpibtn.c 12 Aug 2013 15:35:35 -
@@ -46,6 +46,9 @@
struct acpi_softc *sc_acpi;
struct aml_node *sc_devnode;
+ struct ksensor sc_sens;
+ struct ksensordev sc_sensdev;
+
int sc_btn_type;
#defineACPIBTN_UNKNOWN 0
#define ACPIBTN_LID1
@@ -123,6 +126,7 @@
struct acpibtn_softc*sc = (struct acpibtn_softc *)self;
struct acpi_attach_args *aa = aux;
struct acpi_lid *lid;
+ int64_t lid_open;
sc->sc_acpi = (struct acpi_softc *)parent;
sc->sc_devnode = aa->aaa_node;
@@ -143,6 +147,20 @@
printf(": %s\n", sc->sc_devnode->name);
+ if (sc->sc_btn_type == ACPIBTN_LID) {
+ strlcpy(sc->sc_sensdev.xname, DEVNAME(sc),
+ sizeof(sc->sc_sensdev.xname));
+ strlcpy(sc->sc_sens.desc, "lid open",
+ sizeof(sc->sc_sens.desc));
+ sc->sc_sens.type = SENSOR_INDICATOR;
+ sensor_attach(&sc->sc_sensdev, &sc->sc_sens);
+ sensordev_install(&sc->sc_sensdev);
+
+ aml_evalinteger(sc->sc_acpi, sc->sc_devnode,
+ "_LID", 0, NULL, &lid_open);
+ sc->sc_sens.value = lid_open;
+ }
+
aml_register_notify(sc->sc_devnode, aa->aaa_dev, acpibtn_notify,
sc, ACPIDEV_NOPOLL);
}
@@ -179,11 +197,12 @@
* _LID method. 0 means the lid is closed and we
* should go to sleep.
*/
- if (lid_suspend == 0)
- break;
if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode,
"_LID", 0, NULL, &lid))
return (0);
+ sc->sc_sens.value = lid;
+ if (lid_suspend == 0)
+ break;
if (lid == 0)
goto sleep;
#endif /* SMALL_KERNEL */
Re: add lid status sensor to acpibtn
On Tue, Aug 13, 2013 at 12:00:19AM +0200, Landry Breuil wrote:
> On Mon, Aug 12, 2013 at 06:01:25PM +0200, David Coppa wrote:
> > On Mon, Aug 12, 2013 at 5:40 PM, Landry Breuil
> > wrote:
> > > Hi,
> > >
> > > this diff adds a sensor for acpibtn to show lid status. This allows
> > > userland to monitor/react on lid close/open events, in case one is not
> > > using machdep.lidsuspend. I know sysutils/upower can make use of this, i
> > > just need to add the corresponding code there.
> > >
> > > comments ? I wonder if/how the case when aml_evalinteger() fails should
> > > be handled in acpibtn_attach()..
> >
> > Where's the diff?
> >
> Err.. here it is.
Anyone willing to actually test this on a selection of laptops before it goes
in ?
Landry
> Index: acpibtn.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpibtn.c,v
> retrieving revision 1.34
> diff -u -r1.34 acpibtn.c
> --- acpibtn.c 2 Jan 2011 04:56:57 - 1.34
> +++ acpibtn.c 12 Aug 2013 15:35:35 -
> @@ -46,6 +46,9 @@
> struct acpi_softc *sc_acpi;
> struct aml_node *sc_devnode;
>
> + struct ksensor sc_sens;
> + struct ksensordev sc_sensdev;
> +
> int sc_btn_type;
> #define ACPIBTN_UNKNOWN 0
> #define ACPIBTN_LID 1
> @@ -123,6 +126,7 @@
> struct acpibtn_softc*sc = (struct acpibtn_softc *)self;
> struct acpi_attach_args *aa = aux;
> struct acpi_lid *lid;
> + int64_t lid_open;
>
> sc->sc_acpi = (struct acpi_softc *)parent;
> sc->sc_devnode = aa->aaa_node;
> @@ -143,6 +147,20 @@
>
> printf(": %s\n", sc->sc_devnode->name);
>
> + if (sc->sc_btn_type == ACPIBTN_LID) {
> + strlcpy(sc->sc_sensdev.xname, DEVNAME(sc),
> + sizeof(sc->sc_sensdev.xname));
> + strlcpy(sc->sc_sens.desc, "lid open",
> + sizeof(sc->sc_sens.desc));
> + sc->sc_sens.type = SENSOR_INDICATOR;
> + sensor_attach(&sc->sc_sensdev, &sc->sc_sens);
> + sensordev_install(&sc->sc_sensdev);
> +
> + aml_evalinteger(sc->sc_acpi, sc->sc_devnode,
> + "_LID", 0, NULL, &lid_open);
> + sc->sc_sens.value = lid_open;
> + }
> +
> aml_register_notify(sc->sc_devnode, aa->aaa_dev, acpibtn_notify,
> sc, ACPIDEV_NOPOLL);
> }
> @@ -179,11 +197,12 @@
>* _LID method. 0 means the lid is closed and we
>* should go to sleep.
>*/
> - if (lid_suspend == 0)
> - break;
> if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode,
> "_LID", 0, NULL, &lid))
> return (0);
> + sc->sc_sens.value = lid;
> + if (lid_suspend == 0)
> + break;
> if (lid == 0)
> goto sleep;
> #endif /* SMALL_KERNEL */
>
Re: add lid status sensor to acpibtn
On Wed, Aug 14, 2013 at 01:55:27PM +0400, Vadim Zhukov wrote: > 2013/8/13 Landry Breuil : > > On Mon, Aug 12, 2013 at 06:01:25PM +0200, David Coppa wrote: > >> On Mon, Aug 12, 2013 at 5:40 PM, Landry Breuil > >> wrote: > > * _LID method. 0 means the lid is closed and we > > * should go to sleep. > > */ > > - if (lid_suspend == 0) > > - break; > > if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode, > > "_LID", 0, NULL, &lid)) > > return (0); > > + sc->sc_sens.value = lid; > > + if (lid_suspend == 0) > > + break; > > Probably a stupid question, but is it safe to call aml_evalinteger() > when we're suspending (lid_suspend!=0)? In that context, lid_suspend maps to machdep.lidsuspend, which means 'i want to suspend if the lid is being closed'. The actual 'going to sleep' is done just below, so WRT aml_evalinteger it changes nothing. > > if (lid == 0) > > goto sleep; > > #endif /* SMALL_KERNEL */ Landry
Re: Small binutils tweak
On Sun, Apr 21, 2013 at 10:42:09AM -0400, Brian Callahan wrote: > On 04/21/13 03:21, Jonathan Gray wrote: > >On Sat, Mar 02, 2013 at 10:36:50AM -0500, Brian Callahan wrote: > >>Hi tech -- > >> > >>While doing some ports testing with clang, I came across the > >>binutils bug mentioned here: > >>http://lists.gnu.org/archive/html/bug-binutils/2004-07/msg0.html > >> > >>Below is a backport of the commit mentioned later in the thread. It > >>fixes the issue. > >>I was able to rebuild working kernels and do a full 'make build' on > >>amd64, loongson, and macppc with this patch. But since it affects > >>all archs, testing on the archs I don't have access to will be > >>needed. > >> > >>OK? > >This patch does not apply, it seems your mail client is wrapping lines. > > > > > > Below. Also attached as a tarball, in case Thunderbird really just hates me. > > miod told me about a month and a half ago to focus on moving to > binutils-2.17 and not backport things to 2.15 so I never bothered to > ping this. Bringing this back , since i'm facing issues with mozilla / icu linking with ld/building with clang. In my limited testing, instead of the big patch you were referring to, just using elflink.c r1.76 was enough to fix my issue. See https://bugzilla.mozilla.org/show_bug.cgi?id=908080 for the whole story, and http://www.sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elflink.c.diff?cvsroot=src&r1=1.75&r2=1.76 for the much smaller fix. Whatever was the reason for backing this out (iirc, xenocara blowed on ppc), this needs to be reconsidered, since we're not going to move to binutils 2.17 right now. Landry
Re: SQLite 3.8.0.2 diff
On Thu, Sep 12, 2013 at 02:35:02PM -0400, James Turner wrote: > Attached is a diff to update our in tree version of SQLite to the > recently released 3.8.0.2. SQLite 3.8.0 is needed for a fossil update > I'm working on. > > I've tested this diff against my fossil update and everything appears to > be good, the recent arc4random addition should have been maintained > across the diff. > > This should probably go through a round of bulk builds. I'll express my > thanks now for anyone who can assist by running a bulk build on a couple > platforms. Doesnt seem to cause any direct fallout in an amd64 bulk build. At some poing mozilla will also require 3.8.x, see https://bugzilla.mozilla.org/show_bug.cgi?id=909382. Apparently there are still bugfixes piling on this 3.8.0.x branch.. And note that for mozilla, we might need to turn on the new SQLITE_ALLOW_URI_AUTHORITY define flag at some point for https://bugzilla.mozilla.org/show_bug.cgi?id=879133 . I dont grok all the details here, it seems a windows only issue (profiles on a cifs network drive) but mozilla might require that flag to be set to allow building with systemwide sqlite. Landry
Re: shared libs and ports, maybe a proposal
On Fri, Jul 9, 2010 at 10:16 AM, Marc Espie wrote: > On Thu, Jul 08, 2010 at 08:22:38PM +, Christian Weisgerber wrote: >> I think both sthen@ and I have mentioned before that we really like >> how FreeBSD has the revision in a separate PORTREVISION variable >> that is much easier and less error prone to increment than pX >> suffixes in PKGNAME. >> >> > e.g., we would have something like: >> > >> > REVISION-main = 5 >> > REVISION-a = 2 >> >> Yes. And consider putting vX in a separate variable as well while >> you're there (` la FreeBSD's PORTEPOCH). > > As far as naming goes, are you okay with REVISION(-sub) and EPOCH(-sub) ? > I don't see the point in adding an extra PORT in front of it. Fwiw, i highly support that. Landry
Re: ncursesw
On Mon, Aug 23, 2010 at 01:36:53AM +0100, Nicholas Marriott wrote: > Hi > > Here are the bits for wide character support in libcurses, libform, > libpanel, libmenu. > > Apply the diff below and extract this tarball in src/lib (note this is > on a slow connection so please don't bother unless you are going to > test): > > http://nicm.ath.cx/~nicholas/ncursesw.tar.gz > > It is a major bump for all four libs. The files are also on cvs in > ~nicm/ncursesw/. > > This builds all the libraries with the widechar code and also links them > to "w" versions (libncursesw, libformw, etc). Some OSs only put the > widechar stuff into libncursesw and not libncurses - I don't much like > knobs in the form of library names but if opinion is that we should go > that way then I can change it. > > I've been running with this for a while on amd64 without seeing any > problems, and UTF-8 seems fine in mutt - the port picks it up fine, then > you just need to set LANG. It also seems fine on sparc64. > > Any ports person like to volunteer to help test this/take care of > breakage? :-) I'll run a bulk with it if noone beats me to it. Landry
Re: ncursesw
On Mon, Aug 23, 2010 at 01:04:25PM +, Christian Weisgerber wrote: > Landry Breuil wrote: > > > > http://nicm.ath.cx/~nicholas/ncursesw.tar.gz > > > > I'll run a bulk with it if noone beats me to it. > > Here's a list of candidates that are likely to be affected: > > audio/herrie.log:cc -c ./src/audio_file.c -O2 -pipe -I/usr/local/include > -DAPP_NAME=\"herrie\" -DAPP_VERSION=\"2.2\" -I/usr/local/include > -I/usr/local/include/ncursesw -I/usr/local/include/ncurses > -DCURSES_HEADER=\ -I/usr/local/include/glib-2.0 > -I/usr/local/lib/glib-2.0/include -pthread -I/usr/local/include/glib-2.0 > -I/usr/local/lib/glib-2.0/include -DBUILD_HTTP -DBUILD_SCROBBLER > -I/usr/local/include -DBUILD_MP3 -DBUILD_RES_INIT -DBUILD_SNDFILE -DBUILD_NLS > -DBUILD_VORBIS -DBUILD_AO -o audio_file.o > audio/ncmpc.log:checking for initscr in -lncursesw... no > audio/pms.log:checking for working ncursesw... no > comms/c3270.log:checking for newterm in -lncursesw... no > databases/mysql.log:checking for tgetent in -lncursesw... no > devel/tig.log:checking for ncursesw/ncurses.h... no > editors/zile.log:checking for working ncursesw... no > games/clines.log:checking for initscr in -lncursesw... no > graphics/libcaca.log:checking for initscr in -lncursesw... no > lang/ghc.log:checking for setupterm in -lncursesw... no > lang/swi-prolog.log:checking for main in -lncursesw... no > mail/abook.log:checking for initscr in -lncursesw... no > mail/mutt/snapshot.log:checking for waddnwstr in -lncursesw... no > mail/mutt/stable.log:checking for waddnwstr in -lncursesw... no > misc/dialog.log:checking if you want the wide-curses features... no > misc/lifelines.log:checking for tparm in -lncursesw... no Fails with ../../src/hdrs/mycurses.h:8:29: error: ncursesw/curses.h: No such file or directory > net/mcabber.log:checking for waddnwstr in -lncursesw... no > net/pidgin.log:checking for initscr in -lncursesw... no fails because it looks for a 'get_wch' #define in ncurses.h all depending ports don't build.. should be wget_wch instead ? > print/texlive/base.log:checking if you want the wide-curses features... no > productivity/calcurse.log:checking for initscr in -lncursesw... no > shells/zsh.log:checking for ncursesw/ncurses.h... no Fails at curses.c:717: error: 'cchar_t' undeclared (first use in this function) > sysutils/ncdu.log:checking for initscr in -lncursesw... no > sysutils/testdisk.log:checking for initscr in -lncursesw... no > sysutils/vifm.log:checking for initscr in -lncursesw... no > textproc/aspell/core.log:checking for wide character support in curses > libraray... no > textproc/hunspell.log:checking for tparm in -lncursesw... no Other ports package fine... some will probably need to be checked for WANTLIB (ncurses -> ncursesw). Some of the configure script seem to only check for ncursesw/ncurses.h header, and don't bother trying -lncursesw. cvs:~landry/ncursesw-found.gz contains the list of 'ncursesw' occurences in all the build logs for the bulk. Landry
Re: ncursesw
On Wed, Aug 25, 2010 at 08:48:05AM +0100, Nicholas Marriott wrote:
> Hi
>
> On Tue, Aug 24, 2010 at 11:05:46PM +0200, Landry Breuil wrote:
> > On Mon, Aug 23, 2010 at 01:04:25PM +, Christian Weisgerber wrote:
> > > Landry Breuil wrote:
> > >
> > > > > http://nicm.ath.cx/~nicholas/ncursesw.tar.gz
> > > >
> > > > I'll run a bulk with it if noone beats me to it.
> > >
> > > Here's a list of candidates that are likely to be affected:
> > >
> > > audio/herrie.log:cc -c ./src/audio_file.c -O2 -pipe -I/usr/local/include
> > > -DAPP_NAME=\"herrie\" -DAPP_VERSION=\"2.2\" -I/usr/local/include
> > > -I/usr/local/include/ncursesw -I/usr/local/include/ncurses
> > > -DCURSES_HEADER=\ -I/usr/local/include/glib-2.0
> > > -I/usr/local/lib/glib-2.0/include -pthread -I/usr/local/include/glib-2.0
> > > -I/usr/local/lib/glib-2.0/include -DBUILD_HTTP -DBUILD_SCROBBLER
> > > -I/usr/local/include -DBUILD_MP3 -DBUILD_RES_INIT -DBUILD_SNDFILE
> > > -DBUILD_NLS -DBUILD_VORBIS -DBUILD_AO -o audio_file.o
> > > audio/ncmpc.log:checking for initscr in -lncursesw... no
> > > audio/pms.log:checking for working ncursesw... no
> > > comms/c3270.log:checking for newterm in -lncursesw... no
> > > databases/mysql.log:checking for tgetent in -lncursesw... no
> > > devel/tig.log:checking for ncursesw/ncurses.h... no
> > > editors/zile.log:checking for working ncursesw... no
> > > games/clines.log:checking for initscr in -lncursesw... no
> > > graphics/libcaca.log:checking for initscr in -lncursesw... no
> > > lang/ghc.log:checking for setupterm in -lncursesw... no
> > > lang/swi-prolog.log:checking for main in -lncursesw... no
> > > mail/abook.log:checking for initscr in -lncursesw... no
> > > mail/mutt/snapshot.log:checking for waddnwstr in -lncursesw... no
> > > mail/mutt/stable.log:checking for waddnwstr in -lncursesw... no
> > > misc/dialog.log:checking if you want the wide-curses features... no
> > > misc/lifelines.log:checking for tparm in -lncursesw... no
> >
> > Fails with ../../src/hdrs/mycurses.h:8:29: error: ncursesw/curses.h: No
> > such file or directory
>
> I don't think we're going to install this so this needs to be fixed in
> the port I guess.
Yes probably.
> >
> > > net/mcabber.log:checking for waddnwstr in -lncursesw... no
> > > net/pidgin.log:checking for initscr in -lncursesw... no
> >
> > fails because it looks for a 'get_wch' #define in ncurses.h
> > all depending ports don't build.. should be wget_wch instead ?
>
> Hmm. get_wch is a macro but it should be there. Does it define
> _XOPEN_SOURCE_EXTENDED?
The configure test run is more or less:
#define _XOPEN_SOURCE_EXTENDED
#include
int
main ()
{
#ifndef get_wch
# error get_wch not found!
#endif
;
return 0;
}
conftest.c:126:8: error: #error get_wch not found!
Run make configure in net/pidgin for more details..
>
> And I just realised I forgot to add the few extra w man pages :-/.
>
> >
> > > print/texlive/base.log:checking if you want the wide-curses features... no
> > > productivity/calcurse.log:checking for initscr in -lncursesw... no
> > > shells/zsh.log:checking for ncursesw/ncurses.h... no
> >
> > Fails at
> > curses.c:717: error: 'cchar_t' undeclared (first use in this function)
>
> Again seems like it is probably missing _XOPEN_SOURCE_EXTENDED.
It is defined in Src/system.h
#ifndef ZSH_NO_XOPEN
# ifdef ZSH_CURSES_SOURCE
# define _XOPEN_SOURCE_EXTENDED 1
# else
# ifdef MULTIBYTE_SUPPORT
/*
* Needed for wcwidth() which is part of XSI.
* Various other uses of the interface mean we can't get away with just
* _XOPEN_SOURCE.
*/
# define _XOPEN_SOURCE_EXTENDED 1
# endif /* MULTIBYTE_SUPPORT */
# endif /* ZSH_CURSES_SOURCE */
#endif /* ZSH_NO_XOPEN */
but ZSH_NO_XOPEN is defined to 1... given by this configure.ac snippet
[[case "$host_os" in
*openbsd*|*freebsd5*|*freebsd6.[012]*|*aix*)
zsh_cv_no_xopen=yes
Landry
Re: patch to add RequestHeader directive to httpd mod_headers.c
On Wed, Sep 22, 2010 at 05:20:04PM +0200, Sebastian Reitenbach wrote: > Alexander Hall wrote: > > I don't have any actual interest in the change myself, nor the time to > > test it, but now at least the diff has the fixes I expected to see > > regarding my prior concerns. > > > > Anyone else who would test or comment on this one? > Tested so far by me: telnetting to apache, and see what comes back, so > the old headers still seem to work for me. Tested the new RequestHeader > directive in conjunction with mod_proxy configured as reverse proxy. > Have seen with tcpdump that the headers were sent to the application server. I've read the diff and i see nothing wrong with it. I suppose you tried all set/append/add/unset actions ? Can someone more confident in userland doublecheck and okay it ? Landry
Re: merge pms and pmsi + added support for some of mouse
On Wed, Sep 29, 2010 at 06:53:33PM +0100, Nicholas Marriott wrote: > this reads fine and works fine for me > > although i don't really agree with all this return () and comment > changing.. if everyone did that there would be tons of unnecessary > changes, the existing style is fine... but anyway, meh, the diff works Speaking of that... > > - return (10); > > + return 1; is this really intended or correct ? Landry
Re: no need to link libdes for kerberos
On Tue, Oct 12, 2010 at 06:04:09AM +1100, Jonathan Gray wrote: > The kerberosV code switched to using the version of DES > in libcrypto when biorn imported heimdal 0.7.2 over four > years ago, the following diff removes the uneeded linking > to libdes. > > As the code in OpenSSL/libcrypto is based on the code > in libdes it would be nice if we could move the following > over to libcrypto and remove libdes at some point: > > libexec/login_tis > libexec/login_token > sbin/isakmpd > usr.bin/passwd > usr.bin/sectok > usr.bin/telnet > usr.bin/x99token/ > usr.sbin/ppp/ppp > usr.sbin/tokenadm > usr.sbin/tokeninit > > Builds work fine with the below but I'm not using kerberos/afs etc > so test reports welcome. This might have effects (at least WANTLIB changes, to be handled) on the following ports: sqlite> select fullpkgpath from wantlib where value like 'des'; mail/alpine,-main mail/imap-uw,-server mail/imap-uw,-mailutil mail/mutt/stable mail/mutt/stable,compressed mail/mutt/snapshot mail/mutt/snapshot,sasl mail/mutt/snapshot,sidebar,compressed mail/mutt/snapshot,sasl,sidebar,compressed mail/mutt/snapshot,sasl,sidebar,slang,compressed security/dsniff security/dsniff,no_x11 security/l0phtcrack x11/nx/nxssh Landry
Re: Today's pkg_add -u broke my Thunar on xfce
On Tue, Nov 16, 2010 at 11:58:44AM +0100, David Coppa wrote: > On Mon, Nov 15, 2010 at 11:43 AM, Andreas Kahari wrote: > > On Thu, Nov 11, 2010 at 07:28:18PM +0100, Landry Breuil wrote: > >> On Thu, Nov 11, 2010 at 06:23:50PM +0100, Landry Breuil wrote: > >> > On Thu, Nov 11, 2010 at 04:39:55PM +, Andreas Kahari wrote: > >> > > On Thu, Nov 11, 2010 at 05:17:06PM +0100, Paolo Aglialoro wrote: > >> > > > Hello, > >> > > > > >> > > > I'm running -current on i386, today I upgraded system to 8 nov 2011 > >> > > > snapshot. > >> > > > X and xfce4 worked flawlessly. I last upgraded xfce at the end of > >> > > > October. > >> > > > After controlling X was ok, I went from CLI to upgrade the whole > >> > > > packages > >> > > > with pkg_add -u. > >> > > > Now, after loading xfce, icons on desktop do not show, and thunar > >> > > > fails to > >> > > > start. > >> > > > > >> > > > Is there some problem with last Thunar build? > >> > > > THX > >> > > > > >> > > > >> > > (moved to ports from misc) > >> > > > >> > > I have the same problem (ever since I tried to get back to XFCE4 last > >> > > week). Both /usr/local/bin/thunar and /usr/local/bin/xfdesktop dumps > >> > > core. > >> > > >> > No idea. I've been reported that recently.. thunar/xfdesktop didn't > >> > change, so it's probably something in the dependency chain that was > >> > updated and broke it. From my understanding, the crash happens in > >> > thunar-vfs-enum-types.c which is code generated by glib-mkenums, but i > >> > doubt it is related to last glib update as 2.26 went in end of > >> > september and diffing the code generated by both versions of glib shows > >> > no difference. It seems amd64 is not affected. > >> > > >> > Oh, and if you want to debug things, rebuild/reinstall package with > >> > EBUG=-g set. Useless otherwise. > >> > >> Oh, and of course provide more details. > >> What version of glib2 do you have ? 2.26p1 or 2.26p0 ? What version of > >> libpthread ? 13.0 or 13.1 ? That might be a fallout of > >> sched_get_priority_xx addition to libpthread. Make sure to have very > >> latest version of both. > >> > >> Landry > >> > > > > Hi, > > > > With libpthread.so.13.1 and glib2-2.26.1 thunar (and therefore also > > xfdesktop) runs fine. With glib2 2.26p1 it crashed. > > Uhmmm... It's still failing for me with libpthread.so.13.1 and glib2-2.26.1. > Thunar only works if you compile it using "-O0", which is also strange. > > Btw, It's the same failure reported here: > > https://labs.omniti.com/labs/reconnoiter/lists/users/2010-August/000510.html > > And here: > > http://marc.info/?l=openbsd-ports&m=128785324016639 Excuse me, but how can you say its 'the same failure' ? The backtraces are only barely similar, only common thing is they involve libpthread. Does it work with libpthread 13.0 and glib 2.26.0p0 ? If so, i can only blame sched_get_priority_xx. Here on amd64, libpthread 13.1/glib2.26.0p0 or glib2.26.0p1, works fine. Landry
Re: maxdsiz tweaking
On Sun, Nov 28, 2010 at 06:51:45PM -0500, Ted Unangst wrote: > What follows is a somewhat older mail I had forgotten about. It's > suddenly become more interesting to be because I was playing around with > jruby which requires a big heap size. It pisses me off to own a 3GB > laptop and only be able to use 1GB of that memory. > > This does 2.5 things. > > 1. If uvm_mmap fails to find memory in the normal mmap area, go back > again and look for memory somewhere else (brk). We only do this after > failure, to preserve the brk space as long as possible. > > 2. Distinguish the two meanings of MAXDSIZ. Use BRKSIZ in more places (I > think this technically fixes a bug on vax) and add it to i386. > > 2.5. Up i386 MAXDSIZ to 2G. > > End effect: You can fsck a much larger filesystem now. This doesn't > change memory layout or allocation policy for any existing program, but > will let you throw more memory at programs that don't currently run. Or probably allows one to build debug-enabled monsters like firefox^Wmozilla or webkit on i386.. which currently ld fails to link due to object sizes. if so, i'd welcome that. Landry
Re: wscanf
On Tue, Sep 20, 2011 at 06:09:34PM +0200, Stefan Sperling wrote: > On Tue, Sep 20, 2011 at 12:01:18PM +0200, Stefan Sperling wrote: > > wscanf based on our scanf implementation. The delta from narrow > > to wide character support was obtained from FreeBSD and modified > > to fit our code. > > > > Does not include a libc bump yet! > > Here are corresponding libstdc++ changes, also without bumps. > > The gcc3 version will have to be revisited once we also get wcsftime. > But for now it should work like this (the configure script doesn't define > _GLIBCPP_USE_WCHAR_T unless it finds all wchar functions it wants). > > Not sure if the c_compatibility change is really needed. > We didn't update it for wprintf (by accident?) > > As with wprintf, no actual changes for gcc2 -- we'll just bump the lib > for safety. > > Can someone run this (together with the libc wscanf diff) through a build > on gcc2 and gcc3 architectures? Fwiw, this went on a full amd64 bulk build without issues in the ports tree. Yay! Landry
Re: md5: new -C flag to skip non-existent files in checklist
On Thu, Feb 23, 2012 at 08:16:20AM +, Nicholas Marriott wrote: > Hi > > Is this really much more useful than 2>/dev/null? Yes, return code would be 0 if all present files match... Landry
Re: -not for find(1)
On Mon, Feb 27, 2012 at 03:24:05PM -0430, Andres Perera wrote: > linux does > > worth pointing out that some tests in old firefox ports (maybe still > there) failed because the lack of -not Are you thinking about https://bugzilla.mozilla.org/show_bug.cgi?id=665040 ? Anyway, i think that was the only occurence of -not, since grep -r -- ' \-not' * in mozilla-central yields nothing. Landry > On Mon, Feb 27, 2012 at 3:01 PM, Ted Unangst wrote: > > On Mon, Feb 27, 2012, Steffen Daode Nurpmeso wrote: > >> this patch adds the -not operator to find(1). > >> I personally always found -not easier to use due to shell > >> escaping, but today may laziness has bitten back. > >> And "it's just one more non-POSIX-compliant option". > > > > This makes a lot of sense to me, but it's good to research what other > > systems support the same option. B Linux, FreeBSD, and Solaris are > > worthy references.
Re: latest sparc64 snapshot crashes on boot on a Blade 100
On Thu, Mar 15, 2012 at 08:53:17PM +0100, Markus Lude wrote:
> Hello,
>
> today I tried to upgrade my SUN Blade 100 to the latest sparc64
> snapshot. After rebooting it crashed. dmesgs below.
And it crashes too on hppa, with a similar trace..
>> OpenBSD/hppa BOOT 1.2
boot>
booting dk6a:/bsd: 4177920+1245184+606208 [89+202480+185653]=0x6a2e70
SPID bits: 0xfe0, error = 0
pdc_coproc: 0xc0, 0xc0; model 13 rev 1
WARNING: BTLB purge failed
WARNING: cannot block map kernel text
[ using 388720 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2012 OpenBSD. All rights reserved. http://www.OpenBSD.org
uvm_km_kmem_grow: grown to 0xef00
OpenBSD 5.1-current (GENERIC.MP) #122: Wed Mar 14 21:29:29 MDT 2012
dera...@hppa.openbsd.org:/usr/src/sys/arch/hppa/compile/GENERIC.MP
HP 9000/785/J6700 (Duet W2) PA-RISC 2.0a
real mem = 2147483648 (2048MB)
rsvd mem = 524288 (512KB)
avail mem = 2100035584 (2002MB)
panic: kernel diagnostic assertion "prev->etype & UVM_ET_FREEMAPPED" failed:
file "../../../../uvm/uvm_addr.c", line 675
Stopped at Debugger+0x18: break 0,5
Debugger(5b82cc,c,60,723144) at Debugger+0x18
panic(5c2884,5bad20,5cd5cc,5cd3fc) at panic+0xfc
panic(46b6d4,1ae730,46b790,c2361c20) at panic+0xd4
__assert(1b8b9c,f8df34,69a4e0,7dc74b98) at __assert+0x40
uaddr_rnd_insert(c,7dc64000,69a4e0,9) at uaddr_rnd_insert+0xec
uvm_mapent_free_insert(f17c,f174,f8df2c,69a180) at uvm_mapent_free_inse
rt+0x98
uvm_map_fix_space(699e60,ff8008,f8df44,f8e7ac) at uvm_map_fix_space+0x288
uvm_map_setup_entries(632b0c,8,699fd0,69a280) at uvm_map_setup_entries+0x30
uvm_map_setup(5d15f0,504ce4,10,0) at uvm_map_setup+0x188
uvmspace_init(5cba900b,e499dde7,ae5d4805,f24ceef3) at uvmspace_init+0x90
main+0x4f8:
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS, TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{0}> trace
Debugger(5b82cc,c,60,723144) at Debugger+0x18
panic(5c2884,5bad20,5cd5cc,5cd3fc) at panic+0xfc
panic(46b6d4,1ae730,46b790,c2361c20) at panic+0xd4
__assert(1b8b9c,f8df34,69a4e0,7dc74b98) at __assert+0x40
uaddr_rnd_insert(c,7dc64000,69a4e0,9) at uaddr_rnd_insert+0xec
uvm_mapent_free_insert(f17c,f174,f8df2c,69a180) at uvm_mapent_free_inse
rt+0x98
uvm_map_fix_space(699e60,ff8008,f8df44,f8e7ac) at uvm_map_fix_space+0x288
uvm_map_setup_entries(632b0c,8,699fd0,69a280) at uvm_map_setup_entries+0x30
uvm_map_setup(5d15f0,504ce4,10,0) at uvm_map_setup+0x188
uvmspace_init(5cba900b,e499dde7,ae5d4805,f24ceef3) at uvmspace_init+0x90
main(0,0,0,0) at main+0x4f8
-- trap #0
$start+0x164:
Re: cvs, stop ignoring *@#%&@# files/directories named core
On Tue, Mar 20, 2012 at 10:07:35AM +, Stuart Henderson wrote: > core dumps on OpenBSD are not named 'core' anyway so ignoring them > is pointless and gets in the way. Why not making it '*.core' so it actually matches better the coredump files ? Landry
Re: c++ headers w/ -pedantic, overflow in implicit constant conversion
On Thu, Mar 15, 2012 at 11:19:43AM +0100, Marc Espie wrote:
> On Thu, Mar 15, 2012 at 01:39:18AM +, Stuart Henderson wrote:
> > $ c++ -pedantic -c a.c
> > In file included from /usr/include/g++/memory:60,
> > from /usr/include/g++/string:48,
> > from a.c:1:
> > /usr/include/g++/limits: In static member function 'static char
> > std::numeric_limits::min()':
> > /usr/include/g++/limits:375: warning: overflow in implicit constant
> > conversion
> > /usr/include/g++/limits: In static member function 'static wchar_t
> > std::numeric_limits::max()':
> > /usr/include/g++/limits:530: warning: overflow in implicit constant
> > conversion
>
> It's not even fixed in gcc 4.6.2, not fully anyways.
>
> The following patch might work, it really needs to be read by people who
> understand this
>
> - the max warning comes from gcc 4.6.2, this one should be fine.
> - the min warning affects the specialization for char, but char is
> either signed char or unsigned char, so we can borrow the specializations
> from those types. Preferably directly, to avoid duplication. Obviously,
> gcc will whine at having definitions in the wrong order, so it's possible
> to reorder things to avoid that as well.
>
> Please test. I've "fixed" limits directly, then backfitted the patch to
> the right src file (been a while since I hacked on this), and I hope it's
> correct.
Can this be reviewed/commited ? Those warnings are really annoying and
hide real errors/warnings.
Landry
> Index: std_limits.h
> ===
> RCS file: /cvs/src/gnu/gcc/libstdc++-v3/include/std/std_limits.h,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 std_limits.h
> --- std_limits.h 15 Oct 2009 17:11:32 - 1.1.1.1
> +++ std_limits.h 15 Mar 2012 10:16:04 -
> @@ -137,7 +137,9 @@
>(__glibcxx_signed (T) ? (T)1 << __glibcxx_digits (T) : (T)0)
>
> #define __glibcxx_max(T) \
> - (__glibcxx_signed (T) ? ((T)1 << __glibcxx_digits (T)) - 1 : ~(T)0)
> + (__glibcxx_signed (T) ? \
> + (T)1 << (__glibcxx_digits (T) - 1)) - 1) << 1) + 1) : ~(T)0)
> +
>
> #define __glibcxx_digits(T) \
>(sizeof(T) * __CHAR_BIT__ - __glibcxx_signed (T))
> @@ -365,57 +367,6 @@ _GLIBCXX_BEGIN_NAMESPACE(std)
>static const float_round_style round_style = round_toward_zero;
> };
>
> - /// numeric_limits specialization.
> - template<>
> -struct numeric_limits
> -{
> - static const bool is_specialized = true;
> -
> - static char min() throw()
> - { return __glibcxx_min(char); }
> - static char max() throw()
> - { return __glibcxx_max(char); }
> -
> - static const int digits = __glibcxx_digits (char);
> - static const int digits10 = __glibcxx_digits10 (char);
> - static const bool is_signed = __glibcxx_signed (char);
> - static const bool is_integer = true;
> - static const bool is_exact = true;
> - static const int radix = 2;
> - static char epsilon() throw()
> - { return 0; }
> - static char round_error() throw()
> - { return 0; }
> -
> - static const int min_exponent = 0;
> - static const int min_exponent10 = 0;
> - static const int max_exponent = 0;
> - static const int max_exponent10 = 0;
> -
> - static const bool has_infinity = false;
> - static const bool has_quiet_NaN = false;
> - static const bool has_signaling_NaN = false;
> - static const float_denorm_style has_denorm = denorm_absent;
> - static const bool has_denorm_loss = false;
> -
> - static char infinity() throw()
> - { return char(); }
> - static char quiet_NaN() throw()
> - { return char(); }
> - static char signaling_NaN() throw()
> - { return char(); }
> - static char denorm_min() throw()
> - { return static_cast(0); }
> -
> - static const bool is_iec559 = false;
> - static const bool is_bounded = true;
> - static const bool is_modulo = true;
> -
> - static const bool traps = __glibcxx_integral_traps;
> - static const bool tinyness_before = false;
> - static const float_round_style round_style = round_toward_zero;
> -};
> -
>/// numeric_limits specialization.
>template<>
> struct numeric_limits
> @@ -508,6 +459,61 @@ _GLIBCXX_BEGIN_NAMESPACE(std)
>{ return static_cast(0); }
>static unsigned char denorm_min() throw()
>{ return static_cast(0); }
> +
> + static const bool is_iec559 = false;
> + static const bool is_bounded = true;
> + static const bool is_modulo = true;
> +
> + static const bool traps = __glibcxx_integral_traps;
> + static const bool tinyness_before = false;
> + static const float_round_style round_style = round_toward_zero;
> +};
> +
> + /// numeric_limits specialization.
> + template<>
> +struct numeric_limits
> +{
> + static const bool is_specialized = true;
> +
> +
Re: tar -J to extract xz archives
On Tue, May 29, 2012 at 09:19:49PM -0400, Ted Unangst wrote: > On Tue, May 29, 2012 at 17:46, Gabriel Linder wrote: > > I see more and more tar.xz archives, and thought it would be nice to > > have tar able to extract them directly as with gzip/bzip2. > > > > -J is what GNU and FreeBSD use, so I used it too. Based on what was done > > to add bzip2 support. > > So I never quite finished it in time before the -j patch went in, but > I think tar should just auto detect the compression and use the right > program. It requires reading about two bytes out of the stream. It's > a little tricky if the data is piped in, but I don't think it's > intractable. > > So -z would just always do the right thing. I think that's a better > way to do it. Not an argument per se, but gtar uses -a/--auto-compress for that "mode". And it even see to be default if no compression scheme is specified, ie 'gtar tf' and 'gtar xf' do the right thing (tm). See http://petereisentraut.blogspot.com/2012/05/time-to-retrain-fingers.html and the associated comments.. Landry
Re: sqlite secure delete
On Tue, Jul 24, 2012 at 08:20:55PM -0400, Ted Unangst wrote: > I think this option should be available. > > Index: Makefile > === > RCS file: /cvs/src/lib/libsqlite3/Makefile,v > retrieving revision 1.8 > diff -u -p -r1.8 Makefile > --- Makefile 22 Jun 2012 17:52:34 - 1.8 > +++ Makefile 24 Jul 2012 11:42:51 - > @@ -40,6 +40,7 @@ SRCS += pthread_stub.c > FEATURE_FLAGS = -DSQLITE_ENABLE_COLUMN_METADATA \ > -DSQLITE_ENABLE_RTREE \ > -DSQLITE_ENABLE_UNLOCK_NOTIFY \ > + -DSQLITE_SECURE_DELETE \ > -DSQLITE_ENABLE_FTS3 > > CPPFLAGS += $(FEATURE_FLAGS) -DSQLITE_THREADSAFE=1 \ Note sure it's a good idea, since it's a non-negligible performance loss for all sqlite users if you change it to default to true. For example all mozilla ports want it, and instead of trying to push it into the lib i've resorted to use 'PRAGMA secure_delete = ON' in the client code to selectively turn it no. See mozilla-firefox/patches/patch-storage_src_mozStorageConnection_cpp and https://bugzilla.mozilla.org/show_bug.cgi?id=546162 Landry
pdksh wrong strips quotes in shell substs
Hi,
in the context of https://bugzilla.mozilla.org/show_bug.cgi?id=781461
i've stumbled upon the following issue:
(our pdksh)
$cat < echo ${FOO:+'blah'aa}
> EOF
echo blahaa
bash-4.2# FOO=1
bash-4.2# cat < echo ${FOO:+'blah'aa}
> EOF
echo 'blah'aa
Apparently the ksh from solaris, hpux and debian don't strip the quotes
in that usecase, and none of the other shells do (bash, dash, zsh...)
So maybe it can be considered as a bug in our pdksh..
Landry
Re: cwm(1) windowspawn option
On Wed, Jul 22, 2009 at 6:14 PM, Thomas Pfaff wrote: > Here's another stab at the windowspawn global option. > > It allows you to control where new windows are placed and can > be one of center, cursor, fullscreen, or random. If it's not > specified, the default behaviour is used (cursor). > > It'd be nice if people could test this diff and provide some > feedback, such as "Yes, please" or "No, you moron!" ... I really like the idea, and support such a diff. Landry
Re: Thank you for making p2k9 possible!
On Fri, Oct 16, 2009 at 03:36:58AM +0300, Paul Irofti wrote: > Its been a great hackathon and I'd like to thank both robert and theo > for creating this opportunity for all of us to meet and work together. > Also thanks to everybody that keeps donating and buying CDs which make > such things possible. Yet again thank you for a great time here in > Budapest. Cheers! Add my word to this... p2k9 was as awesome and productive like the previous hackathons ! Lots of cleanups, updates & QA was done, and quite a good amount of new ports were added... Thanks again to robert for hosting us!
Re: azalia: converter channel names
On Tue, Oct 27, 2009 at 4:26 AM, Jacob Meuser wrote: > no comments? It looks more sane and explicit, i like it. Landry
Re: disklabel - 'P' option
On Thu, Apr 8, 2010 at 1:34 PM, Mark Lumsden wrote: >> When I use Disklabel, I have been in the habit of issuing 'p m ' >> rather than just 'p ' >> >> Since I do it for disk / usb thumb setups, and so forth, I find the >> 'megabyte-able' printing more consistent to my liking. >> > > Attached is an amended diff that allows the 'P' option to take an > argument just as the 'p' option does. > >> I'd say leave it out, since CHS information may get scrolled off the >> screen if it was relevant. (Or am I thinking fdisk...?) >> As it is, both 'p' and 'm' keys have less wear than 'e' 't' and 's' and >> make for good finger dexterity... >> > > That is the crux of the issue. For those of us who like to type less this > diff helps, for you people who like type more... you're weird ;) > > Anyway, with only one yay, I don't think this will progress much further. I like this too, fwiw. Landry
pf.conf(5) & reply-to
hi, on a carp setup with two external links (main & backup), i struggled a bit to accept traffic on the backup interface - after fiddling a bit in pf.conf and looking at the faq (https://www.openbsd.org/faq/upgrade69.html) & manpage (https://man.openbsd.org/pf.conf#reply-to) it wasnt super obvious to me that reply-to took *the ip of the nexthop on the backup link*. In the faq for 6.9 there's an example with (iface:peer) but to my understanding that only works for peer-to-peer interfaces (ppp? pppoe?), in my case that's a regular /29 with a remote, an ip for each carp host on em1 and a carp ip on carp1. since the manpage talks about _interface_ and says 'route all outgoing packets of a connection through the interface the incoming connection arrived through' that's a bit confusing, and after unsuccessfully trying reply-to em1 (the carpdev) reply-to carp1 i ended up with reply-to wanbackup_ip (eg none of my IPs) which works. did i screwup something somewhere in my config and there's a better way for that ? should the manpage be improved for reply-to and talk about 'destination address' instead of 'interface' like route-to does ? Landry
Re: pf.conf(5) & reply-to
Le Tue, Sep 21, 2021 at 10:40:12PM +0200, Sebastian Benoit a écrit : > Alexander Bluhm(alexander.bl...@gmx.net) on 2021.09.21 22:34:09 +0200: > > On Mon, Sep 20, 2021 at 03:54:58PM +0200, Landry Breuil wrote: > > > did i screwup something somewhere in my config and there's a better way > > > for that ? > > > > This was changed in February. No more interface, but gateway > > addresses. It seems that some parts of the documentation were > > missed. > > > > > should the manpage be improved for reply-to and talk about 'destination > > > address' instead of 'interface' like route-to does ? > > > > Yes. > > > > It looks like most information is in the commit message. > > https://marc.info/?l=openbsd-cvs&m=161213948819452&w=2 > > It's also on http://www.openbsd.org/faq/upgrade69.html my english sucks and i'm not sure i got the meaning right, but here's a try: Index: pf.conf.5 === RCS file: /cvs/src/share/man/man5/pf.conf.5,v retrieving revision 1.587 diff -u -r1.587 pf.conf.5 --- pf.conf.5 19 Jul 2021 16:23:56 - 1.587 +++ pf.conf.5 22 Sep 2021 09:23:14 - @@ -1103,13 +1103,14 @@ option is similar to .Cm route-to , but routes packets that pass in the opposite direction (replies) to the -specified interface. +specified address. Opposite direction is only defined in the context of a state entry, and .Cm reply-to is useful only in rules that create state. It can be used on systems with multiple external connections to -route all outgoing packets of a connection through the interface -the incoming connection arrived through (symmetric routing enforcement). +route all outgoing packets of a connection through the interface the incoming +connection arrived through (symmetric routing enforcement) via the address of +the gateway specified in the rule. .It Cm route-to The .Cm route-to i wouldnt know how to change the example in faq/upgrade69.html as it is valid (but only specific to the case of a point-to-point interface with a :peer property) ccing experts :)
Re: ucc: ignore get encoding requests
Le Wed, Oct 20, 2021 at 07:43:36AM +0200, Anton Lindqvist a écrit : > Hi, > landry@ reported that he ended up with the wrong encoding in X11 while > having a ucc keyboard attached and /etc/kbdtype being present. The > advertised encoding of a wsmux is a bit fragile as the last attached > device will dictate it. If this happens to be a ucc keyboard, KB_US will > always be the advertised encoding as its encoding is immutable and > /etc/kbdtype is ignored. > > Instead, do not advertise the encoding for ucc devices when the parent > mux queries its attached devices. However, asking the device directly > (i.e. bypassing the mux) still returns the encoding as wsconsctl(8) > would otherwise report an error. > > Comments? OK? fwiw i've tested this diff on my workplace desktop with a us kbd and a fr kbd both plugged in, /etc/kbdtype contains fr, and machdep.forceukbd=1. without the diff, previously i ended up with a us mapping in xenodm, and now i correctly have the fr mapping. i also tested that with machdep.forceukbd=0 and without the diff, i got the correct fr mapping too. thanks !
Re: use /dev/dri/ in xenocara
On Thu, Feb 18, 2021 at 11:11:15PM +1100, Jonathan Gray wrote: > On Thu, Feb 18, 2021 at 11:34:19AM +, Stuart Henderson wrote: > > On 2021/02/18 22:24, Jonathan Gray wrote: > > > On Thu, Feb 18, 2021 at 12:01:28PM +0100, Mark Kettenis wrote: > > > > > Date: Thu, 18 Feb 2021 21:18:51 +1100 > > > > > From: Jonathan Gray > > > > > > > > I suspect that there are some ports that need to get their unveils > > > > updated if we do this. > > > > > > firefox ports were updated. Not aware of anything else in ports that > > > unveils /dev/drm. > > > > unveils: not afaik > > > > others: gdm already handled it, some other ports will need patches changing: > > > > graphics/clutter/cogl/patches/patch-cogl_winsys_cogl-winsys-egl-kms_c > > graphics/waffle/patches/patch-src_waffle_gbm_wgbm_display_c > > x11/compton/patches/patch-src_compton_c > > x11/slim/patches/patch-slim_conf > > This is a display manager like xdm/gdm. The last upstream release was > in 2013. I can patch it after the xenocara changes go in or perhaps we > remove it as landry suggested in there's a less dead upstream at https://github.com/PeteGozz/slim. FreeBSD and debian still ship a package for slim :) I *might* have a look at updating the port to this github fork. Landry
Re: ping graphical display
On Fri, Feb 19, 2021 at 03:19:49PM +, Stuart Henderson wrote: > This diff adds something similar to cisco's ping display, giving a > visual display of good/dropped pings. Any interest in it? Example > output (with a couple of ^T during the run): fwiw, noping from net/liboping in ports has this feature builtin. Landry
Re: iwm(4): Tx aggregation
On Fri, Apr 30, 2021 at 12:03:41AM +0200, Stefan Sperling wrote: > This is another patch for Tx aggregation support in iwm(4). > I have tested 7265, 8265, and 9560, and they seem to work. > > Causes of various fatal firmware errors from my earlier attempts at > getting this to work have been identified and fixed in this version. > In particular, the AP starting and stopping Tx BA sessions repeatedly > was causing firmware crashes. And a frame header padding issue which > caused firmware crashes on 9k devices has been fixed. > > In my testing, tcpbench reports up to 100 Mbit/s both ways against > a pepwave 11ac AP, and games/chaiki is running smoothly at 720p. > > Tests on all types of iwm devices are welcome. works fine on iwm0 at pci2 dev 0 function 0 "Intel AC 7265" rev 0x59, msi iwm0: hw rev 0x210, fw ver 17.3216344376.0 tcpbench from this iwm0 client to an em0 server over an 'J9650A HP E-MSM430 Wireless Access Point' configured as bridge went from bandwidth min/avg/max/std-dev = 20.039/28.960/31.578/2.921 Mbps to 670720840 bytes sent over 59.047 seconds bandwidth min/avg/max/std-dev = 57.874/90.801/105.435/11.927 Mbps in the other direction (eg tcpbench -s on iwm0) i get this on a first 20s session: bandwidth min/avg/max/std-dev = 38.328/49.347/54.263/3.980 Mbps then a second 20s session gives: bandwidth min/avg/max/std-dev = 31.687/82.597/97.757/17.791 Mbps a third: bandwidth min/avg/max/std-dev = 60.839/88.534/101.340/10.263 Mbps so that looks pretty stable & solid, great stuff ! Thanks ! Landry
Re: Add 'video' pledge
On Thu, May 24, 2018 at 07:15:05PM +0200, Landry Breuil wrote:
> Hi,
>
> here's two simple diffs (one for the kernel, one for the pledge.2
> manpage) that allow me to use my webcam again within firefox when
> pledged,, adding 'video' to the main process pledges.
>
> The kernel changes are similar to what was done for 'audio' pledge, and
> i took the ioctl list from the ones found in the mozilla codebase:
> https://dxr.mozilla.org/mozilla-central/search?q=vidioc&redirect=false
>
> Comments and feedback welcome. Of course, to test it using firefox, you
> still need to grant your user access to /dev/video*.
After having been poked offline about why this diff hadnt been commited,
sending an updated diff including the pledge.h change, and updated after unveil
addition. Among other bits, you'll need this if you want to use webrtc in
firefox while being still pledged - the other solution right now is of course
disabling pledge, which is a pity.
I went over this for a while and i don't see how firefox could be adapted to
avoid this new pledge class. The other option is to move lots of code around so
that the video device is opened/configured inconditionally by the main process
before pledging (but then you'd still need the various ioctls getting buffers
etc), but that feels stupid: why would you want to open the video device if
you're not going to actually use it ?
Right now the devices are listed/opened *when* camera access is requested by
a page aiming to use the camera, ie during the process lifetime, so until
upstream decides to separate video device access in a separate process (which
isnt afaik on the radar) adding this pledge class is the only solution i see
for now.
That of course doesn't try to solve the video device access/ownership which is
a separate issue.
Feedback appreciated.
Index: sys/pledge.h
===
RCS file: /cvs/src/sys/sys/pledge.h,v
retrieving revision 1.37
diff -u -r1.37 pledge.h
--- sys/pledge.h13 Jul 2018 09:25:23 - 1.37
+++ sys/pledge.h25 Jul 2018 17:59:15 -
@@ -62,6 +62,7 @@
#define PLEDGE_ERROR 0x0004ULL /* ENOSYS instead of kill */
#define PLEDGE_WROUTE 0x0008ULL /* interface address ioctls */
#define PLEDGE_UNVEIL 0x0010ULL /* allow unveil() */
+#define PLEDGE_VIDEO 0x00200800ULL /* video ioctls */
/*
* Bits outside PLEDGE_USERSET are used by the kernel itself
@@ -112,6 +113,7 @@
{ PLEDGE_ERROR, "error" },
{ PLEDGE_WROUTE,"wroute" },
{ PLEDGE_UNVEIL,"unveil" },
+ { PLEDGE_VIDEO, "video" },
{ 0, NULL },
};
#endif
Index: kern/kern_pledge.c
===
RCS file: /cvs/src/sys/kern/kern_pledge.c,v
retrieving revision 1.237
diff -u -r1.237 kern_pledge.c
--- kern/kern_pledge.c 15 Jul 2018 12:44:09 - 1.237
+++ kern/kern_pledge.c 25 Jul 2018 17:59:15 -
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -396,6 +397,7 @@
{ "tty",PLEDGE_TTY },
{ "unix", PLEDGE_UNIX },
{ "unveil", PLEDGE_UNVEIL },
+ { "video", PLEDGE_VIDEO },
{ "vminfo", PLEDGE_VMINFO },
{ "vmm",PLEDGE_VMM },
{ "wpath", PLEDGE_WPATH },
@@ -1151,6 +1153,30 @@
break;
}
}
+
+ if ((p->p_p->ps_pledge & PLEDGE_VIDEO)) {
+ switch (com) {
+ case VIDIOC_QUERYCAP:
+ case VIDIOC_ENUM_FMT:
+ case VIDIOC_S_FMT:
+ case VIDIOC_G_PARM:
+ case VIDIOC_S_PARM:
+ case VIDIOC_REQBUFS:
+ case VIDIOC_QBUF:
+ case VIDIOC_DQBUF:
+ case VIDIOC_QUERYBUF:
+ case VIDIOC_STREAMON:
+ case VIDIOC_STREAMOFF:
+ case VIDIOC_ENUM_FRAMESIZES:
+ case VIDIOC_ENUM_FRAMEINTERVALS:
+ if (fp->f_type == DTYPE_VNODE &&
+ vp->v_type == VCHR &&
+ cdevsw[major(vp->v_rdev)].d_open == videoopen)
+ return (0);
+ break;
+ }
+ }
+
#if NPF > 0
if ((p->p_p->ps_pledge & PLEDGE_PF)) {
Re: Add 'video' pledge
On Wed, Jul 25, 2018 at 12:29:10PM -0600, Theo de Raadt wrote: > >I went over this for a while and i don't see how firefox could be adapted to > >avoid this new pledge class. The other option is to move lots of code around > >so > >that the video device is opened/configured inconditionally by the main > >process > >before pledging (but then you'd still need the various ioctls getting buffers > >etc), but that feels stupid: why would you want to open the video device if > >you're not going to actually use it ? > > Most privsep programs contain a process which isn't pledged. Except the privsep programs usually follow a model of 'a master process doing init, opening priviledged devices, then orchestrating the others/passing fds'. Here, we're talking about the main firefox process, which does shitloads of things, among those orchestrate the content processes, but also & mostly filesystem access, network access, etc, etc . You'd prefer having it unpledged ? I don't understand your argument here. > >That of course doesn't try to solve the video device access/ownership which > >is > >a separate issue. > > I fear it solves no issues at all. > > As I said before, I am uncomfortable pushing this policy mechanism into > the kernel to be used by *only one program*. I never said it was *only* for firefox. Right now, any program using the v4l api can't be pledged or then loses the ability to talk to the camera device. Ok, in base there's only video(1), but in ports there's mplayer, ffmpeg, vlc, gstreamer, sane, etc.. I know blindly adding pledge everywhere in the ports tree isnt a primary target, but i think huge programs with big attack surface (like all the video players) would be good contenders. I'm not volunteering for them, but i'd like to allow OpenBSD users to 'easily' use video chat in their browser, without having to resort to skype or hangouts on their jesus laptops, or to go through knobs to disable pledge. > Sorry, but that isn't how pledge is developed / extended. I thought it was developed by experimenting with things, and then iterating on them. As far as i see from the cvs log for the pledge kernel subsystem and the basesystem programs conversion, that's how it was developed. Start with a set of syscalls subsets, then add a new syscall to a subset when needed because it's a valid usecase (or change the program behaviour to hoist the syscall usage), or separate a set of syscalls in a new class. I don't see how different the video pledge i'm proposing is from the other classes of syscalls that were added for bpf/drm/tape/audio/disklabel/pf/tty/route. They were all added to allow for a subset of ioctls on a particular type of device. How is my approach different here ?
nmea(4): support GNRMC messages sent by gps devices supporting multiple networks
Hi, was playing with an usb gps that works ootb with gpsd, but our nmea line discipline doesnt recognize it, and the 'indicator' sensor stays at its default 'unknown'. The gps is a navilock nl-8002u: umodem0 at uhub3 port 2 configuration 1 interface 0 "u-blox AG - www.u-blox.com u-blox GNSS receiver" rev 1.10/2.01 addr 2 umodem0: data interface 1, has CM over data, has no break umodem0: status change notification available ucom1 at umodem0 The RMC message our tty_nmea.c code looks for is like this w/ this device: $GNRMC,194858.00,A,,N,yyy,E,0.236,,290818,,,A*6E Turns out the NMEA 0183 spec says that RMC message types are prefixed by various codes for 'talkers' which says if the data comes from GPS (GP), Glonass (GL), Galileo (GA), Beidou (BD), or 'Global navigation satellite' (GN) for the 'generic term' (cf http://freenmea.net/docs or https://github.com/mvglasow/satstat/wiki/NMEA-IDs) and mine uses GNRMC, while tty_nmea.c looks for GPRMC. Poking at the string comparison, i finally have sensors working: $doas ldattach -d nmea /dev/cuaU1 ldattach[93876]: attach nmea on /dev/cuaU1 hw.sensors.nmea0.indicator0=On (Signal), OK hw.sensors.nmea0.timedelta0=0.031653 secs (GPS autonomous), OK, Wed Aug 29 21:48:52.031 hw.sensors.nmea0.angle0=xx degrees (Latitude), OK hw.sensors.nmea0.angle1=yy degrees (Longitude), OK ntpd thinks the sensor is invalid, but that's for more poking later. $ntpctl -s Sensors sensor wt gd st next poll offset correction nmea0 1 0 02s 15s - sensor not valid - So here's the diff.. i wonder if we should just match the 3 chars for the 'RMC' message. Index: tty_nmea.c === RCS file: /cvs/src/sys/kern/tty_nmea.c,v retrieving revision 1.46 diff -u -r1.46 tty_nmea.c --- tty_nmea.c 19 Feb 2018 08:59:52 - 1.46 +++ tty_nmea.c 29 Aug 2018 19:49:24 - @@ -261,7 +261,7 @@ } /* we only look at the GPRMC message */ - if (strcmp(fld[0], "GPRMC")) + if (strcmp(fld[0], "GPRMC") && strcmp(fld[0], "GNRMC")) return; /* if we have a checksum, verify it */
Re: nmea(4): support GNRMC messages sent by gps devices supporting multiple networks
On Wed, Aug 29, 2018 at 02:13:01PM -0600, Theo de Raadt wrote: > Landry Breuil wrote: > > > Hi, > > > > was playing with an usb gps that works ootb with gpsd, but our nmea line > > discipline doesnt recognize it, and the 'indicator' sensor stays at its > > default 'unknown'. > > > > The gps is a navilock nl-8002u: > > umodem0 at uhub3 port 2 configuration 1 interface 0 "u-blox AG - > > www.u-blox.com u-blox GNSS receiver" rev 1.10/2.01 addr 2 > > umodem0: data interface 1, has CM over data, has no break > > umodem0: status change notification available > > ucom1 at umodem0 > > > > The RMC message our tty_nmea.c code looks for is like this w/ this device: > > $GNRMC,194858.00,A,,N,yyy,E,0.236,,290818,,,A*6E > > > > Turns out the NMEA 0183 spec says that RMC message types are prefixed by > > various > > codes for 'talkers' which says if the data comes from GPS (GP), Glonass > > (GL), > > Galileo (GA), Beidou (BD), or 'Global navigation satellite' (GN) for the > > 'generic term' (cf http://freenmea.net/docs or > > https://github.com/mvglasow/satstat/wiki/NMEA-IDs) and mine uses GNRMC, > > while > > tty_nmea.c looks for GPRMC. > > > > Poking at the string comparison, i finally have sensors working: > > > > $doas ldattach -d nmea /dev/cuaU1 > > ldattach[93876]: attach nmea on /dev/cuaU1 > > > > hw.sensors.nmea0.indicator0=On (Signal), OK > > hw.sensors.nmea0.timedelta0=0.031653 secs (GPS autonomous), OK, Wed Aug 29 > > 21:48:52.031 > > hw.sensors.nmea0.angle0=xx degrees (Latitude), OK > > hw.sensors.nmea0.angle1=yy degrees (Longitude), OK > > > > ntpd thinks the sensor is invalid, but that's for more poking later. > > > > $ntpctl -s Sensors > > sensor > >wt gd st next poll offset correction > > nmea0 > > 1 0 02s 15s - sensor not valid - > > > > So here's the diff.. i wonder if we should just match the 3 chars for the > > 'RMC' > > message. > > I think it should match all the currently known ones, including the first > two characters. Well, let's match on the 5 'most common' used, otherwise there's many more.. cf http://www.catb.org/gpsd/NMEA.html#_talker_ids Would there be interest in adding support for speed/elevation to sensors provided by nmea(4) ? As the data is available anyway on the wire.. (altitude in the GGA messages, and RMC has the ground speed in knots) Index: tty_nmea.c === RCS file: /cvs/src/sys/kern/tty_nmea.c,v retrieving revision 1.46 diff -u -r1.46 tty_nmea.c --- tty_nmea.c 19 Feb 2018 08:59:52 - 1.46 +++ tty_nmea.c 30 Aug 2018 05:46:29 - @@ -260,8 +260,20 @@ } } - /* we only look at the GPRMC message */ - if (strcmp(fld[0], "GPRMC")) + /* +* we only look at the RMC message, which can come from different 'talkers', +* distinguished by the two-chars prefix, the most common being: +* GPS (GP) +* Glonass (GL) +* BeiDou (BD) +* Galileo (GA) +* 'Any kind/a mix of GNSS systems' (GN) +*/ + if (strcmp(fld[0], "BDRMC") && + strcmp(fld[0], "GARMC") && + strcmp(fld[0], "GLRMC") && + strcmp(fld[0], "GNRMC") && + strcmp(fld[0], "GPRMC")) return; /* if we have a checksum, verify it */
Re: iostat: add "sp" column for CP_SPIN
On Tue, Sep 04, 2018 at 03:27:29PM +0200, Solene Rapenne wrote: > Stuart Henderson wrote: > > On 2018/09/04 14:22, Solene Rapenne wrote: > > > About munin I'm trying to get a diff accepted upstream to fix cpu plugin > > > and > > > talk about this with kirby@. The cpu plugin uses sysctl kern.cp_time. > > > While > > > it's not related, I prefer to announce it here so people don't waste time > > > fixing it again by looking at the thread :) > > > > Ah nice. When I worked on the initial munin port with mk I had intended > > to try to get upstream to take the openbsd plugins separately (rather > > than the current "copy similar OS and patch" approach), but I got fed up > > with rrdtool performance on OpenBSD and stopped using munin before I got > > round to it.. (and then I started using librenms and got fed up with > > rrdtool performance once again ;) > > Using rrdcached the performances are really good. But that certainly depend on > the number of systems. It may not scale well with more than 50 systems, this > is > also highly dependent on the number of plugins on each systems (as 1 value = 1 > rrd file). Seconded, rrdcached really helps a lot until you have waaayyy too many rrds, and then switch to a real tsdb (hint: influxdb is in ports)
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 nmea_decode_gsa(stru
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(&v, "%.2f", s->value / 1000.0);
break;
case SENSOR_DISTANCE:
+ case SENSOR_ALTITUDE:
+ case SENSOR_SPEED:
case SENSOR_PRESSURE:
ret = asprintf(&v, "%.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);
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: 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(&v, "%.2f", s->value / 100.0);
break;
case SENSOR_INDICATOR:
@@ -2658,7 +2660,6 @@
case SENSOR_HUMIDITY:
ret = asprintf(&v, "%.2f", s->value / 1000.0);
break;
- case SENSOR_DISTANCE:
case SENSOR_PRESSURE:
ret = asprintf(&v, "%.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);
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(&np->timedev, &np->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(&np->timedev, &np->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(&np->timedev, &np->speed);
+
+
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.
Re: NMEA: add more gps sensor values (altitude, precision...)
On Sat, Nov 03, 2018 at 06:21:38PM -0400, Ted Unangst wrote: > 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? We're talking about the internal unit here, and afaict using um/s would be consistent with distance which is in um per sensors.h: SENSOR_DISTANCE,/* distance (uMeter) */ SENSOR_ACCEL, /* acceleration (u m/s^2) */ SENSOR_VELOCITY,/* velocity (u m/s) */
Re: pvclock(4)
On Mon, Nov 19, 2018 at 01:12:46PM +0100, Reyk Floeter wrote: > Hi, > > the attached diff is another attempt at implementing a pvclock(4) > guest driver. This improves the clock on KVM and replaces the need > for using the VM-expensive acpihpet(4). > > While pvclock(4) is available on KVM, Xen, Hyper-V (in a modified > form), it currently only attaches under KVM: > > pvbus0 at mainbus0: KVM > pvclock0 at pvbus0 Works fine on my proxmox 5.2 / KVM 2.11 dpb build cluster emulating 6x "QEMU Standard PC (Q35 + ICH9, 2009)". Before i had to restart ntpd every 5mn on each hosts, time would drift like crazy under build load. With pvclock it seems the slave clocks are stable and ntpd stays synced. kern.timecounter.tick=1 kern.timecounter.timestepwarnings=0 kern.timecounter.hardware=pvclock0 kern.timecounter.choice=i8254(0) pvclock0(1500) acpihpet0(1000) acpitimer0(1000) dummy(-100) Landry OpenBSD 6.4-current (GENERIC.MP) #0: Tue Nov 20 18:52:03 CET 2018 landry@c64.proxmox2:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4276924416 (4078MB) avail mem = 4138016768 (3946MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5970 (10 entries) bios0: vendor SeaBIOS version "rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org" date 04/01/2014 bios0: QEMU Standard PC (Q35 + ICH9, 2009) acpi0 at bios0: rev 0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP APIC HPET MCFG acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Common KVM processor, 2933.90 MHz, 0f-06-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF,MELTDOWN cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 999MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Common KVM processor, 2933.54 MHz, 0f-06-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF,MELTDOWN cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpihpet0 at acpi0: 1 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xb000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method no _STA method acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) "ACPI0006" at acpi0 not configured acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 "PNP0A06" at acpi0
Re: pvclock(4)
On Thu, Nov 22, 2018 at 07:44:01AM -0800, Mike Larkin wrote: > On Thu, Nov 22, 2018 at 04:37:49PM +0100, Reyk Floeter wrote: > > On Mon, Nov 19, 2018 at 01:12:46PM +0100, Reyk Floeter wrote: > > > the attached diff is another attempt at implementing a pvclock(4) > > > guest driver. This improves the clock on KVM and replaces the need > > > for using the VM-expensive acpihpet(4). > > > > > > > So far I only got positive reports. Where are the problems? ;) > > > > Otherwise: OK? > > > > Reyk > > > > Reads ok. One question - you mention in pvclock.c that this is supported > on i386 and amd64 but I only see GENERIC changes for amd64? > > ok mlarkin in any case, but I'd either add GENERIC changes for i386 or > make this for sure amd64 only. I'm giving it a shot on my i386 vm.
Re: pvclock(4)
On Thu, Nov 22, 2018 at 05:24:10PM +0100, Landry Breuil wrote:
> On Thu, Nov 22, 2018 at 07:44:01AM -0800, Mike Larkin wrote:
> > On Thu, Nov 22, 2018 at 04:37:49PM +0100, Reyk Floeter wrote:
> > > On Mon, Nov 19, 2018 at 01:12:46PM +0100, Reyk Floeter wrote:
> > > > the attached diff is another attempt at implementing a pvclock(4)
> > > > guest driver. This improves the clock on KVM and replaces the need
> > > > for using the VM-expensive acpihpet(4).
> > > >
> > >
> > > So far I only got positive reports. Where are the problems? ;)
> > >
> > > Otherwise: OK?
> > >
> > > Reyk
> > >
> >
> > Reads ok. One question - you mention in pvclock.c that this is supported
> > on i386 and amd64 but I only see GENERIC changes for amd64?
> >
> > ok mlarkin in any case, but I'd either add GENERIC changes for i386 or
> > make this for sure amd64 only.
>
> I'm giving it a shot on my i386 vm.
Also seems to work fine there, i'm stressing the vm (well,
unpacking tarball/building firefox) and ntpd still manages to reduce the drift:
[17:49] c32:~/ $while sleep 10 ; do ntpctl -sa|grep clock ; date ; done
4/4 peers valid, constraint offset -1s, clock unsynced, clock offset is
404.382ms
Thu Nov 22 17:49:49 CET 2018
4/4 peers valid, constraint offset -1s, clock unsynced, clock offset is
354.382ms
Thu Nov 22 17:49:59 CET 2018
4/4 peers valid, constraint offset -1s, clock unsynced, clock offset is
304.382ms
Thu Nov 22 17:50:09 CET 2018
4/4 peers valid, constraint offset -1s, clock unsynced, clock offset is
254.382ms
Thu Nov 22 17:50:19 CET 2018
4/4 peers valid, constraint offset -1s, clock unsynced, clock offset is
204.382ms
Thu Nov 22 17:50:29 CET 2018
4/4 peers valid, constraint offset -1s, clock unsynced, clock offset is
154.382ms
Thu Nov 22 17:50:39 CET 2018
4/4 peers valid, constraint offset -1s, clock unsynced, clock offset is
104.382ms
Thu Nov 22 17:50:49 CET 2018
4/4 peers valid, constraint offset -1s, clock unsynced, clock offset is
54.382ms
Thu Nov 22 17:50:59 CET 2018
4/4 peers valid, constraint offset -1s, clock unsynced
Thu Nov 22 17:51:09 CET 2018
4/4 peers valid, constraint offset -1s, clock unsynced
Thu Nov 22 17:51:19 CET 2018
4/4 peers valid, constraint offset -1s, clock synced, stratum 3
Thu Nov 22 17:51:29 CET 2018
dunno how valid a testcase this is
dmesg below, this time emulating a QEMU Standard PC (i440FX + PIIX, 1996)
Landry
OpenBSD 6.4-current (GENERIC.MP) #4: Thu Nov 22 17:40:05 CET 2018
landry@c32.proxmox2:/usr/src/sys/arch/i386/compile/GENERIC.MP
real mem = 3220561920 (3071MB)
avail mem = 3146719232 (3000MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 06/23/99, BIOS32 rev. 0 @ 0xfd2b1, SMBIOS rev. 2.8 @
0xf5980 (10 entries)
bios0: vendor SeaBIOS version
"rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org" date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP APIC HPET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Common KVM processor ("GenuineIntel" 686-class) 2.94 GHz, 0f-06-01
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 999MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Common KVM processor ("GenuineIntel" 686-class) 2.94 GHz, 0f-06-01
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF,MELTDOWN
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpihpet0 at acpi0: 1 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
"ACPI0006" at acpi0 not configured
"PNP0A03" at acpi0 not configured
acpicmos0 at acpi0
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"QEMU0002" at acpi0 not configured
"ACPI0010" at acpi0 not configured
bios0: RO
add velocity sensor type, change distance unit
Hi,
followup on a diff from last month, updated to -current:
- adds SENSOR_VELOCITY, internal unit um/s, display unit m/s
- changes SENSOR_DISTANCE to display as meters, with 3 decimals
which gives:
hw.sensors.nmea0.distance0=335.600 m (Altitude), OK
hw.sensors.nmea0.velocity0=18.337 m/s (Ground speed), OK
should the LAST-UPDATED field in the snmp sensors mib be updated to the
commit date ?
looking for okays so that i can make progress on the nmea changes for
altitude/speed.
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 8 Dec 2018 09:51:00 -
@@ -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 8 Dec 2018 09:51:00 -
@@ -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.91
diff -u -r1.91 mib.c
--- usr.sbin/snmpd/mib.c31 Aug 2018 05:20:36 - 1.91
+++ usr.sbin/snmpd/mib.c8 Dec 2018 09:51:06 -
@@ -2658,7 +2658,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 *
@@ -2690,6 +2690,8 @@
case SENSOR_LUX:
case SENSOR_FREQ:
case SENSOR_ACCEL:
+ case SENSOR_VELOCITY:
+ case SENSOR_DISTANCE:
ret = asprintf(&v, "%.2f", s->value / 100.0);
break;
case SENSOR_INDICATOR:
@@ -2699,7 +2701,6 @@
case SENSOR_HUMIDITY:
ret = asprintf(&v, "%.2f", s->value / 1000.0);
break;
- case SENSOR_DISTANCE:
case SENSOR_PRESSURE:
ret = asprintf(&v, "%.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.c8 Dec 2018 09:51:06 -
@@ -692,7 +692,7 @@
snprintf(fbuf, RFBUFSIZ, "%lld", value);
break;
case SENSOR_DISTANCE:
- snprintf(fbuf, RFBUFSIZ, "%.2f mm", value / 1000.0);
+ snprintf(fbuf, RFBUFSIZ, "%.3f 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:
case SENSOR_FREQ:
case SENSOR_ACCEL:
+ case SENSOR_DISTANCE:
+ case SENSOR_VELOC
Re: undocumented nfs mount option "intr"
On Thu, Dec 20, 2018 at 09:26:33AM +0100, Solene Rapenne wrote: > Hi > > fstab(5) has an example for a nfs mountpoint using the "intr" option. > > That option isn't documented in mount(8) or mount_nfs(8) and in fact, I've not > been able to find it anywhere. What is it doing? I think it's the fstab shortcut for -i option in mount_nfs(8).
video(1) pledge (& updated kernel diff)
Hi,
so i've updated my 'video' class for pledge and also did an initial
naive pledging of xenocara/app/video:
the kernel diff is the same subset as the diff from some months ago,
except that it adds:
- VIDIOC_QUERYCTRL/VIDIOC_G_CTRL/VIDIOC_S_CTRL: those 3 are used by
video(1) to set gamma/contrast/etc controls on the device on the fly
(via A/a, B/b, C/c - etc when running)
- VIDIOC_TRY_FMT, used by
https://searchfox.org/mozilla-central/source/media/webrtc/trunk/webrtc/modules/video_capture/linux/device_info_linux.cc#418
since https://bugzilla.mozilla.org/show_bug.cgi?id=1376873 (yes, i
checked with ktrace, all the other ioctls are still used)
with that kernel diff, i'm able to record video in firefox with the
video pledge added to the main process.
as for the video(1) diff:
- fixed a typo
- renamed err to errs to avoid shadowing err()
and i've identified 4 main modes:
- -o needs to write to the fs (so wpath cpath) and read from the device
(so video)
- -O needs the same subset and dns unix in addition, as it talks to Xv
- -i only needs rpath & dns/unix for xv, no access to the video device
needed
- no option needs dns unix for xv, video for ioctls, and wpath as the
video device is open with O_RDWR.
tested those 4 modes without aborts so far, video -q exits before
reaching pledge. Not sure if those pledge calls are at the best spot,
but that's a start.
I know video(1) sucks and doesnt work directly with Xv with most modern
builtin devices on laptops as they often dont support the few encodings
supported by video(1) for Xv, but with my old-school cameras lying
around it works fine.
Landry
? ktrace.out
? video
? video.d
Index: video.c
===
RCS file: /cvs/xenocara/app/video/video.c,v
retrieving revision 1.25
diff -u -r1.25 video.c
--- video.c 9 Apr 2018 18:16:44 - 1.25
+++ video.c 28 Dec 2018 20:22:36 -
@@ -1854,7 +1854,7 @@
struct xdsp *x = &vid.xdsp;
const char *errstr;
size_t len;
- int ch, err = 0;
+ int ch, errs = 0;
bzero(&vid, sizeof(struct video));
@@ -1872,21 +1872,21 @@
x->cur_adap = strtonum(optarg, 0, 4, &errstr);
if (errstr != NULL) {
warnx("Xv adaptor '%s' is %s", optarg, errstr);
- err++;
+ errs++;
}
break;
case 'e':
vid.enc = find_enc(optarg);
if (vid.enc >= ENC_LAST) {
warnx("encoding '%s' is invalid", optarg);
- err++;
+ errs++;
}
break;
case 'f':
len = strlcpy(d->path, optarg, sizeof(d->path));
if (len >= sizeof(d->path)) {
warnx("file path is too long: %s", optarg);
- err++;
+ errs++;
}
break;
case 'g':
@@ -1894,8 +1894,8 @@
break;
case 'i':
if (vid.mode & (M_IN_FILE | M_OUT_FILE)) {
- warnx("only one input or ouput file allowed");
- err++;
+ warnx("only one input or output file allowed");
+ errs++;
} else {
vid.mode = (vid.mode & ~M_IN_DEV) | M_IN_FILE;
vid.mmap_on = 0; /* mmap mode does not work for
files */
@@ -1904,15 +1904,15 @@
if (len >= sizeof(vid.iofile)) {
warnx("input path is too long: %s",
optarg);
- err++;
+ errs++;
}
}
break;
case 'o':
case 'O':
if (vid.mode & (M_IN_FILE | M_OUT_FILE)) {
- warnx("only one input or ouput file allowed");
- err++;
+ warnx("only one input or output file allowed");
+ errs++;
} else {
vid.mode |= M_OUT_FILE;
if (ch != 'O')
@@ -1922,7 +1922,7 @@
if (len >= sizeof(vid.iofile)) {
warnx("output path is too long: %s",
optarg);
- err++;
+
NMEA: add more gps sensor values (2nd take)
Hi,
so now that the sensor types got adjusted, here's the tty_nmea.c diff
again, adding 7 new sensors:
- # satellites (raw)
- GPS/DGPS fix (or not) (raw)
- HDOP/VDOP/PDOP (raw)
- Altitude (m)
- Speed (m/s)
i'd welcome eyes on the logic, and especially on the nmea_atoi()
implementation - it is inspired by nmea_degrees() just below but it
feels awkward. I can of course only add altitude/speed as a start..
And testing with other nmea devices would be great ! So far i've tested
this in various static locations and recording data points when driving,
and it matched the gps data from my smartphone.
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 28 Dec 2018 20:47:20 -
@@ -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(&np->timedev, &np->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(&np->timedev, &np->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(&np->timedev, &np->speed);
+
+ np->nsat.type = SENSOR_INTEGER;
+ np->nsat.status = SENSOR_S_UNKNOWN;
+ np->nsat.flags = SENSOR_FINVALID;
+ np->nsat.value = 0;
+ strlcpy(np->nsat.desc, "Nb satellites", sizeof(np->nsat.desc));
+ sensor_attach(&np->timedev, &np->nsat);
+
+ np->quality.type = SENSOR_INTEGER;
+ np->quality.status = SENSOR_S_UNKNOWN;
+ np->quality.flags = SENSOR_FINVALID;
+ np->quality.value = 0;
+ strlcpy(np->quality.desc, "Fix Quality", sizeof(np->quality.desc));
+ sensor_attach(&np->timedev, &np->quality);
+
+ np->hdop.type = SENSOR_INTEGER;
+ np->hdop.status = SENSOR_S_UNKNOWN;
+ np->hdop.flags = SENSOR_FINVALID;
+ np->hdop.value = 0;
+ strlcpy(np->hdop.desc, "HDOP", sizeof(np->hdop.desc));
+ sensor_attach(&np->timedev, &np->hdop);
+
+ np->vdop.type = SENSOR_INTEGER;
+ np->vdop.status = SENSOR_S_UNKNOWN;
+ np->vdop.flags = SENSOR_FINVALID;
+ np->vdop.value = 0;
+ strlcpy(np->vdop.desc, "VDOP", sizeof(np->vdop.desc));
+ sensor_attach(&np->timedev, &np->vdop);
+
+ np->pdop.type = SENSOR_INTEGER;
+ np->pdop.status = SENSOR_S_UNKNOWN;
+ np->pdop.flags = SENSOR_FINVALID;
+ np->pdop.value = 0;
+ strlcpy(np->pdop.desc, "PDOP", sizeof(np->pdop.desc));
+ sensor_attach(&np->timedev, &np->pdop);
+
np->sync = 1;
tp->t_sc = (caddr_t)np;
@@ -182,7 +245,7 @@
np->ts.tv_nsec = ts.tv_nsec;
#ifdef NMEA_DEBUG
- if (nmeadebug > 0) {
+ if (nmeadebug > 1) {
linesw[TTYDISC].l_rint('[', tp);
linesw[TTYDISC].l_rint('0' + np->gapno++, tp);
linesw[TTYDISC].l_rint(']', tp);
@@ -261,7 +324,7 @@
}
/*
-* we only look at the RMC
Re: video(1) pledge (& updated kernel diff)
On Sat, Dec 29, 2018 at 09:30:22AM +0100, Sebastien Marie wrote:
> On Fri, Dec 28, 2018 at 09:41:06PM +0100, Landry Breuil wrote:
> > Hi,
> >
> > so i've updated my 'video' class for pledge and also did an initial
> > naive pledging of xenocara/app/video:
>
> just a small note: video(1) is the sole customer for ioctl(VIDIOC_*) in
> base. other potential customers are in ports.
>
> personally, with such promise, I would be interested in pledging a SIP
> program (like telephony/baresip, but I didn't check if this program is
> designed well enough for be pledgeable). I will look at it in order to
> have a third program to check the relevance of the ioctls.
>
> > as for the video(1) diff:
> > - fixed a typo
> > - renamed err to errs to avoid shadowing err()
>
> I would separate the addition of pledge(2) and unrelated fixes.
Right, two separated diffs attached for this.
> I think you pledged too early.
>
> "dns unix" are here for XOpenDisplay(), but if the display is remote,
> "inet" could be needed too. Even if Xv isn't possible on remote display,
> XOpenDisplay() will be killed by pledge.
>
> So ideally, pledge(2) should occurs later.
Yup, after some discussions, moving the pledge calls after setup()
(which does the file & xv opening) allows to only need stdio in the -i
case, and 'stdio rpath video' in the others. i thought rpath could be
dropped but in my testing with video -vvv -O i had a crash upon some
keys where x tried to open /usr/X11R6/share/X11/locale/locale.alias..
in addition we can also pledge the video -q case which needs
stdio/rpath/wpath/video.
> > +#define PLEDGE_VIDEO 0x00200800ULL /* video ioctls */
>
> I suspect a copy/paste error: PLEDGE_VIDEO contains 2 bits sets (there is a
> '8' after the '2').
> and space vs tab between the name and the value.
Yes that was a typo, i think when i originally started this the next
available define was 8000ULL :)
Landry
Index: video.c
===
RCS file: /cvs/xenocara/app/video/video.c,v
retrieving revision 1.25
diff -u -r1.25 video.c
--- video.c 9 Apr 2018 18:16:44 - 1.25
+++ video.c 30 Dec 2018 09:39:21 -
@@ -1854,7 +1854,7 @@
struct xdsp *x = &vid.xdsp;
const char *errstr;
size_t len;
- int ch, err = 0;
+ int ch, errs = 0;
bzero(&vid, sizeof(struct video));
@@ -1872,21 +1872,21 @@
x->cur_adap = strtonum(optarg, 0, 4, &errstr);
if (errstr != NULL) {
warnx("Xv adaptor '%s' is %s", optarg, errstr);
- err++;
+ errs++;
}
break;
case 'e':
vid.enc = find_enc(optarg);
if (vid.enc >= ENC_LAST) {
warnx("encoding '%s' is invalid", optarg);
- err++;
+ errs++;
}
break;
case 'f':
len = strlcpy(d->path, optarg, sizeof(d->path));
if (len >= sizeof(d->path)) {
warnx("file path is too long: %s", optarg);
- err++;
+ errs++;
}
break;
case 'g':
@@ -1894,8 +1894,8 @@
break;
case 'i':
if (vid.mode & (M_IN_FILE | M_OUT_FILE)) {
- warnx("only one input or ouput file allowed");
- err++;
+ warnx("only one input or output file allowed");
+ errs++;
} else {
vid.mode = (vid.mode & ~M_IN_DEV) | M_IN_FILE;
vid.mmap_on = 0; /* mmap mode does not work for
files */
@@ -1904,15 +1904,15 @@
if (len >= sizeof(vid.iofile)) {
warnx("input path is too long: %s",
optarg);
- err++;
+ errs++;
}
}
break;
case 'o':
case 'O':
if (vid.mode & (M_IN_FILE | M_OUT_FILE)) {
-
Re: NMEA: add more gps sensor values (2nd take)
On Sat, Dec 29, 2018 at 12:45:07AM +0200, Paul Irofti wrote:
> > so now that the sensor types got adjusted, here's the tty_nmea.c diff
> > again, adding 7 new sensors:
> > - # satellites (raw)
> > - GPS/DGPS fix (or not) (raw)
> > - HDOP/VDOP/PDOP (raw)
> > - Altitude (m)
> > - Speed (m/s)
>
> Yay sensors!
>
> > i'd welcome eyes on the logic, and especially on the nmea_atoi()
> > implementation - it is inspired by nmea_degrees() just below but it
> > feels awkward. I can of course only add altitude/speed as a start..
>
> I had a stab at it. Read ok, but I also tested it. If this is the
> desired output in the corner cases (e.g. ".1"), then its OK by me.
Yes, i had more or less done the same tests, and setting nmeadebug above
2 shows the actual values and their translation in the kernel buffer:
559.1 -> 559100 (altitude in mm)
2.79 -> 2790
1.11 -> 1110
2.56 -> 2560
0.039 -> 39 (speed in mm/s)
> > And testing with other nmea devices would be great ! So far i've tested
> > this in various static locations and recording data points when driving,
> > and it matched the gps data from my smartphone.
>
> Unfortunately I don't have any devices (that I know of) to test.
>
> The diff looks OK to me. The only thing that bugs me is a few scalar
> values that you use instead of defines. Mainly fld[] entries and vdop
> checks.
Right.. for the DOP warning threshold, added a #define NMEA_DOP_WARN. As
for the fld[] indexes, those are the position of the interesting value
in the NMEA sentence, so i dont think using #define for this is useful.
Adding comments and sentence examples before nmea_decode_gsa() &
nmea_decode_gga() might be better, as shown in the attached new diff.
While here i rechecked the NMEA spec for the GGA/GSA field definitions,
and understood why RMC could be 12 or 13 - a new field was added in NMEA
2.3 for some sentences only, per
http://www.catb.org/gpsd/NMEA.html#_sentence_mixes_and_nmea_variations
"In NMEA 2.3, several sentences (APB, BWC, BWR, GLL, RMA, RMB, RMC, VTG,
WCV, and XTE) got a new last field carrying the signal integrity
information needed by the FAA. " so this didnt apply to GSA/GGA.
Also attached is a poor try at updating nmea(4).
Index: nmea.4
===
RCS file: /cvs/src/share/man/man4/nmea.4,v
retrieving revision 1.26
diff -u -r1.26 nmea.4
--- nmea.4 2 Sep 2018 08:14:25 - 1.26
+++ nmea.4 30 Dec 2018 11:26:57 -
@@ -37,16 +37,19 @@
maintains timedelta and position sensors using the NMEA data.
The sensors will appear as nmea* in the list.
The timedelta (nanoseconds difference between the received time
-information and the local time), and position (calculated
-latitude and longitude in degrees) can be accessed through the
+information and the local time), position (calculated latitude
+and longitude in degrees), altitude, speed and precision can be
+accessed through the
.Xr sysctl 8
interface.
.Pp
The
.Nm
-line discipline decodes NMEA 0183
-Recommended Minimum Specific GPS/TRANSIT Data sentences.
-The time and date information and position are extracted.
+line discipline decodes the following NMEA 0183 sentences:
+.Bl -tag -width "RMCXX"
+.It RMC
+Recommended Minimum Specific GPS/TRANSIT Data.
+The time and date information, position and speed are extracted.
The warning indication is used to provide the sensor status (see below).
If the attached device sends the RMC message in the 13-field format,
the operation mode of the GPS device is reported in the sensor description.
@@ -54,8 +57,16 @@
is being used and tty timestamping has been turned on.
Otherwise the sensor timestamp is taken when the initial `$' character of
a message block is received from the NMEA device.
+.It GGA
+current fix data.
+The fix type (DGPS or GPS), amount of satellites used and altitude in meters
are extracted.
+.It GSA
+precision data.
+The Positional (PDOP), Horizontal (HDOP) and Vertical (VDOP) dilution of
+precision are extracted. A value above 2 is considered not precise enough.
+.El
.Pp
-RMC messages source are recognised by the first two characters of the
+Messages source are recognised by the first two characters of the NMEA
sentence according to the following prefixes:
.Pp
.Bl -tag -width "X" -offset indent -compact
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 30 Dec 2018 11:08:31 -
@@ -28,7 +28,11 @@
#ifdef NMEA_DEBUG
#define DPRINTFN(n, x) do { if (nmeadebug > (n)) printf x; } while (0)
-int nmeadebug = 0;
+int nmeadebug = 2;
+/*
+ * 1 = print interesting messages
+ * 2 = print all messages
+ */
#else
#define DPRINTFN(n, x)
#endif
@@ -38,6 +42,7 @@
#define NMEAMAX82
#define MAXFLDS32
+#define NMEA_DOP_WARN 2000
#ifdef NMEA_DEBUG
#define TRUSTTIM
Re: NMEA: add more gps sensor values (2nd take)
On Sun, Dec 30, 2018 at 05:17:54AM -0700, Theo de Raadt wrote: > I think you've gone overboard adding sensors. > > Some of them aren't informing a fact about the world, but about the GPS device > operation. > > Therefore I think nsat, quality, hdop, vdop, pdop are irrelevant. These > are basically protocol-specific / device-specific "error bars". > > I think you should delete those. Sure, i dont mind. I'm mostly interested in adding speed & altitude to lat/lon in the sensors. Others showed interest in other values. > We should also discuss the privacy implications of allowing all local software > to know the location of the user's machine, and then possibly broadcasting > into the cloud. I consider this similar to our recent decision to have > the microphone disabled by default, and same thing with /dev/video0 being > restricted access. What is the plan for hiding this sensitive information? Except that most devices around have a builtin microphone, all laptops have builtin webcams, and none have a builtin gps device. When you buy and plug a specific devices, you plan to make use of it.. Note that right now, if you plug a gps device, you need to be root (or in dialer group) to directly read on /dev/cuaU0. You also need it to run ldattach and make the information available via sensors. At that point, i think the admin has made the choice to make this information 'available to userland' - which is right now lat/lon, and my diff only proposes to add speed/altitude. This is imo orthogonal to the privacy discussion, and i personally have no plans to dig into adding knobs for restricting/allowing fine-grained access to devices. But i'll gladly test diffs, be it for video or nmea. Landry
Re: NMEA: add more gps sensor values (2nd take)
On Sun, Dec 30, 2018 at 06:04:17AM -0700, Theo de Raadt wrote: > Anyways, I haven't seen a specific consumer ready to use this > information from sysctl. I'm sure such programs exist and will be > adapted to use sysctl (or a file, will we make it mode 600 by > default?) rather than some linux interface. But I'm pretty sure I > don't want a system call making this feature available to all my > software, including some of the gigantic software I run which will > communicate my whereabouts to the world, such that the information can > be used against me. > > In many ways this is similar to the video pledge for firefox. firefox > main-process wants to do EVERYTHING. That diff is an attempt to > continue enforce pledge "everything" in the main-process, by adding > all missing features to pledge such that the main-process can be > pledged (but really, pledge in name alone, since it really requests > all features to work). > > So if we add a security control feature to block access to sensors, > will firefox want a way to enable GPS coordinate data so that it can > give it to the cloud? > > You will all sense I am becoming quite cynical about where this is going. Well, this drifted far away from the original diff, but i'll reply anyway since i'm feeling lucky. I'm mostly interested in it to record offline traces of trips/hikes for my personal use. After all, that's why i bought a gps, plugged it to my laptop, and i thought it would be simpler to integrate the missing bits (speed/altitude) in the sensors framework rather than running gpsd. Let's be clear since you seem worried about that, i have no plans to make firefox use that information. It *could* be possible though if people show interest, provided that: - one enables location sharing in firefox when a website asks for it: well, that also means you trust it to not share the location when you said you dont want to. At that point, if you dont trust it, dont run it. Do you trust your smartphone to disable the gps when you tell it so ? Your laptop vendor to disable the webcam when you say so in the bios ? Where is the line ? - one implements the missing bits between firefox and geoclue (https://bugzilla.mozilla.org/show_bug.cgi?id=1063572) - so far nobody showed interest upstream, and location is done through the public IP (as the browser doesnt have access to the list of nearby wifi networks, which is what's done on other OSes) cf https://support.mozilla.org/en-US/kb/does-firefox-share-my-location-websites - one implements the missing bits in geoclue to read location from hw.sensors.nmea. I had a quick look a while ago and never managed to get anything out of geoclue. If i had to choose and wanted to share my exact location with a website (for $reasons), i'd rather do it through a passive gps device rather than actively pinging google location services.. Landry
Re: NMEA: add more gps sensor values (2nd take)
On Sun, Dec 30, 2018 at 05:17:54AM -0700, Theo de Raadt wrote: > I think you've gone overboard adding sensors. > > Some of them aren't informing a fact about the world, but about the GPS device > operation. > > Therefore I think nsat, quality, hdop, vdop, pdop are irrelevant. These > are basically protocol-specific / device-specific "error bars". > > I think you should delete those. New smaller, simpler diff only adding altitude and speed. As a bonus nmea_atoi() loses the now useless decimal argument. 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 30 Dec 2018 14:28:21 - @@ -52,6 +52,8 @@ struct ksensor signal; /* signal status */ struct ksensor latitude; struct ksensor longitude; + struct ksensor altitude; + struct ksensor speed; struct ksensordev timedev; struct timespec ts; /* current timestamp */ struct timespec lts;/* timestamp of last '$' seen */ @@ -70,6 +72,7 @@ /* NMEA decoding */ void nmea_scan(struct nmea *, struct tty *); void nmea_gprmc(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 +80,7 @@ /* longitude and latitude conversion */ intnmea_degrees(int64_t *dst, char *src, int neg); +intnmea_atoi(int64_t *dst, char *src); /* degrade the timedelta sensor */ void nmea_timeout(void *); @@ -126,6 +130,20 @@ strlcpy(np->longitude.desc, "Longitude", sizeof(np->longitude.desc)); sensor_attach(&np->timedev, &np->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(&np->timedev, &np->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(&np->timedev, &np->speed); + np->sync = 1; tp->t_sc = (caddr_t)np; @@ -261,7 +279,7 @@ } /* -* we only look at the RMC message, which can come from different 'talkers', +* we only look at the messages coming from well-known sources or 'talkers', * distinguished by the two-chars prefix, the most common being: * GPS (GP) * Glonass (GL) @@ -269,11 +287,16 @@ * Galileo (GA) * 'Any kind/a mix of GNSS systems' (GN) */ - if (strcmp(fld[0], "BDRMC") && - strcmp(fld[0], "GARMC") && - strcmp(fld[0], "GLRMC") && - strcmp(fld[0], "GNRMC") && - strcmp(fld[0], "GPRMC")) + if (strncmp(fld[0], "BD", 2) && + strncmp(fld[0], "GA", 2) && + strncmp(fld[0], "GL", 2) && + strncmp(fld[0], "GN", 2) && + strncmp(fld[0], "GP", 2)) + return; + + /* we look for the RMC & GGA messages */ + if (strncmp(fld[0] + 2, "RMC", 3) && + strncmp(fld[0] + 2, "GGA", 3)) return; /* if we have a checksum, verify it */ @@ -299,7 +322,10 @@ return; } } - nmea_gprmc(np, tp, fld, fldcnt); + if (strncmp(fld[0] + 2, "RMC", 3) == 0) + nmea_gprmc(np, tp, fld, fldcnt); + if (strncmp(fld[0] + 2, "GGA", 3) == 0) + nmea_decode_gga(np, tp, fld, fldcnt); } /* Decode the recommended minimum specific GPS/TRANSIT data. */ @@ -385,9 +411,11 @@ np->signal.status = SENSOR_S_OK; np->latitude.status = SENSOR_S_OK; np->longitude.status = SENSOR_S_OK; + np->speed.status = SENSOR_S_OK; np->time.flags &= ~SENSOR_FINVALID; np->latitude.flags &= ~SENSOR_FINVALID; np->longitude.flags &= ~SENSOR_FINVALID; + np->speed.flags &= ~SENSOR_FINVALID; break; case 'V': /* * The GPS indicates a warning status, do not add to @@ -399,6 +427,7 @@ np->signal.status = SENSOR_S_CRIT; np->latitude.status = SENSOR_S_WARN; np->longitude.status = SENSOR_S_WARN; + np->speed.status = SENSOR_S_WARN; break; } if (nmea_degrees(&np->latitude.value, fld[3], *fld[4] == 'S' ? 1 : 0)) @@ -406,6 +435,11 @@ if (nmea_deg
