Re: ospfd: prevent additional ospfd from starting
On Mon, Aug 27, 2018 at 11:33:19PM +0200, Remi Locherer wrote:
> On Fri, Aug 24, 2018 at 12:21:31PM +0200, Remi Locherer wrote:
> > On Fri, Aug 24, 2018 at 08:58:12AM +0200, Claudio Jeker wrote:
> > > On Wed, Aug 22, 2018 at 12:12:10AM +0200, Remi Locherer wrote:
> > > > On Tue, Aug 21, 2018 at 05:54:18PM +0100, Stuart Henderson wrote:
> > > > > On 2018/08/21 17:16, Remi Locherer wrote:
> > > > > > Hi tech,
> > > > > >
> > > > > > recently we had a short outage in our network. A script started an
> > > > > > additional
> > > > > > ospfd instance because the -n flag for config test was missing.
> > > > >
> > > > > This is a problem with bgpd as well, last time I did this it killed
> > > > > one of the
> > > > > *other* routers on the network (i.e. not just the one where I
> > > > > accidentally ran
> > > > > 2x bgpd...).
> > > > >
> > > > > > What then happend was not nice:
> > > > > > - The new ospfd unlinked the control socket of the first ospfd
> > > > > > - The new ospfd removed all routes from the first ospfd
> > > > > > - The new ospfd was not able to build up an adjacency and therefore
> > > > > > could
> > > > > > not install the routes needed for a recovery.
> > > > > > - Both ospfd instances were running but non-functional.
> > > > > >
> > > > > > Of course the faulty script is fixed by now. ;-)
> > > > > >
> > > > > > It would be nice if ospfd could prevent such a situation.
> > > > > >
> > > > > > Below diff does these things:
> > > > > > - Detect a running ospfd by first doing a connect on the control
> > > > > > socket.
> > > > > > - Do not delete the control socket on exit.
> > > > > > - This could delete the socket of another instance.
> > > > > > - Unlinking the socket on shutdown will be in the way once we add
> > > > > > pledge
> > > > > > to the main process. It was removed recently from various
> > > > > > daemons.
> > > > >
> > > > > This all sounds very sensible.
> > > > >
> > > > > > - Do not delete routes added by another process even if they have
> > > > > > prio RTP_OSPF. Without this the new ospfd will remove all the
> > > > > > routes
> > > > > > of the first one.
> > > > >
> > > > > I'm unsure about this, the above changes stop the new ospfd from
> > > > > running
> > > > > don't they, so that shouldn't be a problem?
> > > >
> > > > It stops to late. kr_init happens before and kill all existing routes
> > > > with
> > > > priority 32. And again in the shutdown function of ospfd.
> > > > >
> > > > > If an ospfd blows up for whatever reason, it would be quite
> > > > > inconvenient
> > > > > if it needs manual route tweaks rather than just 'rcctl start ospfd'
> > > > > to fix it ..
> > > >
> > > > Yes, this is not optimal.
> > > >
> > > > The new diff below defers kr_init until the ospf engine notifies the
> > > > parent
> > > > that the control socket is ready. In case the ospf engine exits because
> > > > the
> > > > control socket is already in use no routes are known that could be
> > > > removed.
> > > >
> > > > With this ospfd keeps the behaviour of removing foreign routes with
> > > > priority 32.
> > > >
> > > > Better?
> > > >
> > >
> > > Why are we not checking the control socket in the parent?
> > > Also it may be better to create the control socket in the parent and pass
> > > it to the ospfe. This is what bgpd is doing and allows to change the path
> > > during runtime with a config reload.
> >
> > This makes sense to me. I'll come up with a new diff once I found some
> > time for it.
> >
> > But I'm not sure about changing the socket path with a reload. I plan to
> > pledge (stdio rpath sendfd wroute) and eventually unveil (read ospfd.conf)
> > the main process.
>
> New diff below creates the control socket in the main process and passes it
> to the ospf engine later on. The connect check on the control socket now
> happens very early.
>
> The diff in action looks like this:
>
> typhoon ..sbin/ospfd$ doas obj/ospfd -dv
> startup
> control_init: socket in use
> fatal in ospfd: control socket setup failed
> typhoon 1 ..sbin/ospfd$
>
>
> I borrowed the fd passing code from slaacd.
>
> >
> > >
> > > Could there be a case where this causes ospfd to hang on start in the
> > > connect? Not sure if we can sleep doing a connect() to a AF_UNIX socket.
>
> I never observed a hangin ospfctl which also does a connect on the control
> socket. But I could not find the definitiv answer.
>
> Remi
>
>
> Index: control.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/control.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 control.c
> --- control.c 24 Jan 2017 04:24:25 - 1.44
> +++ control.c 27 Aug 2018 21:17:42 -
> @@ -42,19 +42,29 @@ int
> control_init(char *path)
> {
> struct sockaddr_un sun;
> - int fd;
> + int fd, fd_check;
> mode_t old_umask;
>
> +
nits in ifconfig.8
Hi, just a couple of nits in ifconfig.8 that I found whilst struggling to get a route to fe80::1 on a VPS. 'colon-separated' and 'comma-separated' is in keeping with the style of the rest of the page. 'lowest 64th bit' > 'lowest 64 bits' is self-explanatory, I hope. Index: ifconfig.8 === RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v retrieving revision 1.317 diff -u -p -r1.317 ifconfig.8 --- ifconfig.8 13 Aug 2018 05:54:13 - 1.317 +++ ifconfig.8 28 Aug 2018 03:00:39 - @@ -122,7 +122,7 @@ a host name present in the host name dat .Xr hosts 5 ; .Dq dot notation (IPv4); -colon separated (IPv6); +colon-separated (IPv6); or CIDR notation. .It Ar dest_address Specify the address of the correspondent on the other end @@ -838,7 +838,7 @@ and Create a load balancing group consisting of up to 32 nodes. Each node is specified as a .Ar vhid:advskew -tuple in a comma separated list. +tuple in a comma-separated list. .It Cm carpdev Ar iface Attach to parent interface .Ar iface . @@ -1217,7 +1217,7 @@ Currently configured addresses will not invalid. .It Cm eui64 Fill the interface index -.Pq the lowermost 64th bit of an IPv6 address +.Pq the lowermost 64 bits of an IPv6 address automatically. .It Cm pltime Ar n Set preferred lifetime for the address, in seconds.
openssl s_time: drop SSLv2, SSLv3 APIs and symbols
If I understand correctly it is now impossible for the openssl(1) tool to open an SSLv2 or SSLv3 session with the host. We can also switch SSLv23_client_method to TLS_client_method to set a good example. ok? Index: s_time.c === RCS file: /cvs/src/usr.bin/openssl/s_time.c,v retrieving revision 1.30 diff -u -p -r1.30 s_time.c --- s_time.c28 Aug 2018 02:14:22 - 1.30 +++ s_time.c28 Aug 2018 02:21:25 - @@ -242,7 +242,7 @@ s_time_main(int argc, char **argv) } } - s_time_meth = SSLv23_client_method(); + s_time_meth = TLS_client_method(); verify_depth = 0; @@ -435,10 +435,6 @@ benchmark(int reuse_session) ver = SSL_version(scon); if (ver == TLS1_VERSION) ver = 't'; - else if (ver == SSL3_VERSION) - ver = '3'; - else if (ver == SSL2_VERSION) - ver = '2'; else ver = '*'; }
Re: ospfd: prevent additional ospfd from starting
On Fri, Aug 24, 2018 at 12:21:31PM +0200, Remi Locherer wrote:
> On Fri, Aug 24, 2018 at 08:58:12AM +0200, Claudio Jeker wrote:
> > On Wed, Aug 22, 2018 at 12:12:10AM +0200, Remi Locherer wrote:
> > > On Tue, Aug 21, 2018 at 05:54:18PM +0100, Stuart Henderson wrote:
> > > > On 2018/08/21 17:16, Remi Locherer wrote:
> > > > > Hi tech,
> > > > >
> > > > > recently we had a short outage in our network. A script started an
> > > > > additional
> > > > > ospfd instance because the -n flag for config test was missing.
> > > >
> > > > This is a problem with bgpd as well, last time I did this it killed one
> > > > of the
> > > > *other* routers on the network (i.e. not just the one where I
> > > > accidentally ran
> > > > 2x bgpd...).
> > > >
> > > > > What then happend was not nice:
> > > > > - The new ospfd unlinked the control socket of the first ospfd
> > > > > - The new ospfd removed all routes from the first ospfd
> > > > > - The new ospfd was not able to build up an adjacency and therefore
> > > > > could
> > > > > not install the routes needed for a recovery.
> > > > > - Both ospfd instances were running but non-functional.
> > > > >
> > > > > Of course the faulty script is fixed by now. ;-)
> > > > >
> > > > > It would be nice if ospfd could prevent such a situation.
> > > > >
> > > > > Below diff does these things:
> > > > > - Detect a running ospfd by first doing a connect on the control
> > > > > socket.
> > > > > - Do not delete the control socket on exit.
> > > > > - This could delete the socket of another instance.
> > > > > - Unlinking the socket on shutdown will be in the way once we add
> > > > > pledge
> > > > > to the main process. It was removed recently from various daemons.
> > > >
> > > > This all sounds very sensible.
> > > >
> > > > > - Do not delete routes added by another process even if they have
> > > > > prio RTP_OSPF. Without this the new ospfd will remove all the routes
> > > > > of the first one.
> > > >
> > > > I'm unsure about this, the above changes stop the new ospfd from running
> > > > don't they, so that shouldn't be a problem?
> > >
> > > It stops to late. kr_init happens before and kill all existing routes with
> > > priority 32. And again in the shutdown function of ospfd.
> > > >
> > > > If an ospfd blows up for whatever reason, it would be quite inconvenient
> > > > if it needs manual route tweaks rather than just 'rcctl start ospfd' to
> > > > fix it ..
> > >
> > > Yes, this is not optimal.
> > >
> > > The new diff below defers kr_init until the ospf engine notifies the
> > > parent
> > > that the control socket is ready. In case the ospf engine exits because
> > > the
> > > control socket is already in use no routes are known that could be
> > > removed.
> > >
> > > With this ospfd keeps the behaviour of removing foreign routes with
> > > priority 32.
> > >
> > > Better?
> > >
> >
> > Why are we not checking the control socket in the parent?
> > Also it may be better to create the control socket in the parent and pass
> > it to the ospfe. This is what bgpd is doing and allows to change the path
> > during runtime with a config reload.
>
> This makes sense to me. I'll come up with a new diff once I found some
> time for it.
>
> But I'm not sure about changing the socket path with a reload. I plan to
> pledge (stdio rpath sendfd wroute) and eventually unveil (read ospfd.conf)
> the main process.
New diff below creates the control socket in the main process and passes it
to the ospf engine later on. The connect check on the control socket now
happens very early.
The diff in action looks like this:
typhoon ..sbin/ospfd$ doas obj/ospfd -dv
startup
control_init: socket in use
fatal in ospfd: control socket setup failed
typhoon 1 ..sbin/ospfd$
I borrowed the fd passing code from slaacd.
>
> >
> > Could there be a case where this causes ospfd to hang on start in the
> > connect? Not sure if we can sleep doing a connect() to a AF_UNIX socket.
I never observed a hangin ospfctl which also does a connect on the control
socket. But I could not find the definitiv answer.
Remi
Index: control.c
===
RCS file: /cvs/src/usr.sbin/ospfd/control.c,v
retrieving revision 1.44
diff -u -p -r1.44 control.c
--- control.c 24 Jan 2017 04:24:25 - 1.44
+++ control.c 27 Aug 2018 21:17:42 -
@@ -42,19 +42,29 @@ int
control_init(char *path)
{
struct sockaddr_un sun;
- int fd;
+ int fd, fd_check;
mode_t old_umask;
+ bzero(, sizeof(sun));
+ sun.sun_family = AF_UNIX;
+ strlcpy(sun.sun_path, path, sizeof(sun.sun_path));
+
+ if ((fd_check = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) {
+ log_warn("control_init: socket check");
+ return (-1);
+ }
+ if (connect(fd_check, (struct sockaddr *), sizeof(sun)) == 0) {
+
Re: ENA support
Mike Belopuhov writes: > On Sat, 25 Aug 2018 at 20:03, Zbyszek Żółkiewski > wrote: >> >> Hi, >> >> just a question: anyone tried/consider porting ENA (Elastic Network > Adapter) support to OpenBSD ( > https://github.com/amzn/amzn-drivers/tree/master/kernel/fbsd/ena), how hard > would be to get it to obsd? >> >> _ >> Zbyszek Żółkiewski > > Hi, > > It would be nice to have a thoughtful port or a partial rewrite of > this vendor code dump. IIRC, dlg@ was toying with the idea. > > Cheers, > Mike BTW, a merged and trimmed down version available directly from the FreeBSD tree: https://svnweb.freebsd.org/base/head/sys/dev/ena/
Re: ENA support
> Wiadomość napisana przez Mike Belopuhov w dniu > 27.08.2018, o godz. 22:06: > > It would be nice to have a thoughtful port or a partial rewrite of > this vendor code dump. IIRC, dlg@ was toying with the idea. I just realized that (i think) it would require not only driver port but whole nitro support, that make it non-trivial... _ Zbyszek Żółkiewski
Re: ENA support
On Sat, 25 Aug 2018 at 20:03, Zbyszek Żółkiewski wrote: > > Hi, > > just a question: anyone tried/consider porting ENA (Elastic Network Adapter) support to OpenBSD ( https://github.com/amzn/amzn-drivers/tree/master/kernel/fbsd/ena), how hard would be to get it to obsd? > > _ > Zbyszek Żółkiewski Hi, It would be nice to have a thoughtful port or a partial rewrite of this vendor code dump. IIRC, dlg@ was toying with the idea. Cheers, Mike
fix ssh build with DEBUG_PK enabled
Hi,
While looking at a misplaced parenthesis I tried to compile ssh with DEBUG_PK
enabled, but it's currently broken.
Comments? OK?
Index: auth2-hostbased.c
===
RCS file: /cvs/src/usr.bin/ssh/auth2-hostbased.c,v
retrieving revision 1.36
diff -u -p -u -r1.36 auth2-hostbased.c
--- auth2-hostbased.c 31 Jul 2018 03:10:27 - 1.36
+++ auth2-hostbased.c 27 Aug 2018 18:42:27 -
@@ -78,7 +78,7 @@ userauth_hostbased(struct ssh *ssh)
cuser, chost, pkalg, slen);
#ifdef DEBUG_PK
debug("signature:");
- sshbuf_dump_data(sig, siglen, stderr);
+ sshbuf_dump_data(sig, slen, stderr);
#endif
pktype = sshkey_type_from_name(pkalg);
if (pktype == KEY_UNSPEC) {
Re: bgpd, streamline aspath matching
On Mon, Aug 27, 2018 at 12:11:43PM +0200, Claudio Jeker wrote:
> This is in preparation for introducing as-sets (a fast lookup table for
> when you want to make sure that your peering partner is realy only passing
> you traffic he should).
>
> To make as-set possible lets do some cleanup beforehands. This mainly
> removes one element from the filter_as struct, uses as_min for unary
> operations and changes the way we pass the and check the neighbor-as.
> as_compare() and aspath_match() now take the neighbor-as as last argument
> and will match against it if AS_FLAG_NEIGHBORAS is set. Simplifies the
> rde_filter_match() a fair bit.
>
And here is the bgpctl diff needed for this change.
--
:wq Claudio
Index: bgpctl.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.210
diff -u -p -r1.210 bgpctl.c
--- bgpctl.c29 Jul 2018 13:02:01 - 1.210
+++ bgpctl.c27 Aug 2018 12:02:44 -
@@ -159,7 +159,7 @@ main(int argc, char *argv[])
case IRRFILTER:
if (!(res->flags & (F_IPV4|F_IPV6)))
res->flags |= (F_IPV4|F_IPV6);
- irr_main(res->as.as, res->flags, res->irr_outdir);
+ irr_main(res->as.as_min, res->flags, res->irr_outdir);
break;
case SHOW_MRT:
if (pledge("stdio", NULL) == -1)
@@ -2056,7 +2056,7 @@ show_mrt_dump(struct mrt_rib *mr, struct
/* filter by AS */
if (req->as.type != AS_NONE &&
!aspath_match(mre->aspath, mre->aspath_len,
- >as, req->as.as))
+ >as, 0))
continue;
if (req->flags & F_CTL_DETAIL) {
@@ -2122,7 +2122,7 @@ network_mrt_dump(struct mrt_rib *mr, str
/* filter by AS */
if (req->as.type != AS_NONE &&
!aspath_match(mre->aspath, mre->aspath_len,
- >as, req->as.as))
+ >as, 0))
continue;
bzero(, sizeof(net));
Index: parser.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/parser.c,v
retrieving revision 1.82
diff -u -p -r1.82 parser.c
--- parser.c10 Jul 2018 13:03:06 - 1.82
+++ parser.c27 Aug 2018 12:01:46 -
@@ -614,7 +614,7 @@ match_token(int *argc, char **argv[], co
}
break;
case ASNUM:
- if (parse_asnum(word, wordlen, )) {
+ if (parse_asnum(word, wordlen, _min)) {
match++;
t = [i];
}
bgpd, streamline aspath matching
This is in preparation for introducing as-sets (a fast lookup table for
when you want to make sure that your peering partner is realy only passing
you traffic he should).
To make as-set possible lets do some cleanup beforehands. This mainly
removes one element from the filter_as struct, uses as_min for unary
operations and changes the way we pass the and check the neighbor-as.
as_compare() and aspath_match() now take the neighbor-as as last argument
and will match against it if AS_FLAG_NEIGHBORAS is set. Simplifies the
rde_filter_match() a fair bit.
OK?
--
:wq Claudio
? obj
Index: bgpd.h
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
retrieving revision 1.330
diff -u -p -r1.330 bgpd.h
--- bgpd.h 9 Aug 2018 21:12:33 - 1.330
+++ bgpd.h 27 Aug 2018 10:03:55 -
@@ -647,7 +647,6 @@ enum aslen_spec {
};
struct filter_as {
- u_int32_t as;
u_int16_t flags;
enum as_spectype;
u_int8_top;
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/bgpd/parse.y,v
retrieving revision 1.330
diff -u -p -r1.330 parse.y
--- parse.y 27 Aug 2018 09:49:00 - 1.330
+++ parse.y 27 Aug 2018 10:03:56 -
@@ -1902,7 +1902,7 @@ filter_as : as4number_any {
if (($$ = calloc(1, sizeof(struct filter_as_l))) ==
NULL)
fatal(NULL);
- $$->a.as = $1;
+ $$->a.as_min = $1;
$$->a.op = OP_EQ;
}
| NEIGHBORAS{
@@ -1916,7 +1916,7 @@ filter_as : as4number_any {
NULL)
fatal(NULL);
$$->a.op = $1;
- $$->a.as = $2;
+ $$->a.as_min = $2;
}
| as4number_any binaryop as4number_any {
if (($$ = calloc(1, sizeof(struct filter_as_l))) ==
Index: printconf.c
===
RCS file: /cvs/src/usr.sbin/bgpd/printconf.c,v
retrieving revision 1.109
diff -u -p -r1.109 printconf.c
--- printconf.c 11 Jul 2018 14:08:46 - 1.109
+++ printconf.c 27 Aug 2018 10:03:56 -
@@ -619,10 +619,10 @@ void print_as(struct filter_rule *r)
printf("%s ", log_as(r->match.as.as_max));
break;
case OP_NE:
- printf("!= %s ", log_as(r->match.as.as));
+ printf("!= %s ", log_as(r->match.as.as_min));
break;
default:
- printf("%s ", log_as(r->match.as.as));
+ printf("%s ", log_as(r->match.as.as_min));
break;
}
}
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.414
diff -u -p -r1.414 rde.c
--- rde.c 9 Aug 2018 12:54:06 - 1.414
+++ rde.c 27 Aug 2018 10:03:57 -
@@ -2149,7 +2149,7 @@ rde_dump_filter(struct prefix *p, struct
return;
if (req->type == IMSG_CTL_SHOW_RIB_AS &&
!aspath_match(asp->aspath->data, asp->aspath->len,
- >as, req->as.as))
+ >as, 0))
return;
if (req->type == IMSG_CTL_SHOW_RIB_COMMUNITY &&
!community_match(asp, req->community.as,
@@ -3769,5 +3769,4 @@ rde_mark_prefixsets_dirty(struct prefixs
}
}
}
- return;
}
Index: rde_filter.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_filter.c,v
retrieving revision 1.99
diff -u -p -r1.99 rde_filter.c
--- rde_filter.c3 Aug 2018 16:31:22 - 1.99
+++ rde_filter.c27 Aug 2018 10:03:57 -
@@ -340,7 +340,6 @@ int
rde_filter_match(struct filter_rule *f, struct rde_peer *peer,
struct filterstate *state, struct prefix *p)
{
- u_int32_t pas;
int cas, type;
int64_t las, ld1, ld2;
struct prefixset_item *psi;
@@ -349,20 +348,16 @@ rde_filter_match(struct filter_rule *f,
if (state != NULL)
asp = >aspath;
- if (asp != NULL && f->match.as.type != AS_NONE) {
- if (f->match.as.flags & AS_FLAG_NEIGHBORAS)
- pas = peer->conf.remote_as;
- else
- pas = f->match.as.as;
- if (aspath_match(asp->aspath->data, asp->aspath->len,
- >match.as, pas) == 0)
- return (0);
- }
-
if (f->peer.ebgp && !peer->conf.ebgp)
return (0);
if (f->peer.ibgp && peer->conf.ebgp)
return (0);
+
+ if
add set time-of-day clock code for OPL based sparc64 machines
i have an m4000 that would come up saying that it was 2023, which is
hard for ntpd to deal with. the rtc in these machines is based on a
value the firmware manages, but we never tell the firmware what we think
the time is.
this diff moves all the opl firwmare handling into the prtc driver, and
adds the todr_settime side of things so the time is kept across reboots.
there's a bunch of dicking around with %sys_tick we could do, but i
can't see what the advantage would be.
ok?
Index: dev/prtc.c
===
RCS file: /cvs/src/sys/arch/sparc64/dev/prtc.c,v
retrieving revision 1.3
diff -u -p -r1.3 prtc.c
--- dev/prtc.c 10 May 2014 12:36:22 - 1.3
+++ dev/prtc.c 27 Aug 2018 07:26:44 -
@@ -49,6 +49,9 @@ struct cfdriver prtc_cd = {
intprtc_gettime(todr_chip_handle_t, struct timeval *);
intprtc_settime(todr_chip_handle_t, struct timeval *);
+intprtc_opl_gettime(todr_chip_handle_t, struct timeval *);
+intprtc_opl_settime(todr_chip_handle_t, struct timeval *);
+
int
prtc_match(struct device *parent, void *match, void *aux)
{
@@ -64,6 +67,14 @@ void
prtc_attach(struct device *parent, struct device *self, void *aux)
{
todr_chip_handle_t handle;
+ char buf[32];
+ int opl;
+
+ opl = OF_getprop(findroot(), "name", buf, sizeof(buf)) > 0 &&
+ strcmp(buf, "SUNW,SPARC-Enterprise") == 0;
+
+ if (opl)
+ printf(": OPL");
printf("\n");
@@ -72,26 +83,25 @@ prtc_attach(struct device *parent, struc
panic("couldn't allocate todr_handle");
handle->cookie = self;
- handle->todr_gettime = prtc_gettime;
- handle->todr_settime = prtc_settime;
+ if (opl) {
+ handle->todr_gettime = prtc_opl_gettime;
+ handle->todr_settime = prtc_opl_settime;
+ } else {
+ handle->todr_gettime = prtc_gettime;
+ handle->todr_settime = prtc_settime;
+ }
handle->bus_cookie = NULL;
handle->todr_setwen = NULL;
+
todr_handle = handle;
}
int
prtc_gettime(todr_chip_handle_t handle, struct timeval *tv)
{
- u_int32_t tod = 0;
char buf[32];
-
- if (OF_getprop(findroot(), "name", buf, sizeof(buf)) > 0 &&
- strcmp(buf, "SUNW,SPARC-Enterprise") == 0) {
- tv->tv_sec = prom_opl_get_tod();
- tv->tv_usec = 0;
- return (0);
- }
+ u_int32_t tod = 0;
snprintf(buf, sizeof(buf), "h# %08lx unix-gettod", (long));
OF_interpret(buf, 0);
@@ -105,4 +115,56 @@ int
prtc_settime(todr_chip_handle_t handle, struct timeval *tv)
{
return (0);
-}
+}
+
+int
+prtc_opl_gettime(todr_chip_handle_t handle, struct timeval *tv)
+{
+ struct {
+ cell_t name;
+ cell_t nargs;
+ cell_t nrets;
+ cell_t stick;
+ cell_t time;
+ } args = {
+ .name = ADR2CELL("FJSV,get-tod"),
+ .nargs = 0,
+ .nrets = 2,
+ };
+
+ if (openfirmware() == -1)
+ return (-1);
+
+ tv->tv_sec = args.time;
+ tv->tv_usec = 0;
+
+ return (0);
+}
+
+int
+prtc_opl_settime(todr_chip_handle_t handle, struct timeval *tv)
+{
+ struct timeval otv;
+ struct {
+ cell_t name;
+ cell_t nargs;
+ cell_t nrets;
+ cell_t diff;
+ } args = {
+ .name = ADR2CELL("FJSV,set-domain-time"),
+ .nargs = 1,
+ .nrets = 0,
+ };
+
+ if (prtc_opl_gettime(handle, ) == -1)
+ return (-1);
+
+ args.diff = tv->tv_sec - otv.tv_sec;
+ if (args.diff == 0)
+ return (-1);
+
+ if (openfirmware() == -1)
+ return (-1);
+
+ return (0);
+}
Index: sparc64/ofw_machdep.c
===
RCS file: /cvs/src/sys/arch/sparc64/sparc64/ofw_machdep.c,v
retrieving revision 1.33
diff -u -p -r1.33 ofw_machdep.c
--- sparc64/ofw_machdep.c 7 Mar 2016 13:21:51 - 1.33
+++ sparc64/ofw_machdep.c 27 Aug 2018 07:26:44 -
@@ -748,27 +748,6 @@ prom_serengeti_set_console_input(const c
return (const char *)args.old;
}
-time_t
-prom_opl_get_tod(void)
-{
- static struct {
- cell_t name;
- cell_t nargs;
- cell_t nreturns;
- cell_t stick;
- cell_t time;
- } args;
-
- args.name = ADR2CELL("FJSV,get-tod");
- args.nargs = 0;
- args.nreturns = 2;
-
- if (openfirmware() == -1)
- return (time_t)-1;
-
- return (time_t)args.time;
-}
-
uint64_t
prom_set_sun4v_api_version(uint64_t api_group, uint64_t major,
uint64_t minor, uint64_t *supported_minor)
Re: libtool: handle fork() error
On Sun, Aug 26, 2018 at 04:13:11PM +0200, Christian Weisgerber wrote:
> I noticed this curious error in a package bulk build:
> Use of uninitialized value $pid in numeric eq (==) at
> /usr/libdata/perl5/LT/Exec.pm line 96.
>
> Perl's fork() wrapper returns undef rather than -1 on error.
> Handle this correctly. OK?
>
> Index: LT/Exec.pm
> ===
> RCS file: /cvs/src/usr.bin/libtool/LT/Exec.pm,v
> retrieving revision 1.4
> diff -u -p -r1.4 Exec.pm
> --- LT/Exec.pm11 Jul 2012 12:54:07 - 1.4
> +++ LT/Exec.pm26 Aug 2018 14:00:15 -
> @@ -93,7 +93,7 @@ sub command_run
> }
> tsay { "@l" };
> my $pid = fork();
> - if ($pid == -1) {
> + if (!defined $pid) {
> die "Couldn't fork while running @l\n";
> }
> if ($pid == 0) {
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
Okay, I actually had this in one of my trees, but forgot to commit it. :)
