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); + i
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&r2=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, &sa.sin_addr) == 1) + peer_family = AF_INET; + + if (peer_family == AF_UNSPEC && inet_pton(AF_INET6, peer_addr, + &sa6.sin6_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(&cfgstate.peerlist); 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(&cfgstate.peerlist, peer, link); - cfgstate.peercnt++; - log_
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(&conf->rde_prefixsets); SIMPLEQ_INIT(&conf->rde_originsets); SIMPLEQ_CONCAT(&conf->rde_prefixsets, &nconf->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(&now, NULL); - TIMEVAL_TO_TIMESPEC(&now, &tv[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(&now, NULL); - TIMEVAL_TO_TIMESPEC(&now, &tv[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(&conf->rde_prefixsets); SIMPLEQ_INIT(&conf->rde_originsets); SIMPLEQ_CONCAT(&conf->rde_prefixsets, &nconf->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->sc_sensordev, &sc->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(&sess, "remote protocol is older " - "than our own (%" PRId32 " < %" PRId32 "): " - "this is not supported", - sess.rver, sess.lver); + ERRX(&sess, + "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(&sess, "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, &st, 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(&sess, "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; struc
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, &sa.sin_addr) == 1) + peer_family = AF_INET; + + if (peer_family == AF_UNSPEC && inet_pton(AF_INET6, peer_addr, + &sa6.sin6_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(&cfgstate.peerlist); 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(&cfgstate.peerlist, peer, link); - cfgstate.peercnt++; - log_msg(2, "config: ad
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->sc_sensordev, &sc->sc_timedelta); : : :-- :>[<++>-]<+++.>+++[<-->-]<.>+++[<+ :+++>-]<.>++[<>-]<+.--.[-] : http://www.weirdnet.nl/ :
Re: [1/4] Re: Add support for Meinberg DCF600USB to umbg(4)
OK On 2019 Mar 22 (Fri) at 10:03:26 +0100 (+0100), Paul de Weerd wrote: : :Index: usbdevs :=== :RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/usbdevs,v :retrieving revision 1.695 :diff -u -p -r1.695 usbdevs :--- usbdevs24 Feb 2019 17:35:29 - 1.695 :+++ usbdevs20 Mar 2019 11:55:44 - :@@ -2924,6 +2924,7 @@ product MEI S20000x1101 Series 2000 : : /* Meinberg Funkuhren products */ : product MEINBERG USB5131 0x0301 USB 5131 DCF77 - Radio Clock :+product MEINBERG DCF600USB0x0302 DCF600USB - Radio Clock : : /* Melco, Inc products */ : product MELCO LUATX1 0x0001 LUA-TX Ethernet : :-- :>[<++>-]<+++.>+++[<-->-]<.>+++[<+ :+++>-]<.>++[<>-]<+.--.[-] : 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, &sa.sin_addr) == 1) + peer_family = AF_INET; + + if (peer_family == AF_UNSPEC && inet_pton(AF_INET6, peer_addr, + &sa6.sin6_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(&cfgstate.peerlist); 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(&cfgstate.peerlist, peer, link); -
[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->sc_sensordev, &sc->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&m=155205024420585&w=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: 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,P
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