Re: timekeep: tk_generation problem
> Date: Tue, 14 Jul 2020 20:17:30 -0500
> From: Scott Cheloha
> Cc: Mark Kettenis , tech@openbsd.org, p...@irofti.net
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Tue, Jul 14, 2020 at 08:21:24PM -0400, George Koehler wrote:
> > On Tue, 14 Jul 2020 11:59:14 +0200 (CEST)
> > Mark Kettenis wrote:
> >
> > > Yeah, one possible approach would be to increment ogen by two. A
> > > little bit easier to check that they can never be the same since one
> > > is always odd and the other is always even.
> > >
> > > Another possible approach would be to export both timehands. This
> > > could help avoiding some of the looping int the bin*time() functions
> > > in libc. Not sure that's worth it. And we should probably go for the
> > > "quick" fix initially regardless.
> >
> > I suspect that the bin*time() functions almost never loop back.
>
> I agree.
>
> I'm actually thinking about reducing the kernel timehands count to 1.
> We dropped from 10 to 2 about a year ago because having 10 seemed
> superfluous. There were no issues associated with that change as far
> as we know.
>
> Now I'm unsure if we even need 2 timehands. I'll need to measure it.
>
> > Here's a quick fix: read ogen from the other struct timehands, so
> > there is only one sequence of generation values, giving odds to th0
> > and evens to th1 (until the generation overflows and skips zero, then
> > it would give evens to th0 and odds to th1).
> >
> > I like this better than my first diff. OK?
>
> This also works, but like I said for your earlier diff it feels
> clever. The solution requires a non-trivial amount of thought to
> understand that it works correctly and why.
>
> The existing update protocol and th_generation code has worked for 15
> years. Excepting the recent addition of memory barriers it has worked
> fine.
>
> I'd like to keep the working code and adapt the new timekeep code to
> work with the existing code instead of changing the working code to
> support the new timekeep code. To me, it seems backwards to
> complicate simple, extant code if we don't need to.
>
> To do this I propose the attached diff. It decouples tk_generation
> from th_generation. tk_generation need not depend upon th_generation.
> That the other tk_* values come from the timehands is incidental to
> the correct operation of the lockless read protocol.
>
> I'll defer to kettenis@ though. Maybe I'm making a fuss over nothing.
>
> Thanks again for figuring this out.
I think George's change is fine and simpler.
> Index: kern_tc.c
> ===
> RCS file: /cvs/src/sys/kern/kern_tc.c,v
> retrieving revision 1.62
> diff -u -p -r1.62 kern_tc.c
> --- kern_tc.c 6 Jul 2020 13:33:09 - 1.62
> +++ kern_tc.c 14 Jul 2020 23:42:06 -
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -532,11 +533,13 @@ tc_update_timekeep(void)
> {
> static struct timecounter *last_tc = NULL;
> struct timehands *th;
> + u_int ogen;
>
> if (timekeep == NULL)
> return;
>
> th = timehands;
> + ogen = timekeep->tk_generation;
> timekeep->tk_generation = 0;
> membar_producer();
> timekeep->tk_scale = th->th_scale;
> @@ -550,7 +553,7 @@ tc_update_timekeep(void)
> last_tc = th->th_counter;
> }
> membar_producer();
> - timekeep->tk_generation = th->th_generation;
> + timekeep->tk_generation = (ogen == UINT_MAX) ? 1 : ogen + 1;
>
> return;
> }
>
Re: timekeep: tk_generation problem
> Date: Tue, 14 Jul 2020 20:21:24 -0400 > From: George Koehler > > On Tue, 14 Jul 2020 11:59:14 +0200 (CEST) > Mark Kettenis wrote: > > > Yeah, one possible approach would be to increment ogen by two. A > > little bit easier to check that they can never be the same since one > > is always odd and the other is always even. > > > > Another possible approach would be to export both timehands. This > > could help avoiding some of the looping int the bin*time() functions > > in libc. Not sure that's worth it. And we should probably go for the > > "quick" fix initially regardless. > > I suspect that the bin*time() functions almost never loop back. > > Here's a quick fix: read ogen from the other struct timehands, so > there is only one sequence of generation values, giving odds to th0 > and evens to th1 (until the generation overflows and skips zero, then > it would give evens to th0 and odds to th1). > > I like this better than my first diff. OK? ok kettenis@ > Index: kern/kern_tc.c > === > RCS file: /cvs/src/sys/kern/kern_tc.c,v > retrieving revision 1.62 > diff -u -p -r1.62 kern_tc.c > --- kern/kern_tc.c6 Jul 2020 13:33:09 - 1.62 > +++ kern/kern_tc.c14 Jul 2020 21:58:57 - > @@ -583,8 +583,8 @@ tc_windup(struct bintime *new_boottime, >* the contents, the generation must be zero. >*/ > tho = timehands; > + ogen = tho->th_generation; > th = tho->th_next; > - ogen = th->th_generation; > th->th_generation = 0; > membar_producer(); > memcpy(th, tho, offsetof(struct timehands, th_generation)); >
Re: tmpfs bug in reclaim
In the spirit of be careful what sticks to you, this has ok beck@ On Mon, Jul 13, 2020 at 11:56:18AM +0200, Gerhard Roth wrote: > tmpfs_reclaim() has to make sure that the VFS cache has no more > locks held for the vnode. Else vclean() could panic because v_holdcnt > is non-zero. > > I know that tmpfs is disabled by default, but it would be nice > to have this fix in the code base anyway. > > Gerhard > > > Index: sys/tmpfs/tmpfs_vnops.c > === > RCS file: /cvs/src/sys/tmpfs/tmpfs_vnops.c,v > retrieving revision 1.42 > diff -u -p -u -p -r1.42 tmpfs_vnops.c > --- sys/tmpfs/tmpfs_vnops.c 11 Jun 2020 09:18:43 - 1.42 > +++ sys/tmpfs/tmpfs_vnops.c 13 Jul 2020 09:48:37 - > @@ -1080,6 +1080,8 @@ tmpfs_reclaim(void *v) > racing = TMPFS_NODE_RECLAIMING(node); > rw_exit_write(&node->tn_nlock); > > + cache_purge(vp); > + > /* >* If inode is not referenced, i.e. no links, then destroy it. >* Note: if racing - inode is about to get a new vnode, leave it. >
[Patch] httpd.h - delete unused field and enum
Field kv_type in struct kv is not used. As that's the only use of
enum key_type, delete them both.
Ross
Index: httpd.h
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
retrieving revision 1.146
diff -u -p -r1.146 httpd.h
--- httpd.h 9 Feb 2020 09:44:04 - 1.146
+++ httpd.h 15 Jul 2020 04:45:16 -
@@ -121,24 +121,12 @@ struct ctl_flags {
uint8_t cf_tls_sid[TLS_MAX_SESSION_ID_LENGTH];
};
-enum key_type {
- KEY_TYPE_NONE = 0,
- KEY_TYPE_COOKIE,
- KEY_TYPE_HEADER,
- KEY_TYPE_PATH,
- KEY_TYPE_QUERY,
- KEY_TYPE_URL,
- KEY_TYPE_MAX
-};
-
TAILQ_HEAD(kvlist, kv);
RB_HEAD(kvtree, kv);
struct kv {
char*kv_key;
char*kv_value;
-
- enum key_typekv_type;
#define KV_FLAG_INVALID 0x01
#define KV_FLAG_GLOBBING0x02
Re: timekeep: tk_generation problem
On Tue, Jul 14, 2020 at 08:21:24PM -0400, George Koehler wrote:
> On Tue, 14 Jul 2020 11:59:14 +0200 (CEST)
> Mark Kettenis wrote:
>
> > Yeah, one possible approach would be to increment ogen by two. A
> > little bit easier to check that they can never be the same since one
> > is always odd and the other is always even.
> >
> > Another possible approach would be to export both timehands. This
> > could help avoiding some of the looping int the bin*time() functions
> > in libc. Not sure that's worth it. And we should probably go for the
> > "quick" fix initially regardless.
>
> I suspect that the bin*time() functions almost never loop back.
I agree.
I'm actually thinking about reducing the kernel timehands count to 1.
We dropped from 10 to 2 about a year ago because having 10 seemed
superfluous. There were no issues associated with that change as far
as we know.
Now I'm unsure if we even need 2 timehands. I'll need to measure it.
> Here's a quick fix: read ogen from the other struct timehands, so
> there is only one sequence of generation values, giving odds to th0
> and evens to th1 (until the generation overflows and skips zero, then
> it would give evens to th0 and odds to th1).
>
> I like this better than my first diff. OK?
This also works, but like I said for your earlier diff it feels
clever. The solution requires a non-trivial amount of thought to
understand that it works correctly and why.
The existing update protocol and th_generation code has worked for 15
years. Excepting the recent addition of memory barriers it has worked
fine.
I'd like to keep the working code and adapt the new timekeep code to
work with the existing code instead of changing the working code to
support the new timekeep code. To me, it seems backwards to
complicate simple, extant code if we don't need to.
To do this I propose the attached diff. It decouples tk_generation
from th_generation. tk_generation need not depend upon th_generation.
That the other tk_* values come from the timehands is incidental to
the correct operation of the lockless read protocol.
I'll defer to kettenis@ though. Maybe I'm making a fuss over nothing.
Thanks again for figuring this out.
Index: kern_tc.c
===
RCS file: /cvs/src/sys/kern/kern_tc.c,v
retrieving revision 1.62
diff -u -p -r1.62 kern_tc.c
--- kern_tc.c 6 Jul 2020 13:33:09 - 1.62
+++ kern_tc.c 14 Jul 2020 23:42:06 -
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -532,11 +533,13 @@ tc_update_timekeep(void)
{
static struct timecounter *last_tc = NULL;
struct timehands *th;
+ u_int ogen;
if (timekeep == NULL)
return;
th = timehands;
+ ogen = timekeep->tk_generation;
timekeep->tk_generation = 0;
membar_producer();
timekeep->tk_scale = th->th_scale;
@@ -550,7 +553,7 @@ tc_update_timekeep(void)
last_tc = th->th_counter;
}
membar_producer();
- timekeep->tk_generation = th->th_generation;
+ timekeep->tk_generation = (ogen == UINT_MAX) ? 1 : ogen + 1;
return;
}
Re: timekeep: tk_generation problem
On Tue, 14 Jul 2020 11:59:14 +0200 (CEST) Mark Kettenis wrote: > Yeah, one possible approach would be to increment ogen by two. A > little bit easier to check that they can never be the same since one > is always odd and the other is always even. > > Another possible approach would be to export both timehands. This > could help avoiding some of the looping int the bin*time() functions > in libc. Not sure that's worth it. And we should probably go for the > "quick" fix initially regardless. I suspect that the bin*time() functions almost never loop back. Here's a quick fix: read ogen from the other struct timehands, so there is only one sequence of generation values, giving odds to th0 and evens to th1 (until the generation overflows and skips zero, then it would give evens to th0 and odds to th1). I like this better than my first diff. OK? Index: kern/kern_tc.c === RCS file: /cvs/src/sys/kern/kern_tc.c,v retrieving revision 1.62 diff -u -p -r1.62 kern_tc.c --- kern/kern_tc.c 6 Jul 2020 13:33:09 - 1.62 +++ kern/kern_tc.c 14 Jul 2020 21:58:57 - @@ -583,8 +583,8 @@ tc_windup(struct bintime *new_boottime, * the contents, the generation must be zero. */ tho = timehands; + ogen = tho->th_generation; th = tho->th_next; - ogen = th->th_generation; th->th_generation = 0; membar_producer(); memcpy(th, tho, offsetof(struct timehands, th_generation));
Re: timekeep: tk_generation problem
On Tue, Jul 14, 2020 at 11:59:14AM +0200, Mark Kettenis wrote:
> > Date: Mon, 13 Jul 2020 17:07:31 -0400
> > From: George Koehler
> >
> > On Mon, 13 Jul 2020 01:18:14 -0500
> > Scott Cheloha wrote:
> >
> > > To review, the update protocol is:
> > >
> > > 1. Set tk_generation to zero; the update has begun.
> > >
> > > 2. Memory barrier. The side effects of step (1) are "visible" to
> > >other CPUs before those of step (3).
> > >
> > > 3. Update the other tk_* members from the active timehands.
> > >
> > > 4. Memory barrier. The side effects of step (3) are "visible" before
> > >those of step (5).
> > >
> > > 5. Set tk_generation to th_generation; the update is over. The
> > >timekeep page is consistent once more.
> > >
> > > --
> > >
> > > As far as I can tell, tk_generation always changes after an update,
> > > during step (5).
> >
> > There are 2 values, th0.th_generation and th1.th_generation. When the
> > kernel updates tk_generation, it switches between these 2 values, but
> > the values might be equal.
> >
> > >From /sys/kern/kern_tc.c tc_windup():
> >
> > tho = timehands;
> > th = tho->th_next;
> > ogen = th->th_generation;
> > th->th_generation = 0;
> > membar_producer();
> > ... /* update th */
> > if (++ogen == 0)
> > ogen = 1;
> > membar_producer();
> > th->th_generation = ogen;
> >
> > timehands is a circular list, where th0->th_next == th1 and
> > th1->th_next == th0. Now suppose that we call tc_windup() with,
> >
> > timehands == th0
> > th0.th_generation == 2177
> > th1.th_generation == 2176
> >
> > We assign tho = th0, th = th1, and ogen = 2176. After we update the
> > clock, we increment ogen and set th1.th_generation = 2177. When we
> > update the user timekeep page, we change tk_generation from 2177, the
> > old th0.th_generation, to 2177, the new th1.th_generation; but libc
> > sees the same value 2177 and can't detect the update.
> >
> > We update the clock 100 times per second (in a 100 Hz kernel), but
> > were incrementing tk_generation only 50 times per second.
> >
> > I run the diff from my first mail (copied below). It moves apart the
> > initial values of th_generation, so they don't become equal:
> >
> > th0.th_generation = UINT_MAX / 2/* changed from 1 */
> > th1.th_generation = 0 /* not changed */
> >
> > It might be better to change how tc_windup() sets ogen.--George
Thanks for the detailed explanation!
> Yeah, one possible approach would be to increment ogen by two. A
> little bit easier to check that they can never be the same since one
> is always odd and the other is always even.
>
> Another possible approach would be to export both timehands. This
> could help avoiding some of the looping int the bin*time() functions
> in libc. Not sure that's worth it.
I don't think it's worth it.
> And we should probably go for the "quick" fix initially regardless.
Agreed.
George: your solution is correct and quick but I think it's too
clever. I can't fully justify why. Just a gut feeling. Might be
wrong.
My alternate fix is to treat the timekeep structure as a separate
timehands and track its generation number separate from those of the
kernel timehands. See the attached diff. Basically we just reuse the
ogen code from tc_windup(). tk_generation is divorced from
th_generation.
Running with it now... I cannot trigger koehler@'s regress.
All: would appreciate a sanity check that this also fixes the issue.
Can you trigger koehler@'s regress with this?
ok?
Index: kern_tc.c
===
RCS file: /cvs/src/sys/kern/kern_tc.c,v
retrieving revision 1.62
diff -u -p -r1.62 kern_tc.c
--- kern_tc.c 6 Jul 2020 13:33:09 - 1.62
+++ kern_tc.c 14 Jul 2020 23:42:06 -
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -532,11 +533,13 @@ tc_update_timekeep(void)
{
static struct timecounter *last_tc = NULL;
struct timehands *th;
+ u_int ogen;
if (timekeep == NULL)
return;
th = timehands;
+ ogen = timekeep->tk_generation;
timekeep->tk_generation = 0;
membar_producer();
timekeep->tk_scale = th->th_scale;
@@ -550,7 +553,7 @@ tc_update_timekeep(void)
last_tc = th->th_counter;
}
membar_producer();
- timekeep->tk_generation = th->th_generation;
+ timekeep->tk_generation = (ogen == UINT_MAX) ? 1 : ogen + 1;
return;
}
Proposal: integrate wsmoused into kernel
There are several user visible "warts" with wsmoused: Wsmoused conflicts with X's use of the mouse, you can't ctrl-alt-screen between X and text consoles and use the mouse in both of them. The cursor location is in character cells instead of pixels, so the cursor moves twice as fast vertically as horizontally, and you need to scale down the mouse to get a reasonable speed. Wsmoused makes an attempt to address this by setting MSMOUSEIO_SRES to WSMOUSE_RES_MIN, but that only does anything on PS/2 mice. There is also a really strange (not even monotonically increasing or directionally invariant!) coordinate scaling function in normalize_event(). Wsmoused is enabled with rcctl and configuration options are set with wsmoused_flags= in /etc/rc.local instead of wsconsctl / wsconsctl.conf. I propose: Wsdisplay would have a mouse device associated with it as keyboards are associated, with "just works" defaults and wsconsctl options. Console cursor work would be automatically supressed when X is active. Cursor position would be tracked in pixels. If no additional scaling is done in X, the cursor would move at the same speed across the graphics or text console screens. The possibility is also then open to draw a pixel addressed bitmap cursor on any of the rasops consoles, which is more user friendly than a text block cursor for both disambiguation from the typing cursor, and avoidance of the unknown block boundary jitter problem. This would also save a couple thousand lines of code, remove a "moving part" from the system, and allow additional improvements like drag selection into the scrollback to be implemented. This would lose the support wsmoused has for some ancient serial mouse protocols parsed in user space. I would argue that if those mice are actually important, they should get a kernel driver. However, I suspect that the intersection of wsmoused users with 25 year old mice is small enough to neglect. Sound ok to pursue?
Re: energy sensor
No harm in adding it.
Mark Kettenis wrote:
> The firmware on the POWER9 machines provides an energy sensor. This
> sensor measures the energy on/in/at the chip. I'm not sure what that
> actually means. But it is different from the energy content of a
> battery which is measured in Watthours.
>
> Should I add this? Or should I just skip these sensors?
>
> Index: sbin/sysctl/sysctl.c
> ===
> RCS file: /cvs/src/sbin/sysctl/sysctl.c,v
> retrieving revision 1.251
> diff -u -p -r1.251 sysctl.c
> --- sbin/sysctl/sysctl.c 29 May 2020 04:42:23 - 1.251
> +++ sbin/sysctl/sysctl.c 14 Jul 2020 17:30:43 -
> @@ -2759,6 +2759,9 @@ print_sensor(struct sensor *s)
> case SENSOR_VELOCITY:
> printf("%4.3f m/s", s->value / 100.0);
> break;
> + case SENSOR_ENERGY:
> + printf("%.2f J", s->value / 100.0);
> + break;
> default:
> printf("unknown");
> }
> Index: usr.bin/systat/sensors.c
> ===
> RCS file: /cvs/src/usr.bin/systat/sensors.c,v
> retrieving revision 1.31
> diff -u -p -r1.31 sensors.c
> --- usr.bin/systat/sensors.c 10 Dec 2018 13:35:54 - 1.31
> +++ usr.bin/systat/sensors.c 14 Jul 2020 17:30:43 -
> @@ -291,6 +291,9 @@ showsensor(struct sensinfo *s)
> case SENSOR_VELOCITY:
> tbprintf("%4.3f m/s", s->sn_value / 100.0);
> break;
> + case SENSOR_ENERGY:
> + tbprintf("%.2f J", s->sn_value / 100.0);
> + break;
> default:
> tbprintf("%10lld", s->sn_value);
> break;
> Index: sys/sys/sensors.h
> ===
> RCS file: /cvs/src/sys/sys/sensors.h,v
> retrieving revision 1.36
> diff -u -p -r1.36 sensors.h
> --- sys/sys/sensors.h 10 Dec 2018 13:35:54 - 1.36
> +++ sys/sys/sensors.h 14 Jul 2020 17:30:43 -
> @@ -53,6 +53,7 @@ enum sensor_type {
> SENSOR_PRESSURE,/* pressure (mPa) */
> SENSOR_ACCEL, /* acceleration (u m/s^2) */
> SENSOR_VELOCITY,/* velocity (u m/s) */
> + SENSOR_ENERGY, /* energy (uJ) */
> SENSOR_MAX_TYPES
> };
>
> @@ -80,6 +81,7 @@ static const char * const sensor_type_s[
> "pressure",
> "acceleration",
> "velocity",
> + "energy",
> "undefined"
> };
> #endif /* !_KERNEL */
>
energy sensor
The firmware on the POWER9 machines provides an energy sensor. This
sensor measures the energy on/in/at the chip. I'm not sure what that
actually means. But it is different from the energy content of a
battery which is measured in Watthours.
Should I add this? Or should I just skip these sensors?
Index: sbin/sysctl/sysctl.c
===
RCS file: /cvs/src/sbin/sysctl/sysctl.c,v
retrieving revision 1.251
diff -u -p -r1.251 sysctl.c
--- sbin/sysctl/sysctl.c29 May 2020 04:42:23 - 1.251
+++ sbin/sysctl/sysctl.c14 Jul 2020 17:30:43 -
@@ -2759,6 +2759,9 @@ print_sensor(struct sensor *s)
case SENSOR_VELOCITY:
printf("%4.3f m/s", s->value / 100.0);
break;
+ case SENSOR_ENERGY:
+ printf("%.2f J", s->value / 100.0);
+ break;
default:
printf("unknown");
}
Index: usr.bin/systat/sensors.c
===
RCS file: /cvs/src/usr.bin/systat/sensors.c,v
retrieving revision 1.31
diff -u -p -r1.31 sensors.c
--- usr.bin/systat/sensors.c10 Dec 2018 13:35:54 - 1.31
+++ usr.bin/systat/sensors.c14 Jul 2020 17:30:43 -
@@ -291,6 +291,9 @@ showsensor(struct sensinfo *s)
case SENSOR_VELOCITY:
tbprintf("%4.3f m/s", s->sn_value / 100.0);
break;
+ case SENSOR_ENERGY:
+ tbprintf("%.2f J", s->sn_value / 100.0);
+ break;
default:
tbprintf("%10lld", s->sn_value);
break;
Index: sys/sys/sensors.h
===
RCS file: /cvs/src/sys/sys/sensors.h,v
retrieving revision 1.36
diff -u -p -r1.36 sensors.h
--- sys/sys/sensors.h 10 Dec 2018 13:35:54 - 1.36
+++ sys/sys/sensors.h 14 Jul 2020 17:30:43 -
@@ -53,6 +53,7 @@ enum sensor_type {
SENSOR_PRESSURE,/* pressure (mPa) */
SENSOR_ACCEL, /* acceleration (u m/s^2) */
SENSOR_VELOCITY,/* velocity (u m/s) */
+ SENSOR_ENERGY, /* energy (uJ) */
SENSOR_MAX_TYPES
};
@@ -80,6 +81,7 @@ static const char * const sensor_type_s[
"pressure",
"acceleration",
"velocity",
+ "energy",
"undefined"
};
#endif /* !_KERNEL */
Re: empty rc.firsttime when installing
Denis Fondras wrote: > I was upgrading an EdgeRouter and it restarted multiple times instead of > booting > /bsd Try to produce a log of that problem, instead.
autoconf-2.69b released [beta]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
We are pleased to announce beta release 2.69b of GNU Autoconf.
This release includes eight years of development work since the
previous release, 2.69. See below for the detailed list of changes
since the previous version, as summarized by the NEWS file.
Because it has been such a long time, and because some of the changes
potentially break existing Autoconf scripts, we are conducting a
public beta test before the final release of version 2.70. Please
test this beta with your autoconf scripts, and report any problems you
find to the Savannah bug tracker:
https://savannah.gnu.org/support/?func=additem&group=autoconf
Please also send general comments and feedback to .
Please also spread this announcement widely, so that as many Autoconf
users as possible hear about it.
The final release of Autoconf 2.70 is tentatively scheduled for three
months from now. We may make more beta releases during this period.
Here are the compressed sources:
https://alpha.gnu.org/gnu/autoconf/autoconf-2.69b.tar.gz (1.9MB)
https://alpha.gnu.org/gnu/autoconf/autoconf-2.69b.tar.xz (1.3MB)
Here are the GPG detached signatures[*]:
https://alpha.gnu.org/gnu/autoconf/autoconf-2.69b.tar.gz.sig
https://alpha.gnu.org/gnu/autoconf/autoconf-2.69b.tar.xz.sig
Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html
[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:
gpg --verify autoconf-2.69b.tar.gz.sig
If that command fails because you don't have the required public key,
then run this command to import it:
gpg --keyserver keys.gnupg.net --recv-keys ED97E90E62AA7E34
and rerun the 'gpg --verify' command.
This release was bootstrapped with the following tools:
Automake 1.15.1
NEWS
* Noteworthy changes in release 2.69b (2020-07-13) [beta]
** config.log properly escapes arguments in the header comment;
config.status --config output is now quoted in a more readable fashion
** Configure scripts now support a '--runstatedir' option, which
defaults to '${localstatedir}/run', and which can be used to place
per-process temporary runtime files (such as pid files) into '/run'
instead of '/var/run'.
** The use of the long-deprecated name 'configure.in' for the autoconf
input file now elicits a warning in the 'obsolete' category.
** Older version of automake and aclocal (< 1.8) are no longer supported
by autoreconf.
** Use of printf is now recommended instead of working around bugs in
echo. The macros AS_ECHO and AS_ECHO_N now expand unconditionally to
'printf "%s\n"' and 'printf %s'.
** Use of the undocumented internal shell variables $as_echo and
$as_echo_n now elicits a warning in the 'obsolete' category.
The macros AS_ECHO and AS_ECHO_N should be used instead.
** When checking for missing templates, autoheader now takes any
templates defined in the inputs of secondary config headers into
account. This makes it possible to use AC_DEFINE for secondary
headers without duplicating the template in the main config header.
** Many macros have been improved to expand their arguments
once and only once. This makes âautoconfâ run faster. However, it
may break configure scripts that did not quote all macro arguments
properly. The âM4 Quotationâ section of the manual explains how to
quote macro arguments properly.
** Several macros that are commonly used early in a configure
script, such as AC_PROG_CC, have been optimized and no longer
invoke as many subroutine macros as they used to. This can expose
several classes of bugs: these are the ones we know about:
- Make sure to explicitly invoke all of the macros that set result
variables used later in the configure script, or in generated
Makefiles.
- Autoconf macros that use AC_REQUIRE internally, are not safe to
use inside of hand-written shell conditional or looping
constructs. Use AS_IF, AS_CASE, AS_FOR, etc. instead.
(See the âPrerequisite Macrosâ section of the manual for
further explanation.)
The set of macros that use AC_REQUIRE internally may change from
release to release. The only macros that are guaranteed *not* to
use AC_REQUIRE are the macros for acting on the results of a
test: AC_DEFINE, AC_SUBST, AC_MSG_*, AC_CACHE_CHECK, etc.
- AC_REQUIRE cannot be applied to macros that need to be used with
arguments. Instead, invoke the macro normally, with its arguments.
** Macros that take whitespace-separated lists as arguments
now always expand macros within those arguments. (Formerly, these
macros would *usually* expand those arguments, but the behavior was
not reliable nor was it consistent between autoconf and autoheader.)
Macro expansion within these arguments is deprecated;
Re: empty rc.firsttime when installing
On Tue, Jul 14, 2020 at 02:14:55PM +0100, Stuart Henderson wrote: > On 2020/07/14 15:03, Denis Fondras wrote: > > I was upgrading an EdgeRouter and it restarted multiple times instead of > > booting > > /bsd > > > > When I had a chance to boot it correctly, I noticed that sysmerge and > > fw_update > > were run multiple times. > > > > This diff avoids filling rc.firsttime and rc.sysmerge. > > hmm, that will cause problems for some things I do (the main one being: > sysupgrade -n, add a pkg_add -u line to rc.firsttime, reboot). > Thank you all for raising the problem.
Re: empty rc.firsttime when installing
On 2020/07/14 15:03, Denis Fondras wrote:
> I was upgrading an EdgeRouter and it restarted multiple times instead of
> booting
> /bsd
>
> When I had a chance to boot it correctly, I noticed that sysmerge and
> fw_update
> were run multiple times.
>
> This diff avoids filling rc.firsttime and rc.sysmerge.
hmm, that will cause problems for some things I do (the main one being:
sysupgrade -n, add a pkg_add -u line to rc.firsttime, reboot).
> Index: distrib/miniroot/install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.1154
> diff -u -p -r1.1154 install.sub
> --- distrib/miniroot/install.sub 26 May 2020 16:21:00 - 1.1154
> +++ distrib/miniroot/install.sub 14 Jul 2020 12:54:27 -
> @@ -2734,6 +2734,9 @@ finish_up() {
> local _kernel_dir=/mnt/usr/share/relink/kernel
> local _kernel=${MDKERNEL:-GENERIC} _syspatch_archs="amd64 arm64 i386"
>
> + # Empty rc.firsttime
> + echo "" >/mnt/etc/rc.firsttime
> +
> # Mount all known swap partitions. This gives systems with little
> # memory a better chance at running 'MAKEDEV all'.
> if [[ -x /mnt/sbin/swapctl ]]; then
> @@ -2812,7 +2815,7 @@ finish_up() {
>
> # Ensure that sysmerge in batch mode is run on reboot.
> [[ $MODE == upgrade ]] &&
> - echo "/usr/sbin/sysmerge -b" >>/mnt/etc/rc.sysmerge
> + echo "/usr/sbin/sysmerge -b" >/mnt/etc/rc.sysmerge
>
> # If a proxy was needed to fetch the sets, use it for fw_update and
> syspatch
> [[ -n $http_proxy ]] &&
>
Re: empty rc.firsttime when installing
Hmm. rc.firsttime could be populated in advance by configuration tools and what
now and in this case you will loose the changes, no?
—
Antoine
> On 14 Jul 2020, at 15:04, Denis Fondras wrote:
>
> I was upgrading an EdgeRouter and it restarted multiple times instead of
> booting
> /bsd
>
> When I had a chance to boot it correctly, I noticed that sysmerge and
> fw_update
> were run multiple times.
>
> This diff avoids filling rc.firsttime and rc.sysmerge.
>
>
> Index: distrib/miniroot/install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.1154
> diff -u -p -r1.1154 install.sub
> --- distrib/miniroot/install.sub26 May 2020 16:21:00 -1.1154
> +++ distrib/miniroot/install.sub14 Jul 2020 12:54:27 -
> @@ -2734,6 +2734,9 @@ finish_up() {
>local _kernel_dir=/mnt/usr/share/relink/kernel
>local _kernel=${MDKERNEL:-GENERIC} _syspatch_archs="amd64 arm64 i386"
>
> +# Empty rc.firsttime
> +echo "" >/mnt/etc/rc.firsttime
> +
># Mount all known swap partitions. This gives systems with little
># memory a better chance at running 'MAKEDEV all'.
>if [[ -x /mnt/sbin/swapctl ]]; then
> @@ -2812,7 +2815,7 @@ finish_up() {
>
># Ensure that sysmerge in batch mode is run on reboot.
>[[ $MODE == upgrade ]] &&
> -echo "/usr/sbin/sysmerge -b" >>/mnt/etc/rc.sysmerge
> +echo "/usr/sbin/sysmerge -b" >/mnt/etc/rc.sysmerge
>
># If a proxy was needed to fetch the sets, use it for fw_update and
> syspatch
>[[ -n $http_proxy ]] &&
>
Re: empty rc.firsttime when installing
On Tue, Jul 14, 2020 at 03:03:33PM +0200, Denis Fondras wrote:
> I was upgrading an EdgeRouter and it restarted multiple times instead of
> booting
> /bsd
>
> When I had a chance to boot it correctly, I noticed that sysmerge and
> fw_update
> were run multiple times.
>
> This diff avoids filling rc.firsttime and rc.sysmerge.
This interfers with sysupgrade(8) cleanup.
>
>
> Index: distrib/miniroot/install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.1154
> diff -u -p -r1.1154 install.sub
> --- distrib/miniroot/install.sub 26 May 2020 16:21:00 - 1.1154
> +++ distrib/miniroot/install.sub 14 Jul 2020 12:54:27 -
> @@ -2734,6 +2734,9 @@ finish_up() {
> local _kernel_dir=/mnt/usr/share/relink/kernel
> local _kernel=${MDKERNEL:-GENERIC} _syspatch_archs="amd64 arm64 i386"
>
> + # Empty rc.firsttime
> + echo "" >/mnt/etc/rc.firsttime
> +
> # Mount all known swap partitions. This gives systems with little
> # memory a better chance at running 'MAKEDEV all'.
> if [[ -x /mnt/sbin/swapctl ]]; then
> @@ -2812,7 +2815,7 @@ finish_up() {
>
> # Ensure that sysmerge in batch mode is run on reboot.
> [[ $MODE == upgrade ]] &&
> - echo "/usr/sbin/sysmerge -b" >>/mnt/etc/rc.sysmerge
> + echo "/usr/sbin/sysmerge -b" >/mnt/etc/rc.sysmerge
>
> # If a proxy was needed to fetch the sets, use it for fw_update and
> syspatch
> [[ -n $http_proxy ]] &&
>
--
I'm not entirely sure you are real.
empty rc.firsttime when installing
I was upgrading an EdgeRouter and it restarted multiple times instead of booting
/bsd
When I had a chance to boot it correctly, I noticed that sysmerge and fw_update
were run multiple times.
This diff avoids filling rc.firsttime and rc.sysmerge.
Index: distrib/miniroot/install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1154
diff -u -p -r1.1154 install.sub
--- distrib/miniroot/install.sub26 May 2020 16:21:00 - 1.1154
+++ distrib/miniroot/install.sub14 Jul 2020 12:54:27 -
@@ -2734,6 +2734,9 @@ finish_up() {
local _kernel_dir=/mnt/usr/share/relink/kernel
local _kernel=${MDKERNEL:-GENERIC} _syspatch_archs="amd64 arm64 i386"
+ # Empty rc.firsttime
+ echo "" >/mnt/etc/rc.firsttime
+
# Mount all known swap partitions. This gives systems with little
# memory a better chance at running 'MAKEDEV all'.
if [[ -x /mnt/sbin/swapctl ]]; then
@@ -2812,7 +2815,7 @@ finish_up() {
# Ensure that sysmerge in batch mode is run on reboot.
[[ $MODE == upgrade ]] &&
- echo "/usr/sbin/sysmerge -b" >>/mnt/etc/rc.sysmerge
+ echo "/usr/sbin/sysmerge -b" >/mnt/etc/rc.sysmerge
# If a proxy was needed to fetch the sets, use it for fw_update and
syspatch
[[ -n $http_proxy ]] &&
Re: [PATCH} Optimized rasops32 putchar
On Sun, Jul 12, 2020 at 07:16:13PM +0200, Frederic Cambus wrote: > On Fri, Jun 26, 2020 at 07:42:50AM -0700, jo...@armadilloaerospace.com wrote: > > Optimized 32 bit character rendering with unrolled rows and pairwise > > foreground / background pixel rendering. > > > > If it weren't for the 5x8 font, I would have just assumed everything > > was an even width and made the fallback path also pairwise. > > > > In isolation, the 16x32 character case got 2x faster, but that wasn't > > a huge real world speedup where the space rendering that was already > > at memory bandwidth limits accounted for most of the character > > rendering time. However, in combination with the previous fast > > conditional console scrolling that removes most of the space rendering, > > it becomes significant. > > On my Ryzen desktop with radeondrm, I don't see any improvements, the > rasops_vcons_copyrows() optimizations seems to have made character > plotting fast enough so that it's not a bottleneck anymore, which is > definitely great. > > cpu0: AMD Ryzen 7 2700 Eight-Core Processor, 3394.18 MHz, 17-08-02 > radeondrm0 at pci8 dev 0 function 0 "ATI Radeon HD 6450" rev 0x00 > radeondrm0: 1920x1080, 32bpp > > On my T450 however, this diff makes cat'ing my usual test file [1] up > to 20% faster with the default 12x24 font on the built-in 1600x900 > screen, which I think is significant enough for the diff to go in. > > cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.47 MHz, 06-3d-04 > inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 5500" rev 0x09 > drm0 at inteldrm0 > inteldrm0: 1600x900, 32bpp > > On my Cubieboard2 (armv7) I didn't notice any meaningful difference, > which I assume is to be expected on a 32-bit platform. I suppose it's > also reasonable to assume other 32-bit platforms (i386, hppa, macppc) > will not see any regression beyond noise level? > > Anyone willing to OK this diff? > > [1] https://norvig.com/big.txt So I tested on the other 32-bit machine I have, and didn't notice any regression on my i386 machine with inteldrm, it is actually up to 1.5% faster. It seems we can remove the 'q' variable and drop this assignement, as it is not used: q = u.q[0]; The diff makes sense to me, I will commit it this week with some minor style(9) fixes for the switch statement (don't indent the case), unless I hear objections.
Re: timekeep: tk_generation problem
> Date: Mon, 13 Jul 2020 17:07:31 -0400
> From: George Koehler
>
> On Mon, 13 Jul 2020 01:18:14 -0500
> Scott Cheloha wrote:
>
> > To review, the update protocol is:
> >
> > 1. Set tk_generation to zero; the update has begun.
> >
> > 2. Memory barrier. The side effects of step (1) are "visible" to
> >other CPUs before those of step (3).
> >
> > 3. Update the other tk_* members from the active timehands.
> >
> > 4. Memory barrier. The side effects of step (3) are "visible" before
> >those of step (5).
> >
> > 5. Set tk_generation to th_generation; the update is over. The
> >timekeep page is consistent once more.
> >
> > --
> >
> > As far as I can tell, tk_generation always changes after an update,
> > during step (5).
>
> There are 2 values, th0.th_generation and th1.th_generation. When the
> kernel updates tk_generation, it switches between these 2 values, but
> the values might be equal.
>
> >From /sys/kern/kern_tc.c tc_windup():
>
> tho = timehands;
> th = tho->th_next;
> ogen = th->th_generation;
> th->th_generation = 0;
> membar_producer();
> ... /* update th */
> if (++ogen == 0)
> ogen = 1;
> membar_producer();
> th->th_generation = ogen;
>
> timehands is a circular list, where th0->th_next == th1 and
> th1->th_next == th0. Now suppose that we call tc_windup() with,
>
> timehands == th0
> th0.th_generation == 2177
> th1.th_generation == 2176
>
> We assign tho = th0, th = th1, and ogen = 2176. After we update the
> clock, we increment ogen and set th1.th_generation = 2177. When we
> update the user timekeep page, we change tk_generation from 2177, the
> old th0.th_generation, to 2177, the new th1.th_generation; but libc
> sees the same value 2177 and can't detect the update.
>
> We update the clock 100 times per second (in a 100 Hz kernel), but
> were incrementing tk_generation only 50 times per second.
>
> I run the diff from my first mail (copied below). It moves apart the
> initial values of th_generation, so they don't become equal:
>
> th0.th_generation = UINT_MAX / 2/* changed from 1 */
> th1.th_generation = 0 /* not changed */
>
> It might be better to change how tc_windup() sets ogen.--George
Yeah, one possible approach would be to increment ogen by two. A
little bit easier to check that they can never be the same since one
is always odd and the other is always even.
Another possible approach would be to export both timehands. This
could help avoiding some of the looping int the bin*time() functions
in libc. Not sure that's worth it. And we should probably go for the
"quick" fix initially regardless.
> Index: kern/kern_tc.c
> ===
> RCS file: /cvs/src/sys/kern/kern_tc.c,v
> retrieving revision 1.62
> diff -u -p -r1.62 kern_tc.c
> --- kern/kern_tc.c6 Jul 2020 13:33:09 - 1.62
> +++ kern/kern_tc.c13 Jul 2020 02:59:58 -
> @@ -98,7 +98,8 @@ static struct timehands th0 = {
> .th_counter = &dummy_timecounter,
> .th_scale = UINT64_MAX / 100,
> .th_offset = { .sec = 1, .frac = 0 },
> - .th_generation = 1,
> + /* Keep apart generations of th0, th1, for user timekeep. */
> + .th_generation = UINT_MAX / 2,
> .th_next = &th1
> };
>
>
Re: disable libc sys wrappers?
On 13.07.2020 20:43, Ted Unangst wrote:
On 2020-07-09, Theo de Raadt wrote:
Added a -T option to ktrace for transparency. I got ambitious here and made
it take suboptions, anticipating that other transparency modifications may
be desired.
Please don't do that.
Here is a simpler version.
OK.
Index: lib/libc/dlfcn/init.c
===
RCS file: /home/cvs/src/lib/libc/dlfcn/init.c,v
retrieving revision 1.8
diff -u -p -r1.8 init.c
--- lib/libc/dlfcn/init.c 6 Jul 2020 13:33:05 - 1.8
+++ lib/libc/dlfcn/init.c 13 Jul 2020 17:36:04 -
@@ -114,6 +114,8 @@ _libc_preinit(int argc, char **argv, cha
_timekeep->tk_version != TK_VERSION)
_timekeep = NULL;
}
+ if (issetugid() == 0 && getenv("LIBC_NOUSERTC"))
+ _timekeep = NULL;
break;
}
}
Index: usr.bin/ktrace/ktrace.1
===
RCS file: /home/cvs/src/usr.bin/ktrace/ktrace.1,v
retrieving revision 1.30
diff -u -p -r1.30 ktrace.1
--- usr.bin/ktrace/ktrace.1 15 May 2019 15:36:59 - 1.30
+++ usr.bin/ktrace/ktrace.1 13 Jul 2020 17:38:22 -
@@ -37,13 +37,13 @@
.Nd enable kernel process tracing
.Sh SYNOPSIS
.Nm ktrace
-.Op Fl aBCcdi
+.Op Fl aCcdi
.Op Fl f Ar trfile
.Op Fl g Ar pgid
.Op Fl p Ar pid
.Op Fl t Ar trstr
.Nm ktrace
-.Op Fl adi
+.Op Fl aBdiT
.Op Fl f Ar trfile
.Op Fl t Ar trstr
.Ar command
@@ -109,6 +109,8 @@ processes.
Enable (disable) tracing on the indicated process ID (only one
.Fl p
flag is permitted).
+.It Fl T
+Disable userland timekeeping, making time related system calls more prevalent.
.It Fl t Ar trstr
Select which information to put into the dump file.
The argument can contain one or more of the following letters.
Index: usr.bin/ktrace/ktrace.c
===
RCS file: /home/cvs/src/usr.bin/ktrace/ktrace.c,v
retrieving revision 1.36
diff -u -p -r1.36 ktrace.c
--- usr.bin/ktrace/ktrace.c 28 Jun 2019 13:35:01 - 1.36
+++ usr.bin/ktrace/ktrace.c 13 Jul 2020 17:37:06 -
@@ -100,7 +100,7 @@ main(int argc, char *argv[])
usage();
}
} else {
- while ((ch = getopt(argc, argv, "aBCcdf:g:ip:t:")) != -1)
+ while ((ch = getopt(argc, argv, "aBCcdf:g:ip:t:T")) != -1)
switch ((char)ch) {
case 'a':
append = 1;
@@ -140,6 +140,9 @@ main(int argc, char *argv[])
usage();
}
break;
+ case 'T':
+ putenv("LIBC_NOUSERTC=");
+ break;
default:
usage();
}
@@ -240,9 +243,9 @@ usage(void)
" [-u trspec] command\n",
__progname);
else
- fprintf(stderr, "usage: %s [-aBCcdi] [-f trfile] [-g pgid]"
+ fprintf(stderr, "usage: %s [-aCcdi] [-f trfile] [-g pgid]"
" [-p pid] [-t trstr]\n"
- " %s [-adi] [-f trfile] [-t trstr] command\n",
+ " %s [-aBdiT] [-f trfile] [-t trstr] command\n",
__progname, __progname);
exit(1);
}
Re: pf: remove ptr_array from struct pf_ruleset
Hello Klemens, > `ptr_array' is allocated momentarily through mallocarray(9) and gets > filled with the TAILQ entries, the sole user pfsync(4) can then access > the list of rules by index to simply pick the n-th rule in a ruleset > during state insertion. > > I came here due to the zero size in its free(9) call, but the diff below > removes the array completely and makes pfsync iterate over the TAILQ to > get "index" of the matching rule in the ruleset. > > I've been successfully running this on amd64 firewalls with pfsync(4) > where I also added expiring `once' rules to further test with. > > Feedback? OK? > my only concern is performance impact. your diff trades O(1) for O(n) just to handle expiration of PFRULE_ONCE correctly. However the extra costs here might be bit reduced by fact, we do the look up just in case receive brand new state from peer. looking at the problem from different angle: if there would be no PFRULE_ONCE rules, the bug won't exist I vaguely remember the question of removing 'PFRULE_ONCE' rule is still unanswered. It seems to me the PFRULE_ONCE is supposed to be used by tftp-proxy only. However the code there is still protected by 'notyet' ifdef guard. if we would get your diff in, then IMHO the cost of keeping rarely used PFRULE_ONCE feature, will further increase. I just don't know if the new cost will still be acceptable, therefore I hesitate with my OK for your change, which seems to look good otherwise. thanks and regards sashan
mktestdata.sh make effective use of character classes
Hello,
This is my first diff I've submitted here, so I imagine there's a dozen
things I'm missing/clueless about.
I've been making an effort to start browsing the tree and reading the
code regularly. I came across this file, I know it's a regress test, so
there may be some context/history I'm ignorant to.
All I know is, is that it is cleaner to use '[:space:]' rather than '
\n' unless you are intentionally ignoring tabs and '\r' etc. I also know
that '[[:alpha:]] is a lot cleaner than [a-zA-Z] and could also avoid
potential issues with localization (I'm not an expert on that, just what
I was told).
I know OpenSSH portable runs on some wacky systems that may not support
character classes, but if this test is just for OpenBSD then all should
be well.
Index: regress/usr.bin/ssh/unittests/sshkey/mktestdata.sh
===
RCS file: /cvs/src/regress/usr.bin/ssh/unittests/sshkey/mktestdata.sh,v
retrieving revision 1.11
diff -u -p -u -r1.11 mktestdata.sh
--- regress/usr.bin/ssh/unittests/sshkey/mktestdata.sh 19 Jun 2020
03:48:49 - 1.11
+++ regress/usr.bin/ssh/unittests/sshkey/mktestdata.sh 14 Jul 2020
07:48:40 -
@@ -9,13 +9,13 @@ rsa_params() {
set -e
openssl rsa -noout -text -in $_in | \
awk '/^modulus:$/,/^publicExponent:/' | \
- grep -v '^[a-zA-Z]' | tr -d ' \n:' > ${_outbase}.n
+ grep -v '^[[:alpha:]]' | tr -d '[:space:]:' > ${_outbase}.n
openssl rsa -noout -text -in $_in | \
awk '/^prime1:$/,/^prime2:/' | \
- grep -v '^[a-zA-Z]' | tr -d ' \n:' > ${_outbase}.p
+ grep -v '^[[:alpha:]]' | tr -d '[:space:]:' > ${_outbase}.p
openssl rsa -noout -text -in $_in | \
awk '/^prime2:$/,/^exponent1:/' | \
- grep -v '^[a-zA-Z]' | tr -d ' \n:' > ${_outbase}.q
+ grep -v '^[[:alpha:]]' | tr -d '[:space:]:' > ${_outbase}.q
for x in n p q ; do
echo "" >> ${_outbase}.$x
echo ${_outbase}.$x
@@ -30,13 +30,13 @@ dsa_params() {
set -e
openssl dsa -noout -text -in $_in | \
awk '/^priv:$/,/^pub:/' | \
- grep -v '^[a-zA-Z]' | tr -d ' \n:' > ${_outbase}.priv
+ grep -v '^[[alpha:]]' | tr -d '[:space:]:' > ${_outbase}.priv
openssl dsa -noout -text -in $_in | \
awk '/^pub:/,/^P:/' | #\
- grep -v '^[a-zA-Z]' | tr -d ' \n:' > ${_outbase}.pub
+ grep -v '^[[:alpha:]]' | tr -d '[:space:]:' > ${_outbase}.pub
openssl dsa -noout -text -in $_in | \
awk '/^G:/,0' | \
- grep -v '^[a-zA-Z]' | tr -d ' \n:' > ${_outbase}.g
+ grep -v '^[[:alpha:]]' | tr -d '[:space:]:' > ${_outbase}.g
for x in priv pub g ; do
echo "" >> ${_outbase}.$x
echo ${_outbase}.$x
@@ -51,10 +51,10 @@ ecdsa_params() {
set -e
openssl ec -noout -text -in $_in | \
awk '/^priv:$/,/^pub:/' | \
- grep -v '^[a-zA-Z]' | tr -d ' \n:' > ${_outbase}.priv
+ grep -v '^[[:alpha:]]' | tr -d '[:space:]:' > ${_outbase}.priv
openssl ec -noout -text -in $_in | \
grep "ASN1 OID:" | \
sed 's/.*: //;s/ *$//' | tr -d '\n' > ${_outbase}.curve
