precision scrolling again
This is an updated version of the diff for precision scrolling. It
fixes a bug of the first one (which didn't check the synchronization
state properly), and it improves the filtering (when a scroll gesture
stops and the fingers remain on the touchpad, the first version
could too easily generate events for the wrong axis).
OK? Or should we wait until 6.5 is through?
Index: dev/wscons/wsconsio.h
===
RCS file: /cvs/src/sys/dev/wscons/wsconsio.h,v
retrieving revision 1.90
diff -u -p -r1.90 wsconsio.h
--- dev/wscons/wsconsio.h 10 Nov 2018 14:27:51 - 1.90
+++ dev/wscons/wsconsio.h 22 Mar 2019 22:02:14 -
@@ -112,6 +112,12 @@ struct wscons_event {
#defineWSCONS_EVENT_TOUCH_RESET25 /* (no value) */
/*
+ * Precision Scrolling
+ */
+#define WSCONS_EVENT_HSCROLL 26 /* dx * 4096 / scroll_unit */
+#define WSCONS_EVENT_VSCROLL 27 /* dy * 4096 / scroll_unit */
+
+/*
* Keyboard ioctls (0 - 31)
*/
Index: dev/wscons/wsmouse.c
===
RCS file: /cvs/src/sys/dev/wscons/wsmouse.c,v
retrieving revision 1.51
diff -u -p -r1.51 wsmouse.c
--- dev/wscons/wsmouse.c19 Feb 2019 07:01:02 - 1.51
+++ dev/wscons/wsmouse.c22 Mar 2019 22:02:14 -
@@ -1034,10 +1034,18 @@ wsmouse_motion_sync(struct wsmouseinput
wsmouse_evq_put(evq, DELTA_X_EV(input), dx);
if (dy)
wsmouse_evq_put(evq, DELTA_Y_EV(input), dy);
- if (motion->dz)
- wsmouse_evq_put(evq, DELTA_Z_EV, motion->dz);
- if (motion->dw)
- wsmouse_evq_put(evq, DELTA_W_EV, motion->dw);
+ if (motion->dz) {
+ if (IS_TOUCHPAD(input))
+ wsmouse_evq_put(evq, VSCROLL_EV, motion->dz);
+ else
+ wsmouse_evq_put(evq, DELTA_Z_EV, motion->dz);
+ }
+ if (motion->dw) {
+ if (IS_TOUCHPAD(input))
+ wsmouse_evq_put(evq, HSCROLL_EV, motion->dw);
+ else
+ wsmouse_evq_put(evq, DELTA_W_EV, motion->dw);
+ }
}
if (motion->sync & SYNC_POSITION) {
if (motion->sync & SYNC_X) {
Index: dev/wscons/wsmouseinput.h
===
RCS file: /cvs/src/sys/dev/wscons/wsmouseinput.h,v
retrieving revision 1.12
diff -u -p -r1.12 wsmouseinput.h
--- dev/wscons/wsmouseinput.h 10 Nov 2018 14:27:51 - 1.12
+++ dev/wscons/wsmouseinput.h 22 Mar 2019 22:02:14 -
@@ -210,6 +210,8 @@ int wstpad_set_param(struct wsmouseinput
WSCONS_EVENT_MOUSE_ABSOLUTE_X : WSCONS_EVENT_MOUSE_ABSOLUTE_Y)
#define DELTA_Z_EV WSCONS_EVENT_MOUSE_DELTA_Z
#define DELTA_W_EV WSCONS_EVENT_MOUSE_DELTA_W
+#define VSCROLL_EV WSCONS_EVENT_VSCROLL
+#define HSCROLL_EV WSCONS_EVENT_HSCROLL
#define ABS_Z_EV WSCONS_EVENT_TOUCH_PRESSURE
#define ABS_W_EV WSCONS_EVENT_TOUCH_CONTACTS
#define BTN_DOWN_EVWSCONS_EVENT_MOUSE_DOWN
Index: dev/wscons/wstpad.c
===
RCS file: /cvs/src/sys/dev/wscons/wstpad.c,v
retrieving revision 1.22
diff -u -p -r1.22 wstpad.c
--- dev/wscons/wstpad.c 29 Dec 2018 21:03:58 - 1.22
+++ dev/wscons/wstpad.c 22 Mar 2019 22:02:15 -
@@ -167,8 +167,6 @@ struct wstpad {
u_int mtcycle;
u_int ignore;
- int dx;
- int dy;
int contacts;
int prev_contacts;
u_int btns;
@@ -223,12 +221,11 @@ struct wstpad {
} tap;
struct {
- int acc_dx;
- int acc_dy;
int dz;
int dw;
int hdist;
int vdist;
+ int mag;
} scroll;
};
@@ -435,8 +432,8 @@ set_freeze_ts(struct wstpad *tp, int sec
/* Return TRUE if two-finger- or edge-scrolling would be valid. */
-static inline int
-chk_scroll_state(struct wsmouseinput *input)
+int
+wstpad_scroll_coords(struct wsmouseinput *input, int *dx, int *dy)
{
struct wstpad *tp = input->tp;
@@ -445,44 +442,68 @@ chk_scroll_state(struct wsmouseinput *in
tp->scroll.dw = 0;
return (0);
}
+ if ((input->motion.sync & SYNC_POSITION) == 0)
+ return (0);
/*
* Try to exclude accidental scroll events by checking whether the
* pointer-controlling touch is stable. The check, which may cause
* a short delay, is only applied initially, a touch that stops and
* resumes scrolling is not affected.
*/
- if (tp->scroll.dz || tp->scroll.dw || wstpad_is_stable(input, tp->t))
- return (tp->dx || tp->dy);
+
Re: rasops(9): revert changes in rasops32_putchar()?
> Date: Mon, 18 Mar 2019 14:49:48 +0100
> From: Frederic Cambus
>
> Hi tech@,
>
> Now that efifb(4) supports remapping the framebuffer in write combining
> mode, it's on par with inteldrm regarding display performance as for as
> rasops(9) is concerned.
>
> Therefore, I'm proposing reverting changes which were introduced in
> rasops32_putchar() in revision 1.8 [1] as they are now also slowing
> things down on efifb(4).
>
> I used a 6.3M text file for testing display performance:
> ftp https://norvig.com/big.txt
>
> The inteldrm and efifb tests were done on the same machine, the
> radeondrm ones were done on another (faster) machine.
>
> Screen size: 1920x1080
> Font size: 16x32
>
> Here are the results (3 runs each) of running: time cat big.txt
>
> inteldrm:
>
> 2m39.52s real 0m00.00s user 2m39.52s system
> 2m39.74s real 0m00.00s user 2m39.84s system
> 2m39.74s real 0m00.00s user 2m39.77s system
>
> inteldrm (with revert diff applied):
>
> 1m37m76s real 0m00.00s user 1m37m60s system
> 1m37m80s real 0m00.00s user 1m37m56s system
> 1m37m43s real 0m00.00s user 1m37m47s system
>
> efifb:
>
> 2m40.46s real 0m00.00s user 2m39.43s system
> 2m39.49s real 0m00.00s user 2m39.52s system
> 2m39.45s real 0m00.00s user 2m39.48s system
>
> efifb (with revert diff applied):
>
> 1m37m66s real 0m00.00s user 1m37m19s system
> 1m37m17s real 0m00.00s user 1m37m22s system
> 1m37m15s real 0m00.00s user 1m37m20s system
>
> radeondrm:
>
> 4m40.75s real 0m00.00s user 4m39m75s system
> 4m39.84s real 0m00.00s user 4m39m85s system
> 4m39.68s real 0m00.00s user 4m39m71s system
>
> radeondrm (with revert diff applied):
>
> 0m21.08s real 0m00.00s user 0m21.08s system
> 0m21.15s real 0m00.00s user 0m21.05s system
> 0m21.10s real 0m00.00s user 0m21.06s system
>
> [1]
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/rasops/rasops32.c.diff?r1=1.7=1.8
>
> Comments? OK?
Those differences are significant! So yes, let's give this a try and
commit this.
ok kettenis@
> Index: sys/dev/rasops/rasops32.c
> ===
> RCS file: /cvs/src/sys/dev/rasops/rasops32.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 rasops32.c
> --- sys/dev/rasops/rasops32.c 20 Feb 2017 15:35:05 - 1.8
> +++ sys/dev/rasops/rasops32.c 18 Mar 2019 08:15:18 -
> @@ -69,7 +69,6 @@ rasops32_putchar(void *cookie, int row,
> struct rasops_info *ri;
> int32_t *dp, *rp;
> u_char *fr;
> - uint32_t buffer[64];
>
> ri = (struct rasops_info *)cookie;
>
> @@ -91,13 +90,12 @@ rasops32_putchar(void *cookie, int row,
> clr[1] = ri->ri_devcmap[(attr >> 24) & 0xf];
>
> if (uc == ' ') {
> - for (cnt = 0; cnt < width; cnt++)
> - buffer[cnt] = clr[0];
> while (height--) {
> dp = rp;
> DELTA(rp, ri->ri_stride, int32_t *);
>
> - memcpy(dp, buffer, width << 2);
> + for (cnt = width; cnt; cnt--)
> + *dp++ = clr[0];
> }
> } else {
> uc -= ri->ri_font->firstchar;
> @@ -111,11 +109,10 @@ rasops32_putchar(void *cookie, int row,
> fr += fs;
> DELTA(rp, ri->ri_stride, int32_t *);
>
> - for (cnt = 0; cnt < width; cnt++) {
> - buffer[cnt] = clr[(fb >> 31) & 1];
> + for (cnt = width; cnt; cnt--) {
> + *dp++ = clr[(fb >> 31) & 1];
> fb <<= 1;
> }
> - memcpy(dp, buffer, width << 2);
> }
> }
>
>
>
Re: [patch] Re: Possible sasyncd memory leak ?
W dniu 22.03.2019 o 11:19, Michał Koc pisze:
W dniu 21.03.2019 o 11:52, Otto Moerbeek pisze:
On Thu, Mar 21, 2019 at 09:28:28AM +0100, Michał Koc wrote:
W dniu 21.03.2019 o 07:21, Otto Moerbeek pisze:
On Thu, Mar 21, 2019 at 12:51:11AM +0100, Klemens Nanni wrote:
On Tue, Mar 12, 2019 at 03:19:56PM +0100, Otto Moerbeek wrote:
I also fixed a case of parsing IPv6 addresses.
Anyone willing to ok?
See comments inline.
And now also with a lexer bug fixed. Earlier I thougt it was an
order
dependency in the clauses. But is was an order dependency in comment
lines and empty lines.
+check_peer_addr(const char *peer_addr)
+{
+ int valid = 1;
+ short peer_family = AF_UNSPEC;
+ struct ifaddrs *ifap = NULL, *ifa;
+ struct syncpeer *peer;
+ struct sockaddr_in sa;
+ struct sockaddr_in6 sa6;
+
+ if (inet_pton(AF_INET, peer_addr, _addr) == 1)
+ peer_family = AF_INET;
+
+ if (peer_family == AF_UNSPEC && inet_pton(AF_INET6, peer_addr,
+ _addr) == 1)
+ peer_family = AF_INET6;
`peer_addr' must not be a CIDR network, so I'd go with the more AF
agnostic getaddrinfo(3) and check for res->ai_family in any case...
+ if (peer_family == AF_UNSPEC) {
+ log_msg(2, "config: skip unparseable peer %s", peer_addr);
+ valid = 0;
+ }
..but `peer_addr' may also be a hostname, so that is not handled by
your diff:
net.h: char *name; /* FQDN or an IP, from conf */
getaddrinfo(3) can resolve however, thus inet_pton(3) should not
be used
here.
Either way, this is a job for host_ip() as found in pfctl or bgpd.
Other daemons like iked still have host_v4() and host_v6().
Parsers use
these functions to check for valid addresses, so I'd say sasyncd
should
be no exception and adopt the same approach.
@@ -325,7 +386,7 @@ yylex(void)
/* Numerical token? */
if (isdigit(*confptr)) {
for (p = confptr; *p; p++)
- if (*p == '.') /* IP address, or bad input */
+ if (*p == '.' || *p == ':') /* IP address, or bad
input */
This fixes the parser as in
# echo peer 2001:db8::1 > conf
# sasyncd -dnv -c conf
config: syntax error
# ./obj/sasyncd -dnv -c conf
configuration OK
But I have not actually tested this with a proper IPv6 setup since
I do
not use sasyncd; did you?
@@ -397,6 +458,9 @@ conf_parse_file(char *cfgfile)
if (*s == '#') {
while (*s != '\n' && s < buf + conflen)
s++;
+ while (*s == '\n' && s < buf + conflen)
+ s++;
+ s--;
OK kn for this fix alone.
I'll test an ipv6 seup and commit the lexer parts if those work.
Michal, can you work on the first set of comments? I think Klemens is
right.
-Otto
Of course, I'll follow the comments soon
Best Regards
M.K.
the diff is ready, what happened here:
1. host => ip manipulation moved to host_ip() function in net.c and is
using getaddrinfo()
2. net_set_sa() in net.c modified to use host_ip()
Bets Regards
M.K
Do not actually compare two structs sockaddr if their lengths differ.
Index: conf.y
===
RCS file: /cvs/src/usr.sbin/sasyncd/conf.y,v
retrieving revision 1.19
diff -u -p -r1.19 conf.y
--- conf.y 9 Apr 2017 02:40:24 - 1.19
+++ conf.y 22 Mar 2019 20:55:21 -
@@ -30,8 +30,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -48,6 +50,7 @@ struct cfgstate cfgstate;
intconflen = 0;
char *confbuf, *confptr;
+intcheck_peer_addr(const char *);
intyyparse(void);
intyylex(void);
void yyerror(const char *);
@@ -172,17 +175,8 @@ setting: INTERFACE STRING
| PEER STRING
{
struct syncpeer *peer;
- int duplicate = 0;
- for (peer = LIST_FIRST(); peer;
-peer = LIST_NEXT(peer, link))
- if (strcmp($2, peer->name) == 0) {
- duplicate++;
- break;
- }
- if (duplicate)
- free($2);
- else {
+ if (check_peer_addr($2)) {
peer = calloc(1, sizeof *peer);
if (!peer) {
log_err("config: calloc(1, %lu) "
@@ -191,10 +185,11 @@ setting : INTERFACE STRING
YYERROR;
}
peer->name = $2;
- }
- LIST_INSERT_HEAD(, peer, link);
- cfgstate.peercnt++;
- log_msg(2, "config: add peer %s", peer->name);
+
bgpd: unbreak route origin validation
(better when the right diff is sent...) ROV has been broken since the configuration reload changes. Index: rde.c === RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v retrieving revision 1.466 diff -u -p -r1.466 rde.c --- rde.c 13 Mar 2019 14:35:39 - 1.466 +++ rde.c 22 Mar 2019 15:36:41 - @@ -2899,7 +2899,7 @@ rde_reload_done(void) roa_old = conf->rde_roa; as_sets_old = conf->as_sets; - copy_config(conf, nconf); + memcpy(conf, nconf, sizeof(struct bgpd_config)); SIMPLEQ_INIT(>rde_prefixsets); SIMPLEQ_INIT(>rde_originsets); SIMPLEQ_CONCAT(>rde_prefixsets, >rde_prefixsets);
Re: rsync: gettimeofday+TIMEVAL_TO_TIMESPEC -> UTIME_NOW
Kristaps Dzonsons wrote: > >> ... it says the modification time is a time_t. Which means we only > >> have seconds, not subseconds. > > > > Fair enough. The protocol predates common availability of nanosecond > > file timestamps. > > It's worse than that. It's 32-bit time_t. Your docs say it is a time_t, but the code says it isn't. It is handled as an int. A wire protocol should never use a typedef which could change size. Anyways, I suspect upon send/recv of the value it needs to be treated as unsigned, and upon receive also unsigned extended into 64-bits so that it works beyond 2038. We did this in a pile or places, since it is sensible and realistic that the solution will outlast the specific protocol (or filesystem).
Re: rsync: gettimeofday+TIMEVAL_TO_TIMESPEC -> UTIME_NOW
Kristaps Dzonsons wrote: > >> ... it says the modification time is a time_t. Which means we only > >> have seconds, not subseconds. > > > > Fair enough. The protocol predates common availability of nanosecond > > file timestamps. > > It's worse than that. It's 32-bit time_t. Do negative values have a specific meaning? If not, it can be treated as unsigned 32-bit, and then it is harmless in our livetimes and beyond.
Re: usb drivers & arches (Re: [4/4] Re: Add support for Meinberg DCF600USB to umbg(4))
Paul de Weerd wrote: > On Fri, Mar 22, 2019 at 11:53:20AM +, Stuart Henderson wrote: > | This is a more general thing actually, the list of USB drivers is rather > | haphazard at the moment. List below (to fit <80 cols I've snipped i386 > | which has all drivers present in any other GENERIC config, amd64 which > | is only missing umbg, and sgi with all its various different configs). > | > | Would it make sense to try unifying these for all/some arches? are > | there particular space constraints for some (IIRC maybe the case on sgi, > | not sure about others) or other reasons to restrict them? > > One thing that could be considered is putting all USB devices into a > separate file that gets included from the various arch-specific > GENERIC config files. That would look a bit like the below for amd64 > (although the 'USB' file would then probably move to sys/conf/). > > This has some obvious downsides, so this is probably not such a hot > idea. There's some upsides too, though. Obviously, this is above my > pay-grade - I cannot oversee the full implications. This has been looked at before, and we decided against it.
Re: rsync: gettimeofday+TIMEVAL_TO_TIMESPEC -> UTIME_NOW
>> ... it says the modification time is a time_t. Which means we only >> have seconds, not subseconds. > > Fair enough. The protocol predates common availability of nanosecond > file timestamps. It's worse than that. It's 32-bit time_t.
Re: rsync: gettimeofday+TIMEVAL_TO_TIMESPEC -> UTIME_NOW
On Fri, 22 Mar 2019 11:16:00 -0500, Scott Cheloha wrote: > ... it says the modification time is a time_t. Which means we only > have seconds, not subseconds. Fair enough. The protocol predates common availability of nanosecond file timestamps. - todd
Re: usb drivers & arches (Re: [4/4] Re: Add support for Meinberg DCF600USB to umbg(4))
On Fri, Mar 22, 2019 at 11:53:20AM +, Stuart Henderson wrote: | This is a more general thing actually, the list of USB drivers is rather | haphazard at the moment. List below (to fit <80 cols I've snipped i386 | which has all drivers present in any other GENERIC config, amd64 which | is only missing umbg, and sgi with all its various different configs). | | Would it make sense to try unifying these for all/some arches? are | there particular space constraints for some (IIRC maybe the case on sgi, | not sure about others) or other reasons to restrict them? One thing that could be considered is putting all USB devices into a separate file that gets included from the various arch-specific GENERIC config files. That would look a bit like the below for amd64 (although the 'USB' file would then probably move to sys/conf/). This has some obvious downsides, so this is probably not such a hot idea. There's some upsides too, though. Obviously, this is above my pay-grade - I cannot oversee the full implications. Index: GENERIC === RCS file: /home/OpenBSD/cvs/src/sys/arch/amd64/conf/GENERIC,v retrieving revision 1.467 diff -u -p -r1.467 GENERIC --- GENERIC 22 Mar 2019 12:05:45 - 1.467 +++ GENERIC 22 Mar 2019 16:08:19 - @@ -89,7 +89,6 @@ hvn* at hyperv? # Hyper-V NetVSC hvs* at hyperv? # Hyper-V StorVSC option PCIVERBOSE -option USBVERBOSE pchb* at pci? # PCI-Host bridges aapic* at pci? # AMD 8131 IO apic @@ -211,120 +210,7 @@ usb* at ehci? usb* at uhci? usb* at ohci? -# USB devices -uhub* at usb? # USB Hubs -uhub* at uhub?# USB Hubs -urng* at uhub?# USB Random Number Generator -uonerng* at uhub? # Moonbase Otago OneRNG -umodem*at uhub?# USB Modems/Serial -ucom* at umodem? -uvisor*at uhub?# Handspring Visor -ucom* at uvisor? -uvscom*at uhub?# SUNTAC Slipper U VS-10U serial -ucom* at uvscom? -ubsa* at uhub?# Belkin serial adapter -ucom* at ubsa? -uftdi* at uhub?# FTDI FT8U100AX serial adapter -ucom* at uftdi? -uplcom* at uhub? # I/O DATA USB-RSAQ2 serial adapter -ucom* at uplcom? -umct* at uhub?# MCT USB-RS232 serial adapter -ucom* at umct? -uslcom*at uhub?# Silicon Laboratories CP210x serial -ucom* at uslcom? -uscom* at uhub?# Simple USB serial adapters -ucom* at uscom? -uark* at uhub?# Arkmicro ARK3116 serial -ucom* at uark? -moscom*at uhub?# MosChip MCS7703 serial -ucom* at moscom? -umcs* at uhub?# MosChip MCS78x0 serial -ucom* at umcs? -uipaq* at uhub?# iPAQ serial adapter -ucom* at uipaq? -umsm* at uhub?# Qualcomm MSM EVDO -ucom* at umsm? -uchcom*at uhub?# WinChipHead CH341/340 serial -ucom* at uchcom? -uticom*at uhub?# TI serial -ucom* at uticom? -uaudio* at uhub? # USB Audio -audio* at uaudio? -umidi* at uhub?# USB MIDI -midi* at umidi? -ulpt* at uhub?# USB Printers -umass* at uhub?# USB Mass Storage devices -ubcmtp*at uhub?# Broadcom USB trackpad -wsmouse* at ubcmtp? mux 0 -uhidev*at uhub?# Human Interface Devices -ums* at uhidev? # USB mouse -wsmouse* at ums? mux 0 -umt* at uhidev? # USB multitouch touchpad -wsmouse* at umt? mux 0 -uts* at uhub?# USB touchscreen -wsmouse* at uts? mux 0 -uwacom*at uhidev? # USB Wacom tablet -wsmouse* at uwacom? mux 0 -ukbd* at uhidev? # USB keyboard -wskbd* at ukbd? mux 1 -ucycom*at uhidev? # Cypress serial -ucom* at ucycom? -uslhcom* at uhidev?# Silicon Labs CP2110 USB HID UART -ucom* at uslhcom? -uhid* at uhidev? # USB generic HID support -upd* at uhidev? # USB Power Devices sensors -aue* at uhub?# ADMtek AN986 Pegasus Ethernet -atu* at uhub?# Atmel AT76c50x based 802.11b -axe* at uhub?# ASIX Electronics AX88172 USB Ethernet -axen* at uhub?# ASIX Electronics AX88179 USB Ethernet -cue* at uhub?# CATC USB-EL1201A based Ethernet -kue* at uhub?# Kawasaki KL5KUSB101B based Ethernet -smsc* at uhub?# SMSC LAN95xx Ethernet -cdce* at uhub?# CDC Ethernet -urndis*at uhub?# Remote NDIS Ethernet -upl* at uhub?# Prolific PL2301/PL2302 host-to-host `network' -ugl* at uhub?# Genesys Logic GL620USB-A host-to-host `network' -udav* at uhub?
Re: rsync: gettimeofday+TIMEVAL_TO_TIMESPEC -> UTIME_NOW
On Fri, Mar 22, 2019 at 10:10:43AM -0600, Todd C. Miller wrote: > On Fri, 22 Mar 2019 11:04:05 -0500, Scott Cheloha wrote: > > > I always forget about the special value shortcut for utimes(2) et al. > > > > This is equivalent/simpler/more portable. > > That looks good but I wonder why we are not preserving the nanosecond > mtime by using st_mtim? I assumed subseconds were not handled/preserved by the protocol, but I might be wrong. Possibly relevant, from (our) rsync(5): > Update exchange > When the client or server is in sender mode, it begins by conditionally > sending the exclusion list. At this time, this is always empty. > > 1. if --delete and the client, exclusion list zero (integer) > > It then sends the File list. Prior to being sent, the file list should > be lexicographically sorted. > > 1. status byte (integer) > 2. inherited filename length (optional, byte) > 3. filename length (integer or byte) > 4. file (byte array) > 5. file length (long) > 6. file modification time (optional, time_t, integer) > 7. file mode (optional, mode_t, integer) > 8. if -o, the user id (integer) > 9. if -g, the group id (integer) > 10. if a special file and -D, the device "rdev" type (integer) > 11. if a symbolic link and -l, the link target's length (integer) > 12. if a symbolic link and -l, the link target (byte array) ... it says the modification time is a time_t. Which means we only have seconds, not subseconds. But don't quote me on that, I'm just guessing. -Scott
Re: rsync: gettimeofday+TIMEVAL_TO_TIMESPEC -> UTIME_NOW
On Fri, 22 Mar 2019 11:04:05 -0500, Scott Cheloha wrote: > I always forget about the special value shortcut for utimes(2) et al. > > This is equivalent/simpler/more portable. That looks good but I wonder why we are not preserving the nanosecond mtime by using st_mtim? - todd
rsync: gettimeofday+TIMEVAL_TO_TIMESPEC -> UTIME_NOW
I always forget about the special value shortcut for utimes(2) et al.
This is equivalent/simpler/more portable.
ok?
Index: receiver.c
===
RCS file: /cvs/src/usr.bin/rsync/receiver.c,v
retrieving revision 1.19
diff -u -p -r1.19 receiver.c
--- receiver.c 18 Feb 2019 21:55:27 - 1.19
+++ receiver.c 22 Mar 2019 15:59:24 -
@@ -47,7 +47,7 @@ rsync_set_metadata(struct sess *sess, in
{
uid_tuid = (uid_t)-1;
gid_tgid = (gid_t)-1;
- struct timespec tv[2];
+ struct timespec ts[2];
/*
* Conditionally adjust identifiers.
@@ -76,13 +76,10 @@ rsync_set_metadata(struct sess *sess, in
/* Conditionally adjust file modification time. */
if (sess->opts->preserve_times) {
- struct timeval now;
-
- gettimeofday(, NULL);
- TIMEVAL_TO_TIMESPEC(, [0]);
- tv[1].tv_sec = f->st.mtime;
- tv[1].tv_nsec = 0;
- if (futimens(fd, tv) == -1) {
+ ts[0].tv_nsec = UTIME_NOW;
+ ts[1].tv_sec = f->st.mtime;
+ ts[1].tv_nsec = 0;
+ if (futimens(fd, ts) == -1) {
ERR(sess, "%s: futimens", path);
return 0;
}
@@ -108,7 +105,7 @@ rsync_set_metadata_at(struct sess *sess,
{
uid_tuid = (uid_t)-1;
gid_tgid = (gid_t)-1;
- struct timespec tv[2];
+ struct timespec ts[2];
/*
* Conditionally adjust identifiers.
@@ -138,13 +135,10 @@ rsync_set_metadata_at(struct sess *sess,
/* Conditionally adjust file modification time. */
if (sess->opts->preserve_times) {
- struct timeval now;
-
- gettimeofday(, NULL);
- TIMEVAL_TO_TIMESPEC(, [0]);
- tv[1].tv_sec = f->st.mtime;
- tv[1].tv_nsec = 0;
- if (utimensat(rootfd, path, tv, AT_SYMLINK_NOFOLLOW) == -1) {
+ ts[0].tv_nsec = UTIME_NOW;
+ ts[1].tv_sec = f->st.mtime;
+ ts[1].tv_nsec = 0;
+ if (utimensat(rootfd, path, ts, AT_SYMLINK_NOFOLLOW) == -1) {
ERR(sess, "%s: utimensat", path);
return 0;
}
bgpd: unbreak route origin validation
ROV has been broken since the configuration reload changes.
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.466
diff -u -p -r1.466 rde.c
--- rde.c 13 Mar 2019 14:35:39 - 1.466
+++ rde.c 22 Mar 2019 15:36:41 -
@@ -769,7 +769,7 @@ rde_dispatch_imsg_parent(struct imsgbuf
fatal(NULL);
SIMPLEQ_INIT(newdomains);
nconf = new_config();
- copy_config(nconf, imsg.data);
+ memcpy(nconf, imsg.data, sizeof(struct bgpd_config));
for (rid = 0; rid < rib_size; rid++) {
if (!rib_valid(rid))
@@ -2899,7 +2899,7 @@ rde_reload_done(void)
roa_old = conf->rde_roa;
as_sets_old = conf->as_sets;
- copy_config(conf, nconf);
+ memcpy(conf, nconf, sizeof(struct bgpd_config));
SIMPLEQ_INIT(>rde_prefixsets);
SIMPLEQ_INIT(>rde_originsets);
SIMPLEQ_CONCAT(>rde_prefixsets, >rde_prefixsets);
Re: [3/4] Re: Add support for Meinberg DCF600USB to umbg(4)
Whoops. I had missed one change to the manpage that's still needed:
the DESCRIPTION section also mentions the supported devices. This now
supports two models, but I don't think it makes sense to turn this
into a list of supported hardware just yet.
Index: umbg.4
===
RCS file: /home/OpenBSD/cvs/src/share/man/man4/umbg.4,v
retrieving revision 1.5
diff -u -p -r1.5 umbg.4
--- umbg.4 22 Mar 2019 12:04:25 - 1.5
+++ umbg.4 22 Mar 2019 14:47:14 -
@@ -25,8 +25,9 @@
.Sh DESCRIPTION
The
.Nm
-driver provides support for the Meinberg Funkuhren USB5131, a time signal
-station receiver for the German DCF77 station.
+driver provides support for the Meinberg Funkuhren USB5131 and the
+Meinberg Funkuhren DCF600USB, two time signal station receivers for
+the German DCF77 station.
.Nm
implements a timedelta sensor and the delta (in nanoseconds) between the
received time information and the local time can be accessed through the
On Fri, Mar 22, 2019 at 10:04:19AM +0100, Paul de Weerd wrote:
|
| Index: share/man/man4/umbg.4
| ===
| RCS file: /home/OpenBSD/cvs/src/share/man/man4/umbg.4,v
| retrieving revision 1.4
| diff -u -p -r1.4 umbg.4
| --- share/man/man4/umbg.4 16 Jul 2013 16:05:49 - 1.4
| +++ share/man/man4/umbg.4 20 Mar 2019 12:16:03 -
| @@ -19,7 +19,7 @@
| .Os
| .Sh NAME
| .Nm umbg
| -.Nd Meinberg Funkuhren USB5131 timedelta sensor
| +.Nd Meinberg Funkuhren USB5131 and DCF600USB timedelta sensors
| .Sh SYNOPSIS
| .Cd "umbg* at uhub?"
| .Sh DESCRIPTION
| Index: sys/dev/usb/umbg.c
| ===
| RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/umbg.c,v
| retrieving revision 1.25
| diff -u -p -r1.25 umbg.c
| --- sys/dev/usb/umbg.c30 Dec 2017 20:47:00 - 1.25
| +++ sys/dev/usb/umbg.c22 Mar 2019 08:29:40 -
| @@ -156,8 +156,9 @@ umbg_match(struct device *parent, void *
| if (uaa->iface == NULL)
| return UMATCH_NONE;
|
| - return uaa->vendor == USB_VENDOR_MEINBERG &&
| - uaa->product == USB_PRODUCT_MEINBERG_USB5131 ?
| + return uaa->vendor == USB_VENDOR_MEINBERG && (
| + uaa->product == USB_PRODUCT_MEINBERG_USB5131 ||
| + uaa->product == USB_PRODUCT_MEINBERG_DCF600USB) ?
| UMATCH_VENDOR_PRODUCT : UMATCH_NONE;
| }
|
| @@ -172,6 +173,7 @@ umbg_attach(struct device *parent, struc
| usb_endpoint_descriptor_t *ed;
| usbd_status err;
| int signal;
| + const char *desc;
| #ifdef UMBG_DEBUG
| char fw_id[MBG_ID_LEN];
| #endif
| @@ -182,7 +184,18 @@ umbg_attach(struct device *parent, struc
|
| sc->sc_timedelta.type = SENSOR_TIMEDELTA;
| sc->sc_timedelta.status = SENSOR_S_UNKNOWN;
| - strlcpy(sc->sc_timedelta.desc, "USB5131",
| +
| + switch (uaa->product) {
| + case USB_PRODUCT_MEINBERG_DCF600USB:
| + desc = "DCF600USB";
| + break;
| + case USB_PRODUCT_MEINBERG_USB5131:
| + desc = "USB5131";
| + break;
| + default:
| + desc = "Unspecified Radio clock";
| + }
| + strlcpy(sc->sc_timedelta.desc, desc,
| sizeof(sc->sc_timedelta.desc));
| sensor_attach(>sc_sensordev, >sc_timedelta);
|
|
| --
| >[<++>-]<+++.>+++[<-->-]<.>+++[<+
| +++>-]<.>++[<>-]<+.--.[-]
| http://www.weirdnet.nl/
|
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
openrsync: return codes
The following patch fixes exit codes, which became confused in the
switch from returning a Boolean and an exit code. I actually prefer for
these to become an enum to avoid further confusion, but this just gets
it fixed.
It also documents the return values in each function and unifies the
protocol incompatibility error message.
? rsync-error-codes.diff
Index: client.c
===
RCS file: /cvs/src/usr.bin/rsync/client.c,v
retrieving revision 1.12
diff -u -p -r1.12 client.c
--- client.c 18 Mar 2019 15:33:21 - 1.12
+++ client.c 22 Mar 2019 14:31:53 -
@@ -30,17 +30,14 @@
* It can either be in sender or receiver mode.
* In the former, it synchronises local files from a remote sink.
* In the latter, the remote sink synchronses to the local files.
- *
- * Pledges: stdio, rpath, wpath, cpath, unveil, fattr, chown.
- *
- * Pledges (dry-run): -cpath, -wpath, -fattr, chown.
- * Pledges (!preserve_times): -fattr.
+ * Returns exit code 0 on success, 1 on failure, 2 on failure with
+ * incompatible protocols.
*/
int
rsync_client(const struct opts *opts, int fd, const struct fargs *f)
{
struct sess sess;
- int rc = 0;
+ int rc = 1;
/* Standard rsync preamble, sender side. */
@@ -64,10 +61,10 @@ rsync_client(const struct opts *opts, in
}
if (sess.rver < sess.lver) {
- ERRX(, "remote protocol is older "
- "than our own (%" PRId32 " < %" PRId32 "): "
- "this is not supported",
- sess.rver, sess.lver);
+ ERRX(,
+ "remote protocol %d is older than our own %d: unsupported",
+ sess.rver, sess.lver);
+ rc = 2;
goto out;
}
@@ -105,7 +102,7 @@ rsync_client(const struct opts *opts, in
WARNX(, "data remains in read pipe");
#endif
- rc = 1;
+ rc = 0;
out:
return rc;
}
Index: main.c
===
RCS file: /cvs/src/usr.bin/rsync/main.c,v
retrieving revision 1.33
diff -u -p -r1.33 main.c
--- main.c 18 Mar 2019 08:11:11 - 1.33
+++ main.c 22 Mar 2019 14:31:54 -
@@ -273,7 +273,7 @@ main(int argc, char *argv[])
{
struct opts opts;
pid_t child;
- int fds[2], rc = 0, c, st, i;
+ int fds[2], rc, c, st, i;
struct sess sess;
struct fargs *fargs;
char **args;
@@ -478,13 +478,23 @@ main(int argc, char *argv[])
* So close the connection here so that they don't hang.
*/
- if (!rc)
+ if (rc)
close(fds[0]);
if (waitpid(child, , 0) == -1)
err(1, "waitpid");
- if (!(WIFEXITED(st) && WEXITSTATUS(st) == 0))
- rc = 0;
+
+ /*
+ * If we don't already have an error (rc == 0), then inherit the
+ * error code of rsync_server() if it has exited.
+ * If it hasn't exited, it overrides our return value.
+ */
+
+ if (WIFEXITED(st) && rc == 0)
+ rc = WEXITSTATUS(st);
+ else if (!WIFEXITED(st))
+ rc = 1;
+
exit(rc);
usage:
fprintf(stderr, "usage: %s [-aDglnoprtv] [-e program] [--archive] [--delete] [--devices]\n"
Index: server.c
===
RCS file: /cvs/src/usr.bin/rsync/server.c,v
retrieving revision 1.8
diff -u -p -r1.8 server.c
--- server.c 6 Mar 2019 18:37:22 - 1.8
+++ server.c 22 Mar 2019 14:31:54 -
@@ -45,18 +45,15 @@ fcntl_nonblock(struct sess *sess, int fd
* The server (remote) side of the system.
* This parses the arguments given it by the remote shell then moves
* into receiver or sender mode depending upon those arguments.
- *
- * Pledges: unveil rpath, cpath, wpath, stdio, fattr.
- *
- * Pledges (dry-run): -cpath, -wpath, -fattr.
- * Pledges (!preserve_times): -fattr.
+ * Returns exit code 0 on success, 1 on failure, 2 on failure with
+ * incompatible protocols.
*/
int
rsync_server(const struct opts *opts, size_t argc, char *argv[])
{
struct sess sess;
int fdin = STDIN_FILENO,
- fdout = STDOUT_FILENO, rc = 0;
+ fdout = STDOUT_FILENO, rc = 1;
if (pledge("stdio unix rpath wpath cpath dpath fattr chown getpw unveil",
NULL) == -1)
@@ -161,7 +158,7 @@ rsync_server(const struct opts *opts, si
WARNX(, "data remains in read pipe");
#endif
- rc = 1;
+ rc = 0;
out:
return rc;
}
Index: socket.c
===
RCS file: /cvs/src/usr.bin/rsync/socket.c,v
retrieving revision 1.19
diff -u -p -r1.19 socket.c
--- socket.c 6 Mar 2019 18:37:22 - 1.19
+++ socket.c 22 Mar 2019 14:31:54 -
@@ -232,10 +232,9 @@ protocol_line(struct sess *sess, const c
}
/*
- * Pledges: dns, inet, unix, unveil, rpath, cpath, wpath, stdio, fattr, chown.
- *
- * Pledges (dry-run): -unix, -cpath, -wpath, -fattr, -chown.
- * Pledges (!preserve_times): -fattr.
+ * Talk to a remote rsync://-enabled server sender.
+ * Returns exit code 0 on success, 1 on failure, 2 on failure with
+ * incompatible protocols.
*/
int
rsync_socket(const struct opts *opts, const struct fargs *f)
@@ -243,7 +242,7 @@ rsync_socket(const struct opts *opts, co
struct sess sess;
struct source *src = NULL;
Re: [patch] Re: Possible sasyncd memory leak ?
W dniu 22.03.2019 o 11:19, Michał Koc pisze:
W dniu 21.03.2019 o 11:52, Otto Moerbeek pisze:
On Thu, Mar 21, 2019 at 09:28:28AM +0100, Michał Koc wrote:
W dniu 21.03.2019 o 07:21, Otto Moerbeek pisze:
On Thu, Mar 21, 2019 at 12:51:11AM +0100, Klemens Nanni wrote:
On Tue, Mar 12, 2019 at 03:19:56PM +0100, Otto Moerbeek wrote:
I also fixed a case of parsing IPv6 addresses.
Anyone willing to ok?
See comments inline.
And now also with a lexer bug fixed. Earlier I thougt it was an
order
dependency in the clauses. But is was an order dependency in comment
lines and empty lines.
+check_peer_addr(const char *peer_addr)
+{
+ int valid = 1;
+ short peer_family = AF_UNSPEC;
+ struct ifaddrs *ifap = NULL, *ifa;
+ struct syncpeer *peer;
+ struct sockaddr_in sa;
+ struct sockaddr_in6 sa6;
+
+ if (inet_pton(AF_INET, peer_addr, _addr) == 1)
+ peer_family = AF_INET;
+
+ if (peer_family == AF_UNSPEC && inet_pton(AF_INET6, peer_addr,
+ _addr) == 1)
+ peer_family = AF_INET6;
`peer_addr' must not be a CIDR network, so I'd go with the more AF
agnostic getaddrinfo(3) and check for res->ai_family in any case...
+ if (peer_family == AF_UNSPEC) {
+ log_msg(2, "config: skip unparseable peer %s", peer_addr);
+ valid = 0;
+ }
..but `peer_addr' may also be a hostname, so that is not handled by
your diff:
net.h: char *name; /* FQDN or an IP, from
conf */
getaddrinfo(3) can resolve however, thus inet_pton(3) should not
be used
here.
Either way, this is a job for host_ip() as found in pfctl or bgpd.
Other daemons like iked still have host_v4() and host_v6().
Parsers use
these functions to check for valid addresses, so I'd say sasyncd
should
be no exception and adopt the same approach.
@@ -325,7 +386,7 @@ yylex(void)
/* Numerical token? */
if (isdigit(*confptr)) {
for (p = confptr; *p; p++)
- if (*p == '.') /* IP address, or bad input */
+ if (*p == '.' || *p == ':') /* IP address, or bad
input */
This fixes the parser as in
# echo peer 2001:db8::1 > conf
# sasyncd -dnv -c conf
config: syntax error
# ./obj/sasyncd -dnv -c conf
configuration OK
But I have not actually tested this with a proper IPv6 setup since
I do
not use sasyncd; did you?
@@ -397,6 +458,9 @@ conf_parse_file(char *cfgfile)
if (*s == '#') {
while (*s != '\n' && s < buf + conflen)
s++;
+ while (*s == '\n' && s < buf + conflen)
+ s++;
+ s--;
OK kn for this fix alone.
I'll test an ipv6 seup and commit the lexer parts if those work.
Michal, can you work on the first set of comments? I think Klemens is
right.
-Otto
Of course, I'll follow the comments soon
Best Regards
M.K.
the diff is ready, what happened here:
1. host => ip manipulation moved to host_ip() function in net.c and is
using getaddrinfo()
2. net_set_sa() in net.c modified to use host_ip()
Bets Regards
M.K
Additional range check when comparing memory contents
Index: conf.y
===
RCS file: /cvs/src/usr.sbin/sasyncd/conf.y,v
retrieving revision 1.19
diff -u -p -r1.19 conf.y
--- conf.y 9 Apr 2017 02:40:24 - 1.19
+++ conf.y 22 Mar 2019 14:27:49 -
@@ -30,8 +30,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -48,6 +50,7 @@ struct cfgstate cfgstate;
intconflen = 0;
char *confbuf, *confptr;
+intcheck_peer_addr(const char *);
intyyparse(void);
intyylex(void);
void yyerror(const char *);
@@ -172,17 +175,8 @@ setting: INTERFACE STRING
| PEER STRING
{
struct syncpeer *peer;
- int duplicate = 0;
- for (peer = LIST_FIRST(); peer;
-peer = LIST_NEXT(peer, link))
- if (strcmp($2, peer->name) == 0) {
- duplicate++;
- break;
- }
- if (duplicate)
- free($2);
- else {
+ if (check_peer_addr($2)) {
peer = calloc(1, sizeof *peer);
if (!peer) {
log_err("config: calloc(1, %lu) "
@@ -191,10 +185,11 @@ setting : INTERFACE STRING
YYERROR;
}
peer->name = $2;
- }
- LIST_INSERT_HEAD(, peer, link);
- cfgstate.peercnt++;
- log_msg(2, "config: add peer %s", peer->name);
+
Re: [4/4] Re: Add support for Meinberg DCF600USB to umbg(4)
OK On 2019 Mar 22 (Fri) at 10:04:37 +0100 (+0100), Paul de Weerd wrote: :Index: GENERIC :=== :RCS file: /home/OpenBSD/cvs/src/sys/arch/amd64/conf/GENERIC,v :retrieving revision 1.466 :diff -u -p -r1.466 GENERIC :--- GENERIC19 Jan 2019 03:24:18 - 1.466 :+++ GENERIC22 Mar 2019 08:10:33 - :@@ -306,6 +306,7 @@ urtw* at uhub?# Realtek 8187 : rsu* at uhub?# Realtek RTL8188SU/RTL8191SU/RTL8192SU : urtwn*at uhub?# Realtek RTL8188CU/RTL8192CU : udcf* at uhub?# Gude Expert mouseCLOCK :+umbg* at uhub?# Meinberg Funkuhren USB5131/DCF600USB : umb* at uhub?# Mobile Broadband Interface Model : uthum*at uhidev? # TEMPerHUM sensor : ugold*at uhidev? # gold TEMPer sensor : : :-- :>[<++>-]<+++.>+++[<-->-]<.>+++[<+ :+++>-]<.>++[<>-]<+.--.[-] : http://www.weirdnet.nl/ :
Re: [3/4] Re: Add support for Meinberg DCF600USB to umbg(4)
OK
On 2019 Mar 22 (Fri) at 10:04:19 +0100 (+0100), Paul de Weerd wrote:
:
:Index: share/man/man4/umbg.4
:===
:RCS file: /home/OpenBSD/cvs/src/share/man/man4/umbg.4,v
:retrieving revision 1.4
:diff -u -p -r1.4 umbg.4
:--- share/man/man4/umbg.4 16 Jul 2013 16:05:49 - 1.4
:+++ share/man/man4/umbg.4 20 Mar 2019 12:16:03 -
:@@ -19,7 +19,7 @@
: .Os
: .Sh NAME
: .Nm umbg
:-.Nd Meinberg Funkuhren USB5131 timedelta sensor
:+.Nd Meinberg Funkuhren USB5131 and DCF600USB timedelta sensors
: .Sh SYNOPSIS
: .Cd "umbg* at uhub?"
: .Sh DESCRIPTION
:Index: sys/dev/usb/umbg.c
:===
:RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/umbg.c,v
:retrieving revision 1.25
:diff -u -p -r1.25 umbg.c
:--- sys/dev/usb/umbg.c 30 Dec 2017 20:47:00 - 1.25
:+++ sys/dev/usb/umbg.c 22 Mar 2019 08:29:40 -
:@@ -156,8 +156,9 @@ umbg_match(struct device *parent, void *
: if (uaa->iface == NULL)
: return UMATCH_NONE;
:
:- return uaa->vendor == USB_VENDOR_MEINBERG &&
:- uaa->product == USB_PRODUCT_MEINBERG_USB5131 ?
:+ return uaa->vendor == USB_VENDOR_MEINBERG && (
:+ uaa->product == USB_PRODUCT_MEINBERG_USB5131 ||
:+ uaa->product == USB_PRODUCT_MEINBERG_DCF600USB) ?
: UMATCH_VENDOR_PRODUCT : UMATCH_NONE;
: }
:
:@@ -172,6 +173,7 @@ umbg_attach(struct device *parent, struc
: usb_endpoint_descriptor_t *ed;
: usbd_status err;
: int signal;
:+ const char *desc;
: #ifdef UMBG_DEBUG
: char fw_id[MBG_ID_LEN];
: #endif
:@@ -182,7 +184,18 @@ umbg_attach(struct device *parent, struc
:
: sc->sc_timedelta.type = SENSOR_TIMEDELTA;
: sc->sc_timedelta.status = SENSOR_S_UNKNOWN;
:- strlcpy(sc->sc_timedelta.desc, "USB5131",
:+
:+ switch (uaa->product) {
:+ case USB_PRODUCT_MEINBERG_DCF600USB:
:+ desc = "DCF600USB";
:+ break;
:+ case USB_PRODUCT_MEINBERG_USB5131:
:+ desc = "USB5131";
:+ break;
:+ default:
:+ desc = "Unspecified Radio clock";
:+ }
:+ strlcpy(sc->sc_timedelta.desc, desc,
: sizeof(sc->sc_timedelta.desc));
: sensor_attach(>sc_sensordev, >sc_timedelta);
:
:
:--
:>[<++>-]<+++.>+++[<-->-]<.>+++[<+
:+++>-]<.>++[<>-]<+.--.[-]
: http://www.weirdnet.nl/
:
usb drivers & arches (Re: [4/4] Re: Add support for Meinberg DCF600USB to umbg(4))
On 2019/03/22 11:55, Paul de Weerd wrote:
> On Fri, Mar 22, 2019 at 10:22:15AM +, Stuart Henderson wrote:
> | $ for i in */conf/GENERIC; do grep -q ^udcf $i && grep -q ^umbg $i || echo
> ${i%%/*}; done
>
> Did you want to only find archs which DO have udcf(4) but not umbg(4)?
> Because not all of those in your list have udcf. This adds ubmg where
> we already have udcf.
Oops yes, trying to be too clever.
$ for i in `grep -l ^udcf */conf/GENERIC`; do grep -q ^umbg $i || echo
${i%%/*}; done
amd64
arm64
armv7
landisk
loongson
:-)
> As mentioned, this has not been tested at all.
This is a more general thing actually, the list of USB drivers is rather
haphazard at the moment. List below (to fit <80 cols I've snipped i386
which has all drivers present in any other GENERIC config, amd64 which
is only missing umbg, and sgi with all its various different configs).
Would it make sense to try unifying these for all/some arches? are
there particular space constraints for some (IIRC maybe the case on sgi,
not sure about others) or other reasons to restrict them?
ubcmtp (i386/amd64 only)
umb (i386/amd64 only)
athn: arm64 armv7 landisk loongson macppc octeon socppc sparc64
atu: arm64 armv7 hppa landisk loongson macppc octeonsparc64
aue: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
bwfm: arm64 armv7 loongson macppc
cdce:alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
cue: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
kue: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
mos: arm64 armv7 loongson macppc octeon socppc sparc64
moscom:arm64 armv7 landisk loongson macppc octeon
mue: arm64 armv7
otus: arm64 armv7 loongson macppc octeon
rsu: arm64 armv7 hppa landisk loongson macppc octeon socppc sparc64
uark:alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
uath:alpha arm64 armv7 landisk loongson macppc octeon socppc sparc64
uaudio: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
uberry:arm64 armv7 loongson macppc octeon
ubsa:alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
uchcom: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
udav:alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
udcf: arm64 armv7 landisk loongson macppc octeonsparc64
udl: arm64 armv7 hppa landisk loongson macppcsocppc
udsbr: alpha arm64 armv7 hppa landisk macppc octeonsparc64
uftdi: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
ugl: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
uipaq: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
umbg:macppc octeonsparc64
umcs: arm64 armv7 landisk loongson macppc octeon
umct:alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
umidi: alpha arm64 armv7 hppa loongson macppc sparc64
umodem: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
umsm: arm64 armv7 hppa landisk loongson macppc octeon
uonerng: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
uow: alpha arm64 armv7 hppa macppc octeonsparc64
upgt: arm64 armv7 loongson macppc octeon
upl: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
uplcom: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
ure: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
url: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
urndis: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
urng:alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
urtw: arm64 armv7 loongson macppc octeon
urtwn: arm64 armv7 landisk loongson macppc octeon socppc sparc64
uscom: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
uslcom: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
uticom:arm64 armv7 octeon
uts: arm64 armv7 macppc
utvfu: alpha arm64 armv7 loongson macppc octeonsparc64
uvideo: alpha arm64 armv7 loongson macppc octeonsparc64
uvisor: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
uvscom: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
wi: alpha arm64 armv7 hppa landisk loongson macppc octeonsparc64
zyd: arm64 armv7 hppa landisk loongson macppc octeon socppc sparc64
Re: [4/4] Re: Add support for Meinberg DCF600USB to umbg(4)
On Fri, Mar 22, 2019 at 10:22:15AM +, Stuart Henderson wrote:
| $ for i in */conf/GENERIC; do grep -q ^udcf $i && grep -q ^umbg $i || echo
${i%%/*}; done
Did you want to only find archs which DO have udcf(4) but not umbg(4)?
Because not all of those in your list have udcf. This adds ubmg where
we already have udcf.
As mentioned, this has not been tested at all.
Index: arm64/conf/GENERIC
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/arm64/conf/GENERIC,v
retrieving revision 1.96
diff -u -p -r1.96 GENERIC
--- arm64/conf/GENERIC 3 Feb 2019 14:03:36 - 1.96
+++ arm64/conf/GENERIC 22 Mar 2019 10:50:20 -
@@ -299,6 +299,7 @@ urtw* at uhub?# Realtek 8187
rsu* at uhub?# Realtek RTL8188SU/RTL8191SU/RTL8192SU
urtwn* at uhub?# Realtek RTL8188CU/RTL8192CU
udcf* at uhub?# Gude Expert mouseCLOCK
+umbg* at uhub?# Meinberg Funkuhren USB5131/DCF600USB
uthum* at uhidev? # TEMPerHUM sensor
ugold* at uhidev? # gold TEMPer sensor
utrh* at uhidev? # USBRH sensor
Index: armv7/conf/GENERIC
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.121
diff -u -p -r1.121 GENERIC
--- armv7/conf/GENERIC 12 Jan 2019 19:37:16 - 1.121
+++ armv7/conf/GENERIC 22 Mar 2019 10:50:34 -
@@ -326,6 +326,7 @@ urtw* at uhub?# Realtek 8187
rsu* at uhub?# Realtek RTL8188SU/RTL8191SU/RTL8192SU
urtwn* at uhub?# Realtek RTL8188CU/RTL8192CU
udcf* at uhub?# Gude Expert mouseCLOCK
+umbg* at uhub?# Meinberg Funkuhren USB5131/DCF600USB
uthum* at uhidev? # TEMPerHUM sensor
ugold* at uhidev? # gold TEMPer sensor
utrh* at uhidev? # USBRH sensor
Index: landisk/conf/GENERIC
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/landisk/conf/GENERIC,v
retrieving revision 1.53
diff -u -p -r1.53 GENERIC
--- landisk/conf/GENERIC22 Aug 2018 15:38:46 - 1.53
+++ landisk/conf/GENERIC22 Mar 2019 10:50:53 -
@@ -162,6 +162,7 @@ rsu*at uhub?# Realtek
RTL8188SU/RTL81
urtwn* at uhub?# Realtek RTL8188CU/RTL8192CU
zyd* at uhub?# Zydas ZD1211
udcf* at uhub?# Gude Expert mouseCLOCK
+umbg* at uhub?# Meinberg Funkuhren USB5131/DCF600USB
uthum* at uhidev? # TEMPerHUM sensor
ugold* at uhidev? # gold TEMPer sensor
utwitch* at uhidev?# YUREX BBU sensor
Index: loongson/conf/GENERIC
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/loongson/conf/GENERIC,v
retrieving revision 1.59
diff -u -p -r1.59 GENERIC
--- loongson/conf/GENERIC 22 Aug 2018 15:38:46 - 1.59
+++ loongson/conf/GENERIC 22 Mar 2019 10:51:09 -
@@ -192,6 +192,7 @@ wi* at uhub?# WaveLAN IEEE 802.11DS
zyd* at uhub?# Zydas ZD1211
uberry*at uhub?# Research In Motion BlackBerry
udcf* at uhub?# Gude Expert mouseCLOCK
+umbg* at uhub?# Meinberg Funkuhren USB5131/DCF600USB
uthum* at uhidev? # TEMPerHUM sensor
ugold* at uhidev? # gold TEMPer sensor
utwitch* at uhidev? # YUREX BBU sensor
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: [4/4] Re: Add support for Meinberg DCF600USB to umbg(4)
On Fri, Mar 22, 2019 at 10:22:15AM +, Stuart Henderson wrote:
| it's missing on some others too;
|
| $ for i in */conf/GENERIC; do grep -q ^udcf $i && grep -q ^umbg $i || echo
${i%%/*}; done
| alpha
| amd64
| arm64
| armv7
| hppa
| landisk
| loongson
| luna88k
| socppc
Yes. I have some of those (some even in a working condition), but
haven't tried yet. My amd64 is the fastest machine (platform) I have,
the others I would first need to dig out, update and get a source tree
on. That'll take me a lot more time - I wanted to send this out
before going down that route.
Paul
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: bypass interface input queues for vlan(4)
On 23.2.2019. 10:35, David Gwynne wrote: > On Fri, Feb 22, 2019 at 09:56:58AM -0300, Martin Pieuchot wrote: >> On 22/02/19(Fri) 15:01, David Gwynne wrote: >>> On Thu, Feb 21, 2019 at 04:29:27PM -0300, Martin Pieuchot wrote: On 21/02/19(Thu) 14:19, David Gwynne wrote: > right now we add vlan_input as a possible input handler on the parent > interface, and if the packet is for a vlan we take it and pretend we > received it on the vlan interface by calling if_input against that mbuf. > > as mpi notes, the if input queue stuff looks like a lot of work, > especially for a single packet. my opinion is that we got away with > the if input stuff we've done to try and encourage an mpsafe network > stack because we amortised the cost of it over many packets off the > hardware ring. vlan does it a packet at a time. > > this moves the handling of vlan packets back into ether_input by > calling vlan_input directly on packets that are either marked as vlan > tagged or have a vlan ethertype. note that we have to do that anyway, > this just makes it explicit. > > vlan_input is then tweaked to implement all the important bits of if > input. part of what if input does is count the packets. because vlan > already has per cpu counters for bypassing queues on output, we can use > them again for input from any cpu. if i ever get round to making a > driver handle multiple rx rings this means we can rx vlan packets > concurrently, they don't get serialised to a single if input q. > > finally, hrvoje popovski has tested this diff and get's a significant > bump with it. on a machine that can forward 1100Kpps without vlan, it > goes from 790Kpps with vlan to 870Kpps. On a box that can do 730Kpps > without vlans, it goes from 550Kpps with vlan to 840Kpps. We're > still trying to figure that last one out, but it does appear to be > faster. > > thoughts? ok? Why do we need to move stuff to ether_input() if all we want is to bypass ifiq_input()? Isn't a 3 line diff enough^^ ? >>> Fair point. It turns out it's not quite three lines, but it's still >>> smaller. >> I'm unhappy to see the bpf & packet magic reappear in pseudo-drivers. >> >> This is going to spread in every pseudo-driver, no? So why not keeping >> it in the new API? Should we document if_input() vs if_input_one()? >> Should we assert that if_input_one() is only called from a network >> thread? If yes, should we pick a better name? > Maybe. How's if_vinput? And as you suggest, it can do some more of > the magic? Let me try converting a few more drivers before we > burden it with constraints. Hi all, this diff really nicely increase forwarding performance over vlan. i tested it with this loop vlan300 destroy && sh netstart && sleep 5 && ifconfig vlan400 destroy && sh netstart && sleep 5 && ifconfig ix3 down && sh netstart and box seems stable ..
Re: [4/4] Re: Add support for Meinberg DCF600USB to umbg(4)
On 2019/03/22 10:04, Paul de Weerd wrote:
> Index: GENERIC
> ===
> RCS file: /home/OpenBSD/cvs/src/sys/arch/amd64/conf/GENERIC,v
> retrieving revision 1.466
> diff -u -p -r1.466 GENERIC
> --- GENERIC 19 Jan 2019 03:24:18 - 1.466
> +++ GENERIC 22 Mar 2019 08:10:33 -
> @@ -306,6 +306,7 @@ urtw* at uhub?# Realtek 8187
> rsu* at uhub?# Realtek RTL8188SU/RTL8191SU/RTL8192SU
> urtwn* at uhub?# Realtek RTL8188CU/RTL8192CU
> udcf*at uhub?# Gude Expert mouseCLOCK
> +umbg*at uhub?# Meinberg Funkuhren USB5131/DCF600USB
> umb* at uhub?# Mobile Broadband Interface Model
> uthum* at uhidev? # TEMPerHUM sensor
> ugold* at uhidev? # gold TEMPer sensor
>
>
> --
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
> http://www.weirdnet.nl/
>
it's missing on some others too;
$ for i in */conf/GENERIC; do grep -q ^udcf $i && grep -q ^umbg $i || echo
${i%%/*}; done
alpha
amd64
arm64
armv7
hppa
landisk
loongson
luna88k
socppc
Re: [patch] Re: Possible sasyncd memory leak ?
W dniu 21.03.2019 o 11:52, Otto Moerbeek pisze:
On Thu, Mar 21, 2019 at 09:28:28AM +0100, Michał Koc wrote:
W dniu 21.03.2019 o 07:21, Otto Moerbeek pisze:
On Thu, Mar 21, 2019 at 12:51:11AM +0100, Klemens Nanni wrote:
On Tue, Mar 12, 2019 at 03:19:56PM +0100, Otto Moerbeek wrote:
I also fixed a case of parsing IPv6 addresses.
Anyone willing to ok?
See comments inline.
And now also with a lexer bug fixed. Earlier I thougt it was an order
dependency in the clauses. But is was an order dependency in comment
lines and empty lines.
+check_peer_addr(const char *peer_addr)
+{
+ int valid = 1;
+ short peer_family = AF_UNSPEC;
+ struct ifaddrs *ifap = NULL, *ifa;
+ struct syncpeer *peer;
+ struct sockaddr_in sa;
+ struct sockaddr_in6 sa6;
+
+ if (inet_pton(AF_INET, peer_addr, _addr) == 1)
+ peer_family = AF_INET;
+
+ if (peer_family == AF_UNSPEC && inet_pton(AF_INET6, peer_addr,
+ _addr) == 1)
+ peer_family = AF_INET6;
`peer_addr' must not be a CIDR network, so I'd go with the more AF
agnostic getaddrinfo(3) and check for res->ai_family in any case...
+ if (peer_family == AF_UNSPEC) {
+ log_msg(2, "config: skip unparseable peer %s", peer_addr);
+ valid = 0;
+ }
..but `peer_addr' may also be a hostname, so that is not handled by
your diff:
net.h: char*name; /* FQDN or an IP, from conf */
getaddrinfo(3) can resolve however, thus inet_pton(3) should not be used
here.
Either way, this is a job for host_ip() as found in pfctl or bgpd.
Other daemons like iked still have host_v4() and host_v6(). Parsers use
these functions to check for valid addresses, so I'd say sasyncd should
be no exception and adopt the same approach.
@@ -325,7 +386,7 @@ yylex(void)
/* Numerical token? */
if (isdigit(*confptr)) {
for (p = confptr; *p; p++)
- if (*p == '.') /* IP address, or bad input */
+ if (*p == '.' || *p == ':') /* IP address, or bad input
*/
This fixes the parser as in
# echo peer 2001:db8::1 > conf
# sasyncd -dnv -c conf
config: syntax error
# ./obj/sasyncd -dnv -c conf
configuration OK
But I have not actually tested this with a proper IPv6 setup since I do
not use sasyncd; did you?
@@ -397,6 +458,9 @@ conf_parse_file(char *cfgfile)
if (*s == '#') {
while (*s != '\n' && s < buf + conflen)
s++;
+ while (*s == '\n' && s < buf + conflen)
+ s++;
+ s--;
OK kn for this fix alone.
I'll test an ipv6 seup and commit the lexer parts if those work.
Michal, can you work on the first set of comments? I think Klemens is
right.
-Otto
Of course, I'll follow the comments soon
Best Regards
M.K.
the diff is ready, what happened here:
1. host => ip manipulation moved to host_ip() function in net.c and is
using getaddrinfo()
2. net_set_sa() in net.c modified to use host_ip()
Bets Regards
M.K.
Index: conf.y
===
RCS file: /cvs/src/usr.sbin/sasyncd/conf.y,v
retrieving revision 1.19
diff -u -p -r1.19 conf.y
--- conf.y 9 Apr 2017 02:40:24 - 1.19
+++ conf.y 22 Mar 2019 09:16:37 -
@@ -30,8 +30,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -48,6 +50,7 @@ struct cfgstate cfgstate;
intconflen = 0;
char *confbuf, *confptr;
+intcheck_peer_addr(const char *);
intyyparse(void);
intyylex(void);
void yyerror(const char *);
@@ -172,17 +175,8 @@ setting: INTERFACE STRING
| PEER STRING
{
struct syncpeer *peer;
- int duplicate = 0;
- for (peer = LIST_FIRST(); peer;
-peer = LIST_NEXT(peer, link))
- if (strcmp($2, peer->name) == 0) {
- duplicate++;
- break;
- }
- if (duplicate)
- free($2);
- else {
+ if (check_peer_addr($2)) {
peer = calloc(1, sizeof *peer);
if (!peer) {
log_err("config: calloc(1, %lu) "
@@ -191,10 +185,11 @@ setting : INTERFACE STRING
YYERROR;
}
peer->name = $2;
- }
- LIST_INSERT_HEAD(, peer, link);
- cfgstate.peercnt++;
-
[5/4] Re: Add support for Meinberg DCF600USB to umbg(4)
Bonus diff - make explicit in the GENERIC configs that already have umbg(4), that this driver now supports DCF600USB too Index: i386/conf/GENERIC === RCS file: /home/OpenBSD/cvs/src/sys/arch/i386/conf/GENERIC,v retrieving revision 1.839 diff -u -p -r1.839 GENERIC --- i386/conf/GENERIC 18 Jan 2019 01:34:50 - 1.839 +++ i386/conf/GENERIC 22 Mar 2019 09:08:51 - @@ -318,7 +318,7 @@ urtw* at uhub?# Realtek 8187 rsu* at uhub?# Realtek RTL8188SU/RTL8191SU/RTL8192SU urtwn* at uhub?# Realtek RTL8188CU/RTL8192CU udcf* at uhub?# Gude Expert mouseCLOCK -umbg* at uhub?# Meinberg Funkuhren USB5131 +umbg* at uhub?# Meinberg Funkuhren USB5131/DCF600USB umb* at uhub?# Mobile Broadband Interface Model uthum* at uhidev? # TEMPerHUM sensor ugold* at uhidev? # gold TEMPer sensor Index: macppc/conf/GENERIC === RCS file: /home/OpenBSD/cvs/src/sys/arch/macppc/conf/GENERIC,v retrieving revision 1.266 diff -u -p -r1.266 GENERIC --- macppc/conf/GENERIC 21 Sep 2018 12:42:34 - 1.266 +++ macppc/conf/GENERIC 22 Mar 2019 09:08:56 - @@ -293,7 +293,7 @@ zyd*at uhub?# Zydas ZD1211 upgt* at uhub?# Conexant/Intersil PrismGT SoftMAC USB urtw* at uhub?# Realtek 8187 udcf* at uhub?# Gude Expert mouseCLOCK -umbg* at uhub?# Meinberg Funkuhren USB5131 +umbg* at uhub?# Meinberg Funkuhren USB5131/DCF600USB uthum* at uhidev? # TEMPerHUM sensor ugold* at uhidev? # gold TEMPer sensor utrh* at uhidev? # USBRH sensor Index: octeon/conf/GENERIC === RCS file: /home/OpenBSD/cvs/src/sys/arch/octeon/conf/GENERIC,v retrieving revision 1.45 diff -u -p -r1.45 GENERIC --- octeon/conf/GENERIC 12 Jan 2019 16:59:38 - 1.45 +++ octeon/conf/GENERIC 22 Mar 2019 09:08:58 - @@ -175,7 +175,7 @@ urtw* at uhub?# Realtek 8187 rsu* at uhub?# Realtek RTL8188SU/RTL8191SU/RTL8192SU urtwn* at uhub?# Realtek RTL8188CU/RTL8192CU udcf* at uhub?# Gude Expert mouseCLOCK -umbg* at uhub?# Meinberg Funkuhren USB5131 +umbg* at uhub?# Meinberg Funkuhren USB5131/DCF600USB uthum* at uhidev? # TEMPerHUM sensor ugold* at uhidev? # gold TEMPer sensor utrh* at uhidev? # USBRH sensor Index: sparc64/conf/GENERIC === RCS file: /home/OpenBSD/cvs/src/sys/arch/sparc64/conf/GENERIC,v retrieving revision 1.309 diff -u -p -r1.309 GENERIC --- sparc64/conf/GENERIC29 Jan 2019 02:43:05 - 1.309 +++ sparc64/conf/GENERIC22 Mar 2019 09:09:04 - @@ -247,7 +247,7 @@ udsbr* at uhub?# D-Link DSB-R100 radio radio* at udsbr? # USB radio ugen* at uhub?# USB Generic driver udcf* at uhub?# Gude Expert mouseCLOCK -umbg* at uhub?# Meinberg Funkuhren USB5131 +umbg* at uhub?# Meinberg Funkuhren USB5131/DCF600USB uthum* at uhidev? # TEMPerHUM sensor ugold* at uhidev? # gold TEMPer sensor utwitch* at uhidev?# UYUREX BBU sensor -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
[2/4] Re: Add support for Meinberg DCF600USB to umbg(4)
Index: usbdevs.h
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.707
diff -u -p -r1.707 usbdevs.h
--- usbdevs.h 24 Feb 2019 17:35:44 - 1.707
+++ usbdevs.h 22 Mar 2019 07:48:28 -
@@ -1,10 +1,10 @@
-/* $OpenBSD: usbdevs.h,v 1.707 2019/02/24 17:35:44 patrick Exp $ */
+/* $OpenBSD$ */
/*
* THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
*
* generated from:
- * OpenBSD: usbdevs,v 1.694 2019/01/14 03:28:03 jmatthew Exp
+ * OpenBSD: usbdevs,v 1.695 2019/02/24 17:35:29 patrick Exp
*/
/* $NetBSD: usbdevs,v 1.322 2003/05/10 17:47:14 hamajima Exp $ */
@@ -2931,6 +2931,7 @@
/* Meinberg Funkuhren products */
#defineUSB_PRODUCT_MEINBERG_USB51310x0301 /* USB 5131
DCF77 - Radio Clock */
+#defineUSB_PRODUCT_MEINBERG_DCF600USB 0x0302 /* DCF600USB -
Radio Clock */
/* Melco, Inc products */
#defineUSB_PRODUCT_MELCO_LUATX10x0001 /* LUA-TX
Ethernet */
Index: usbdevs_data.h
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.701
diff -u -p -r1.701 usbdevs_data.h
--- usbdevs_data.h 24 Feb 2019 17:35:44 - 1.701
+++ usbdevs_data.h 22 Mar 2019 07:48:28 -
@@ -1,10 +1,10 @@
-/* $OpenBSD: usbdevs_data.h,v 1.701 2019/02/24 17:35:44 patrick Exp $
*/
+/* $OpenBSD$ */
/*
* THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
*
* generated from:
- * OpenBSD: usbdevs,v 1.694 2019/01/14 03:28:03 jmatthew Exp
+ * OpenBSD: usbdevs,v 1.695 2019/02/24 17:35:29 patrick Exp
*/
/* $NetBSD: usbdevs,v 1.322 2003/05/10 17:47:14 hamajima Exp $ */
@@ -7016,6 +7016,10 @@ const struct usb_known_product usb_known
{
USB_VENDOR_MEINBERG, USB_PRODUCT_MEINBERG_USB5131,
"USB 5131 DCF77 - Radio Clock",
+ },
+ {
+ USB_VENDOR_MEINBERG, USB_PRODUCT_MEINBERG_DCF600USB,
+ "DCF600USB - Radio Clock",
},
{
USB_VENDOR_MELCO, USB_PRODUCT_MELCO_LUATX1,
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
[4/4] Re: Add support for Meinberg DCF600USB to umbg(4)
Index: GENERIC === RCS file: /home/OpenBSD/cvs/src/sys/arch/amd64/conf/GENERIC,v retrieving revision 1.466 diff -u -p -r1.466 GENERIC --- GENERIC 19 Jan 2019 03:24:18 - 1.466 +++ GENERIC 22 Mar 2019 08:10:33 - @@ -306,6 +306,7 @@ urtw* at uhub?# Realtek 8187 rsu* at uhub?# Realtek RTL8188SU/RTL8191SU/RTL8192SU urtwn* at uhub?# Realtek RTL8188CU/RTL8192CU udcf* at uhub?# Gude Expert mouseCLOCK +umbg* at uhub?# Meinberg Funkuhren USB5131/DCF600USB umb* at uhub?# Mobile Broadband Interface Model uthum* at uhidev? # TEMPerHUM sensor ugold* at uhidev? # gold TEMPer sensor -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
[3/4] Re: Add support for Meinberg DCF600USB to umbg(4)
Index: share/man/man4/umbg.4
===
RCS file: /home/OpenBSD/cvs/src/share/man/man4/umbg.4,v
retrieving revision 1.4
diff -u -p -r1.4 umbg.4
--- share/man/man4/umbg.4 16 Jul 2013 16:05:49 - 1.4
+++ share/man/man4/umbg.4 20 Mar 2019 12:16:03 -
@@ -19,7 +19,7 @@
.Os
.Sh NAME
.Nm umbg
-.Nd Meinberg Funkuhren USB5131 timedelta sensor
+.Nd Meinberg Funkuhren USB5131 and DCF600USB timedelta sensors
.Sh SYNOPSIS
.Cd "umbg* at uhub?"
.Sh DESCRIPTION
Index: sys/dev/usb/umbg.c
===
RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/umbg.c,v
retrieving revision 1.25
diff -u -p -r1.25 umbg.c
--- sys/dev/usb/umbg.c 30 Dec 2017 20:47:00 - 1.25
+++ sys/dev/usb/umbg.c 22 Mar 2019 08:29:40 -
@@ -156,8 +156,9 @@ umbg_match(struct device *parent, void *
if (uaa->iface == NULL)
return UMATCH_NONE;
- return uaa->vendor == USB_VENDOR_MEINBERG &&
- uaa->product == USB_PRODUCT_MEINBERG_USB5131 ?
+ return uaa->vendor == USB_VENDOR_MEINBERG && (
+ uaa->product == USB_PRODUCT_MEINBERG_USB5131 ||
+ uaa->product == USB_PRODUCT_MEINBERG_DCF600USB) ?
UMATCH_VENDOR_PRODUCT : UMATCH_NONE;
}
@@ -172,6 +173,7 @@ umbg_attach(struct device *parent, struc
usb_endpoint_descriptor_t *ed;
usbd_status err;
int signal;
+ const char *desc;
#ifdef UMBG_DEBUG
char fw_id[MBG_ID_LEN];
#endif
@@ -182,7 +184,18 @@ umbg_attach(struct device *parent, struc
sc->sc_timedelta.type = SENSOR_TIMEDELTA;
sc->sc_timedelta.status = SENSOR_S_UNKNOWN;
- strlcpy(sc->sc_timedelta.desc, "USB5131",
+
+ switch (uaa->product) {
+ case USB_PRODUCT_MEINBERG_DCF600USB:
+ desc = "DCF600USB";
+ break;
+ case USB_PRODUCT_MEINBERG_USB5131:
+ desc = "USB5131";
+ break;
+ default:
+ desc = "Unspecified Radio clock";
+ }
+ strlcpy(sc->sc_timedelta.desc, desc,
sizeof(sc->sc_timedelta.desc));
sensor_attach(>sc_sensordev, >sc_timedelta);
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
[1/4] Re: Add support for Meinberg DCF600USB to umbg(4)
Index: usbdevs === RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.695 diff -u -p -r1.695 usbdevs --- usbdevs 24 Feb 2019 17:35:29 - 1.695 +++ usbdevs 20 Mar 2019 11:55:44 - @@ -2924,6 +2924,7 @@ product MEI S2000 0x1101 Series 2000 /* Meinberg Funkuhren products */ product MEINBERG USB5131 0x0301 USB 5131 DCF77 - Radio Clock +product MEINBERG DCF600USB 0x0302 DCF600USB - Radio Clock /* Melco, Inc products */ product MELCO LUATX1 0x0001 LUA-TX Ethernet -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Add support for Meinberg DCF600USB to umbg(4)
Hi all,
After Peter J. Philipp asked about Meinberg DCF clock support on misc@
in https://marc.info/?l=openbsd-misc=155205024420585=2 I was also
interested in the question he asked. After some consideration, I
decided to try, so I bought a Meinberg DCF600USB which was delivered
yesterday. I unpacked it this morning and hooked it up to find the
kernel reporting:
2019-03-22T07:46:55.515Z pom /bsd: ugen0 at uhub3 port 2 "Meinberg DCF600USB"
rev 2.00/1.13 addr 7
After that I
1/3: added the USB product ID (0x0302) to usbdevs
2/3: ran `make usbdevs` to update usbdevs{_data,}.h
3/3: updated the driver (and manpage) to support DCF600USB
Unfortunately, after a reboot I still got
2019-03-22T08:00:48.096Z pom /bsd: ugen0 at uhub3 port 2 "Meinberg DCF600USB"
rev 2.00/1.13 addr 3
Turns out umbg(4) was never added to GENERIC for amd64. So after
4/3: add umbg(4) to amd64 GENERIC kernel config
I now have
[weerd@pom] $ dmesg | grep umbg0
umbg0 at uhub3 port 2 configuration 1 interface 0 "Meinberg DCF600USB" rev
2.00/1.13 addr 3
umbg0: not synchronized, freerun
(full dmesg at the bottom of this mail)
Immediately after boot, it's not synced:
[weerd@pom] $ sysctl hw.sensors.umbg0
hw.sensors.umbg0.percent0=100.00% (Signal), WARNING, Fri Mar 22 09:39:18.964
hw.sensors.umbg0.timedelta0=-0.436787 secs (DCF600USB), OK, Fri Mar 22
09:39:18.964
but after some uptime:
[weerd@pom] $ sysctl hw.sensors.umbg0
hw.sensors.umbg0.percent0=100.00% (Signal), OK, Fri Mar 22 09:58:14.412
hw.sensors.umbg0.timedelta0=-0.008610 secs (DCF600USB), OK, Fri Mar 22
09:58:14.412
And ntpd is happy with this sensor:
[weerd@pom] $ ntpctl -s Sensors
sensor
wt gd st next poll offset correction
umbg0
1 1 0 15s 15s 8.598ms 0.000ms
I'm sending the 4 diffs in separate e-mails; comments and/or commits
very welcome.
Paul
OpenBSD 6.5-beta (GENERIC.MP) #14: Fri Mar 22 09:32:08 CET 2019
we...@pom.alm.weirdnet.nl:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34243903488 (32657MB)
avail mem = 33195778048 (31657MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec410 (88 entries)
bios0: vendor Dell Inc. version "A22" date 02/01/2018
bios0: Dell Inc. OptiPlex 9020
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT
ASF! DMAR
acpi0: wakeup devices UAR1(S3) PXSX(S4) RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4)
RP05(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S4)
HDEF(S4) PEG0(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3692.03 MHz, 06-3c-03
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.46 MHz, 06-3c-03
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.46 MHz, 06-3c-03
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.46 MHz, 06-3c-03
cpu3:
Re: smtpctl, mailer.conf: drop send-mail (was: mail(1): use "sendmail" as argv[0] for sendmail)
On Tue, Mar 19 2019 15:28:48 -0600, Todd C. Miller wrote: > On Tue, 19 Mar 2019 23:24:24 +0200, Lauri Tirkkonen wrote: > > > I might be blind, but 'grep -r send-mail /usr/ports/pobj/nmh-1.7.1' > > comes up empty for me after 'make extract' in /usr/ports/mail/nmh? > > It looks like spost.c is historical code that is not actually packaged > in the distribution (though it is in the nmh repo). I did 'make fetch' in /usr/ports, extracted the results by hand (I avoided 'make extract' because that would try to compile and install dependencies), and did grep -rw send-mail on the directory where I extracted the distfiles. As far as I can tell there is nothing in ports that uses "send-mail" as argv[0] to anything. The false positives are: - 364 occurrences in emacs-26.1/; these are references to 'send-mail-function', 'send-mail-with-sendmail', 'message-send-mail', 'message-send-mail-hook', etc. - 362 occurrences in xemacs-packages/; similar to above. - 11 occurrences in gettext-0.19.8.1/; references to 'po-send-mail' in po-mode.el - 11 occurrences in mgetty-1.1.37/; options called 'success-send-mail' and 'failure-send-mail', in faxrunq/faxrunqd - 1 occurrence in git-2.21.0/Documentation/RelNotes/1.6.0.txt; typo of 'git-send-mail', when it means to say 'git-send-email'. -- Lauri Tirkkonen | lotheac @ IRCnet
