chilepeso in units(1)
An apparent typo was introduced in http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/units/units.lib.diff?r1=1.144=1.145=h Does nobody use units(1) on their Chilean vacation anymore? Jan Index: units.lib === RCS file: /cvs/src/usr.bin/units/units.lib,v retrieving revision 1.146 diff -u -p -r1.146 units.lib --- units.lib 18 Nov 2022 19:07:54 - 1.146 +++ units.lib 12 Apr 2023 10:33:22 - @@ -337,7 +337,7 @@ venezuelabolivar1|2500064.0890 $ / The Economist, April 28, 2021 / Hungary, Iceland, Ukraine, Vietnam: no updates available since October 2018 argentinapeso 1|93.4 $ -chilepeso 1|702 +chilepeso 1|702 $ colombiapeso 1|3707 $ czechkoruna1|21.4 $ egyptpound 1|15.7 $
Re: lidaction on an M1 macbook
> > aplsmc(4) provides support for the lid position sensor. Should that be mentioned in aplsmc(4)? Index: aplsmc.4 === RCS file: /cvs/src/share/man/man4/man4.arm64/aplsmc.4,v retrieving revision 1.2 diff -u -p -r1.2 aplsmc.4 --- aplsmc.410 Jan 2022 21:16:44 - 1.2 +++ aplsmc.411 Apr 2023 15:49:20 - @@ -28,7 +28,7 @@ The driver provides support for the System Management Controller (SMC) found on various Apple SoCs. The driver provides a collection of current, fan, power, temperature, -voltage and battery information sensors. +voltage, lid position and battery information sensors. .Pp Sensor values are made available through the .Xr sysctl 8
Re: lidaction on an M1 macbook
> > o On arm64, add a machdep.lidaction sysctl(8) > > for aplsmc(4) Apple Silicon laptops. Should that be mentioned in the arm64 examples/sysctl.conf as on other such architectures? Index: etc/etc.arm64/sysctl.conf === RCS file: /cvs/src/etc/etc.arm64/sysctl.conf,v retrieving revision 1.1 diff -u -p -r1.1 sysctl.conf --- etc.arm64/sysctl.conf 11 Jan 2017 22:57:34 - 1.1 +++ etc.arm64/sysctl.conf 11 Apr 2023 15:40:50 - @@ -0,0 +1 @@ +#machdep.lidaction=0 # 1=suspend, 2=hibernate laptop upon lid closing Jan
Re: iostat's four drives by default
ping
On Sep 18 18:16:45, h...@stare.cz wrote:
> Better diff: remove the comment as well.
>
>
> Index: iostat.8
> ===
> RCS file: /cvs/src/usr.sbin/iostat/iostat.8,v
> retrieving revision 1.28
> diff -u -p -r1.28 iostat.8
> --- iostat.8 17 Sep 2022 11:39:09 - 1.28
> +++ iostat.8 18 Sep 2022 16:15:26 -
> @@ -134,9 +134,9 @@ characters written to terminals
> .It disks
> Disk operations.
> The header of the field is the disk name and unit number.
> -If more than four disk drives are configured in the system,
> +By default,
> .Nm
> -displays only the first four drives.
> +displays all drives.
> To force
> .Nm
> to display specific drives, their names may be supplied on the command
> Index: iostat.c
> ===
> RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 iostat.c
> --- iostat.c 12 Jul 2021 15:09:21 - 1.44
> +++ iostat.c 18 Sep 2022 16:15:26 -
> @@ -442,9 +442,8 @@ selectdrives(char *argv[])
> if (reps)
> interval = 1;
>
> - /* Pick up to 4 drives if none specified. */
> if (ndrives == 0)
> - for (i = 0; i < dk_ndrive && ndrives < 4; i++) {
> + for (i = 0; i < dk_ndrive ; i++) {
> if (cur.dk_select[i])
> continue;
> cur.dk_select[i] = 1;
>
>
>
> On Sep 18 18:10:51, h...@stare.cz wrote:
> > By default, iostat displays the first for drives.
> > It would be less surprising if it displayed all drives.
> >
> > It seems that the reason to display four is that
> > it fits into the 80 columns (that is, with -d; otherwise,
> > the cpu and tty display make the line overflow anyway).
> >
> > Jan
> >
> >
> >
> > Index: iostat.8
> > ===
> > RCS file: /cvs/src/usr.sbin/iostat/iostat.8,v
> > retrieving revision 1.28
> > diff -u -p -r1.28 iostat.8
> > --- iostat.817 Sep 2022 11:39:09 - 1.28
> > +++ iostat.818 Sep 2022 16:05:52 -
> > @@ -134,9 +134,9 @@ characters written to terminals
> > .It disks
> > Disk operations.
> > The header of the field is the disk name and unit number.
> > -If more than four disk drives are configured in the system,
> > +By default,
> > .Nm
> > -displays only the first four drives.
> > +displays all drives.
> > To force
> > .Nm
> > to display specific drives, their names may be supplied on the command
> > Index: iostat.c
> > ===
> > RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v
> > retrieving revision 1.44
> > diff -u -p -r1.44 iostat.c
> > --- iostat.c12 Jul 2021 15:09:21 - 1.44
> > +++ iostat.c18 Sep 2022 16:05:52 -
> > @@ -444,7 +444,7 @@ selectdrives(char *argv[])
> >
> > /* Pick up to 4 drives if none specified. */
> > if (ndrives == 0)
> > - for (i = 0; i < dk_ndrive && ndrives < 4; i++) {
> > + for (i = 0; i < dk_ndrive ; i++) {
> > if (cur.dk_select[i])
> > continue;
> > cur.dk_select[i] = 1;
>
>
Re: iostat's four drives by default
Better diff: remove the comment as well.
Index: iostat.8
===
RCS file: /cvs/src/usr.sbin/iostat/iostat.8,v
retrieving revision 1.28
diff -u -p -r1.28 iostat.8
--- iostat.817 Sep 2022 11:39:09 - 1.28
+++ iostat.818 Sep 2022 16:15:26 -
@@ -134,9 +134,9 @@ characters written to terminals
.It disks
Disk operations.
The header of the field is the disk name and unit number.
-If more than four disk drives are configured in the system,
+By default,
.Nm
-displays only the first four drives.
+displays all drives.
To force
.Nm
to display specific drives, their names may be supplied on the command
Index: iostat.c
===
RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v
retrieving revision 1.44
diff -u -p -r1.44 iostat.c
--- iostat.c12 Jul 2021 15:09:21 - 1.44
+++ iostat.c18 Sep 2022 16:15:26 -
@@ -442,9 +442,8 @@ selectdrives(char *argv[])
if (reps)
interval = 1;
- /* Pick up to 4 drives if none specified. */
if (ndrives == 0)
- for (i = 0; i < dk_ndrive && ndrives < 4; i++) {
+ for (i = 0; i < dk_ndrive ; i++) {
if (cur.dk_select[i])
continue;
cur.dk_select[i] = 1;
On Sep 18 18:10:51, h...@stare.cz wrote:
> By default, iostat displays the first for drives.
> It would be less surprising if it displayed all drives.
>
> It seems that the reason to display four is that
> it fits into the 80 columns (that is, with -d; otherwise,
> the cpu and tty display make the line overflow anyway).
>
> Jan
>
>
>
> Index: iostat.8
> ===
> RCS file: /cvs/src/usr.sbin/iostat/iostat.8,v
> retrieving revision 1.28
> diff -u -p -r1.28 iostat.8
> --- iostat.8 17 Sep 2022 11:39:09 - 1.28
> +++ iostat.8 18 Sep 2022 16:05:52 -
> @@ -134,9 +134,9 @@ characters written to terminals
> .It disks
> Disk operations.
> The header of the field is the disk name and unit number.
> -If more than four disk drives are configured in the system,
> +By default,
> .Nm
> -displays only the first four drives.
> +displays all drives.
> To force
> .Nm
> to display specific drives, their names may be supplied on the command
> Index: iostat.c
> ===
> RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 iostat.c
> --- iostat.c 12 Jul 2021 15:09:21 - 1.44
> +++ iostat.c 18 Sep 2022 16:05:52 -
> @@ -444,7 +444,7 @@ selectdrives(char *argv[])
>
> /* Pick up to 4 drives if none specified. */
> if (ndrives == 0)
> - for (i = 0; i < dk_ndrive && ndrives < 4; i++) {
> + for (i = 0; i < dk_ndrive ; i++) {
> if (cur.dk_select[i])
> continue;
> cur.dk_select[i] = 1;
iostat's four drives by default
By default, iostat displays the first for drives.
It would be less surprising if it displayed all drives.
It seems that the reason to display four is that
it fits into the 80 columns (that is, with -d; otherwise,
the cpu and tty display make the line overflow anyway).
Jan
Index: iostat.8
===
RCS file: /cvs/src/usr.sbin/iostat/iostat.8,v
retrieving revision 1.28
diff -u -p -r1.28 iostat.8
--- iostat.817 Sep 2022 11:39:09 - 1.28
+++ iostat.818 Sep 2022 16:05:52 -
@@ -134,9 +134,9 @@ characters written to terminals
.It disks
Disk operations.
The header of the field is the disk name and unit number.
-If more than four disk drives are configured in the system,
+By default,
.Nm
-displays only the first four drives.
+displays all drives.
To force
.Nm
to display specific drives, their names may be supplied on the command
Index: iostat.c
===
RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v
retrieving revision 1.44
diff -u -p -r1.44 iostat.c
--- iostat.c12 Jul 2021 15:09:21 - 1.44
+++ iostat.c18 Sep 2022 16:05:52 -
@@ -444,7 +444,7 @@ selectdrives(char *argv[])
/* Pick up to 4 drives if none specified. */
if (ndrives == 0)
- for (i = 0; i < dk_ndrive && ndrives < 4; i++) {
+ for (i = 0; i < dk_ndrive ; i++) {
if (cur.dk_select[i])
continue;
cur.dk_select[i] = 1;
iostat.8 wording
I believe this reads a little bit better. Jan Index: iostat.8 === RCS file: /cvs/src/usr.sbin/iostat/iostat.8,v retrieving revision 1.27 diff -u -p -r1.27 iostat.8 --- iostat.87 Sep 2018 12:54:44 - 1.27 +++ iostat.815 Sep 2022 14:41:05 - @@ -150,8 +150,9 @@ Transfers per second .It MB/s Megabytes transferred per second .El -The alternate display format, (selected with -.Fl D ) , +.Pp +The alternate display format selected with +.Fl D presents the following values: .Pp .Bl -tag -width indent -compact
Re: obsolete dump options syntax
On Jun 02 07:16:52, dera...@openbsd.org wrote:
> Your diff completely breaks a majority of the ways people use it.
Does that mean people mostly use
the undocumented obsolete syntax
that obsolete() keeps supported?
> Jan Stary wrote:
>
> > # dump /home
> > dump: option requires an argument -- h
> >
> > # dump /music
> > dump: option requires an argument -- s
> >
> > # dump /media
> > dump: option requires an argument -- d
> >
> > What? Before passing its options to getopt(),
> > dump's main() processes them with obsolete():
> >
> > Change set of key letters and ordered arguments
> > into something getopt(3) will like.
> >
> > That results in the above. What obsolete options format
> > is this trying to accomodate? The manpage doesn't say -
> > the options it describes are perfectly getopt()-likable.
> > Looking at the CVS log, this was already "obsolete"
> > in the original 1995 import. Does anyone still use
> > that undescribed obsolete syntax dump "supports"?
> >
> > The diff below simply removes the function.
> > With the diff, dump does the right thing,
> > i.e. just tries to dump the given fs to rst0.
> >
> > # dump /home
> > DUMP: Date of this level 0 dump: Thu Jun 2 14:20:44 2022
> > DUMP: Date of last level 0 dump: the epoch
> > DUMP: Dumping /dev/rsd0a (/home) to /dev/rst0
> > DUMP: mapping (Pass I) [regular files]
> > DUMP: mapping (Pass II) [directories]
> > DUMP: estimated 47580129 tape blocks on 1222.00 tape(s).
> > DUMP: Cannot open output "/dev/rst0".
> >
> > Jan
> >
> >
> > Index: main.c
> > ===
> > RCS file: /cvs/src/sbin/dump/main.c,v
> > retrieving revision 1.62
> > diff -u -p -r1.62 main.c
> > --- main.c 21 Jan 2021 00:16:36 - 1.62
> > +++ main.c 2 Jun 2022 12:23:56 -
> > @@ -99,7 +99,6 @@ struct disklabel lab;
> > static int sblock_try[] = SBLOCKSEARCH;
> >
> > static long long numarg(char *, long long, long long);
> > -static void obsolete(int *, char **[]);
> > static void usage(void);
> >
> > int
> > @@ -134,7 +133,6 @@ main(int argc, char *argv[])
> > if (argc < 2)
> > usage();
> >
> > - obsolete(, );
> > while ((ch = getopt(argc, argv, "0123456789aB:b:cd:f:h:ns:ST:uWw")) !=
> > -1)
> > switch (ch) {
> > /* dump level */
> > @@ -700,80 +698,4 @@ getduid(char *path)
> > }
> >
> > return (NULL);
> > -}
> > -
> > -/*
> > - * obsolete --
> > - * Change set of key letters and ordered arguments into something
> > - * getopt(3) will like.
> > - */
> > -static void
> > -obsolete(int *argcp, char **argvp[])
> > -{
> > - int argc, flags;
> > - char *ap, **argv, *flagsp, **nargv, *p;
> > - size_t len;
> > -
> > - /* Setup. */
> > - argv = *argvp;
> > - argc = *argcp;
> > -
> > - /* Return if no arguments or first argument has leading dash. */
> > - ap = argv[1];
> > - if (argc == 1 || *ap == '-')
> > - return;
> > -
> > - /* Allocate space for new arguments. */
> > - if ((*argvp = nargv = calloc(argc + 1, sizeof(char *))) == NULL ||
> > - (p = flagsp = malloc(strlen(ap) + 2)) == NULL)
> > - err(1, NULL);
> > -
> > - *nargv++ = *argv;
> > - argv += 2;
> > -
> > - for (flags = 0; *ap; ++ap) {
> > - switch (*ap) {
> > - case 'B':
> > - case 'b':
> > - case 'd':
> > - case 'f':
> > - case 'h':
> > - case 's':
> > - case 'T':
> > - if (*argv == NULL) {
> > - warnx("option requires an argument -- %c", *ap);
> > - usage();
> > - }
> > - len = 2 + strlen(*argv) + 1;
> > - if ((nargv[0] = malloc(len)) == NULL)
> > - err(1, NULL);
> > - nargv[0][0] = '-';
> > - nargv[0][1] = *ap;
> > - (void)strlcpy([0][2], *argv, len - 2);
> > - ++argv;
> > - ++nargv;
> > - break;
> > - default:
> > - if (!flags) {
> > - *p++ = '-';
> > - flags = 1;
> > - }
> > - *p++ = *ap;
> > - break;
> > - }
> > - }
> > -
> > - /* Terminate flags, or toss the buffer we did not use. */
> > - if (flags) {
> > - *p = '\0';
> > - *nargv++ = flagsp;
> > - } else
> > - free(flagsp);
> > -
> > - /* Copy remaining arguments. */
> > - while ((*nargv++ = *argv++))
> > - continue;
> > -
> > - /* Update argument count. */
> > - *argcp = nargv - *argvp - 1;
> > }
> >
>
>
Re: obsolete dump options syntax
On Jun 02 14:36:16, h...@stare.cz wrote:
> # dump /home
> dump: option requires an argument -- h
>
> # dump /music
> dump: option requires an argument -- s
>
> # dump /media
> dump: option requires an argument -- d
>
> What? Before passing its options to getopt(),
> dump's main() processes them with obsolete():
>
> Change set of key letters and ordered arguments
> into something getopt(3) will like.
>
> That results in the above. What obsolete options format
> is this trying to accomodate?
http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/dump/main.c.diff?r1=1.4=1.5=h
"Use getopt(3), with obsolete() from restore(8) for backward compatibility."
So it's restore(8); I write "restore rf" myself.
Is this it? Does that still need to be supported by dump(8)?
And by restore(8), while here?
> The manpage doesn't say -
> the options it describes are perfectly getopt()-likable.
> Looking at the CVS log, this was already "obsolete"
> in the original 1995 import. Does anyone still use
> that undescribed obsolete syntax dump "supports"?
>
> The diff below simply removes the function.
> With the diff, dump does the right thing,
> i.e. just tries to dump the given fs to rst0.
>
> # dump /home
> DUMP: Date of this level 0 dump: Thu Jun 2 14:20:44 2022
> DUMP: Date of last level 0 dump: the epoch
> DUMP: Dumping /dev/rsd0a (/home) to /dev/rst0
> DUMP: mapping (Pass I) [regular files]
> DUMP: mapping (Pass II) [directories]
> DUMP: estimated 47580129 tape blocks on 1222.00 tape(s).
> DUMP: Cannot open output "/dev/rst0".
>
> Jan
>
>
> Index: main.c
> ===
> RCS file: /cvs/src/sbin/dump/main.c,v
> retrieving revision 1.62
> diff -u -p -r1.62 main.c
> --- main.c21 Jan 2021 00:16:36 - 1.62
> +++ main.c2 Jun 2022 12:23:56 -
> @@ -99,7 +99,6 @@ struct disklabel lab;
> static int sblock_try[] = SBLOCKSEARCH;
>
> static long long numarg(char *, long long, long long);
> -static void obsolete(int *, char **[]);
> static void usage(void);
>
> int
> @@ -134,7 +133,6 @@ main(int argc, char *argv[])
> if (argc < 2)
> usage();
>
> - obsolete(, );
> while ((ch = getopt(argc, argv, "0123456789aB:b:cd:f:h:ns:ST:uWw")) !=
> -1)
> switch (ch) {
> /* dump level */
> @@ -700,80 +698,4 @@ getduid(char *path)
> }
>
> return (NULL);
> -}
> -
> -/*
> - * obsolete --
> - * Change set of key letters and ordered arguments into something
> - * getopt(3) will like.
> - */
> -static void
> -obsolete(int *argcp, char **argvp[])
> -{
> - int argc, flags;
> - char *ap, **argv, *flagsp, **nargv, *p;
> - size_t len;
> -
> - /* Setup. */
> - argv = *argvp;
> - argc = *argcp;
> -
> - /* Return if no arguments or first argument has leading dash. */
> - ap = argv[1];
> - if (argc == 1 || *ap == '-')
> - return;
> -
> - /* Allocate space for new arguments. */
> - if ((*argvp = nargv = calloc(argc + 1, sizeof(char *))) == NULL ||
> - (p = flagsp = malloc(strlen(ap) + 2)) == NULL)
> - err(1, NULL);
> -
> - *nargv++ = *argv;
> - argv += 2;
> -
> - for (flags = 0; *ap; ++ap) {
> - switch (*ap) {
> - case 'B':
> - case 'b':
> - case 'd':
> - case 'f':
> - case 'h':
> - case 's':
> - case 'T':
> - if (*argv == NULL) {
> - warnx("option requires an argument -- %c", *ap);
> - usage();
> - }
> - len = 2 + strlen(*argv) + 1;
> - if ((nargv[0] = malloc(len)) == NULL)
> - err(1, NULL);
> - nargv[0][0] = '-';
> - nargv[0][1] = *ap;
> - (void)strlcpy([0][2], *argv, len - 2);
> - ++argv;
> - ++nargv;
> - break;
> - default:
> - if (!flags) {
> - *p++ = '-';
> - flags = 1;
> - }
> - *p++ = *ap;
> - break;
> - }
> - }
> -
> - /* Terminate flags, or toss the buffer we did not use. */
> - if (flags) {
> - *p = '\0';
> - *nargv++ = flagsp;
> - } else
> - free(flagsp);
> -
> - /* Copy remaining arguments. */
> - while ((*nargv++ = *argv++))
> - continue;
> -
> - /* Update argument count. */
> - *argcp = nargv - *argvp - 1;
> }
>
>
dump(8) wording
The following wording of dump(8) can IMHO be be simplified without any loss: Rewinding or ejecting tape features after a close operation on a tape device depend on the name of the tape unit device used. I am not a native speaker; but if I parse that right, what "features" are those? Rewinding or ejecting? Then just say that. (Surely dump does not "rewind tape features" or "eject tape features"). Also, "feature" being both a noun and a verb requires extra parsing effort, at least for a non-native speaker. So: Rewinding or ejecting a tape after a close operation on a tape device depends on the name of the tape unit device. I don't know the difference between a "tape device" and a "tape unit device", so I left the "unit" there; if it's superfluous, it can perhaps be "name of the device". Also: dump requires operator intervention on these conditions: end of tape, end of dump, ... dump never required any intervention from me on an "end of dump", it simply says DUMP IS DONE. Would "volume" be more precise here? I don't use tapes, but I suppose an intervention is in order at "end of volume" or perhaps "end of media". Jan
obsolete dump options syntax
# dump /home
dump: option requires an argument -- h
# dump /music
dump: option requires an argument -- s
# dump /media
dump: option requires an argument -- d
What? Before passing its options to getopt(),
dump's main() processes them with obsolete():
Change set of key letters and ordered arguments
into something getopt(3) will like.
That results in the above. What obsolete options format
is this trying to accomodate? The manpage doesn't say -
the options it describes are perfectly getopt()-likable.
Looking at the CVS log, this was already "obsolete"
in the original 1995 import. Does anyone still use
that undescribed obsolete syntax dump "supports"?
The diff below simply removes the function.
With the diff, dump does the right thing,
i.e. just tries to dump the given fs to rst0.
# dump /home
DUMP: Date of this level 0 dump: Thu Jun 2 14:20:44 2022
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rsd0a (/home) to /dev/rst0
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 47580129 tape blocks on 1222.00 tape(s).
DUMP: Cannot open output "/dev/rst0".
Jan
Index: main.c
===
RCS file: /cvs/src/sbin/dump/main.c,v
retrieving revision 1.62
diff -u -p -r1.62 main.c
--- main.c 21 Jan 2021 00:16:36 - 1.62
+++ main.c 2 Jun 2022 12:23:56 -
@@ -99,7 +99,6 @@ struct disklabel lab;
static int sblock_try[] = SBLOCKSEARCH;
static long long numarg(char *, long long, long long);
-static void obsolete(int *, char **[]);
static void usage(void);
int
@@ -134,7 +133,6 @@ main(int argc, char *argv[])
if (argc < 2)
usage();
- obsolete(, );
while ((ch = getopt(argc, argv, "0123456789aB:b:cd:f:h:ns:ST:uWw")) !=
-1)
switch (ch) {
/* dump level */
@@ -700,80 +698,4 @@ getduid(char *path)
}
return (NULL);
-}
-
-/*
- * obsolete --
- * Change set of key letters and ordered arguments into something
- * getopt(3) will like.
- */
-static void
-obsolete(int *argcp, char **argvp[])
-{
- int argc, flags;
- char *ap, **argv, *flagsp, **nargv, *p;
- size_t len;
-
- /* Setup. */
- argv = *argvp;
- argc = *argcp;
-
- /* Return if no arguments or first argument has leading dash. */
- ap = argv[1];
- if (argc == 1 || *ap == '-')
- return;
-
- /* Allocate space for new arguments. */
- if ((*argvp = nargv = calloc(argc + 1, sizeof(char *))) == NULL ||
- (p = flagsp = malloc(strlen(ap) + 2)) == NULL)
- err(1, NULL);
-
- *nargv++ = *argv;
- argv += 2;
-
- for (flags = 0; *ap; ++ap) {
- switch (*ap) {
- case 'B':
- case 'b':
- case 'd':
- case 'f':
- case 'h':
- case 's':
- case 'T':
- if (*argv == NULL) {
- warnx("option requires an argument -- %c", *ap);
- usage();
- }
- len = 2 + strlen(*argv) + 1;
- if ((nargv[0] = malloc(len)) == NULL)
- err(1, NULL);
- nargv[0][0] = '-';
- nargv[0][1] = *ap;
- (void)strlcpy([0][2], *argv, len - 2);
- ++argv;
- ++nargv;
- break;
- default:
- if (!flags) {
- *p++ = '-';
- flags = 1;
- }
- *p++ = *ap;
- break;
- }
- }
-
- /* Terminate flags, or toss the buffer we did not use. */
- if (flags) {
- *p = '\0';
- *nargv++ = flagsp;
- } else
- free(flagsp);
-
- /* Copy remaining arguments. */
- while ((*nargv++ = *argv++))
- continue;
-
- /* Update argument count. */
- *argcp = nargv - *argvp - 1;
}
Re: apmd(8): reconnecting AC, not battery
On May 28 10:34:35, s...@spacehopper.org wrote: > On 2022/05/28 06:52, Jason McIntyre wrote: > > On Fri, May 27, 2022 at 07:19:37PM +0200, Jan Stary wrote: > > > apmd says: > > > > > > When the power status changes (battery is connected or disconnected), > > > apmd fetches the current status and reports it via syslog(3) > > > with logging facility LOG_DAEMON. > > > > > > Is "battery" really meant here? Should that be the AC power? > > > Batteries are typically not being reconnected while running ... > > They certainly can be, either while on external power, or in the case of > machines with multiple batteries (several generations of X series ThinkPads > have both internal and external batteries, so you can swap without powering > down even while on battery power). But yes the common case would be > external power. > > > > (The manpage calls it "external power", "line current" > > > and "AC" interchangably.) > > > > > > Jan > > > > > > > hi. > > > > i think you're right that the text is off. the author possibly meant to > > say battery was charging or discharging. > > > > anyway, if i don;t hear any reason not to soon, i'll commit your > > suggested diff (which i think is simpler and makes sense). > > Why be inaccurate when we don't need to be - it's very uncommon to have > a machine with a battery with an AC input. "External power" would make > more sense. I never liked the AC nomenclature either; it's battery vs wall socket, not AC vs DC. Feel free to change the wording of course. Jan
apmd(8): reconnecting AC, not battery
apmd says: When the power status changes (battery is connected or disconnected), apmd fetches the current status and reports it via syslog(3) with logging facility LOG_DAEMON. Is "battery" really meant here? Should that be the AC power? Batteries are typically not being reconnected while running ... (The manpage calls it "external power", "line current" and "AC" interchangably.) Jan Index: apmd.8 === RCS file: /cvs/src/usr.sbin/apmd/apmd.8,v retrieving revision 1.54 diff -u -p -r1.54 apmd.8 --- apmd.8 31 Mar 2022 17:27:29 - 1.54 +++ apmd.8 27 May 2022 17:13:52 - @@ -58,7 +58,7 @@ When resuming after suspend or standby, runs the appropriate configuration program (if one exists). .Pp When the power status changes -(battery is connected or disconnected), +(AC is connected or disconnected), .Nm fetches the current status and reports it via .Xr syslog 3
Re: apm -m means one of two things now
On Feb 10 16:33:20, j...@juef.net wrote: > (Thu, 10 Feb 14:59) Jan Stary: > > With the recent change to apm -m, > > reporting either the battery lifetime > > or the estimated time to charge (thank you), > > the manpage seems to have been left behind. > > > > While here, tweak some of the wording: > > > > - "in minutes" or "in percent" is not parenthetical; say it explicitly > > - surely -a displays the charger status, not the charger > > - AC is AC, not A/C, right? > > -Display the estimated battery lifetime (in minutes). > > +Display the estimated battery lifetime in minutes when running or battery, > > typo: > running or battery => running on battery Thanks, new diff below. Jan Index: apm.8 === RCS file: /cvs/src/usr.sbin/apm/apm.8,v retrieving revision 1.44 diff -u -p -r1.44 apm.8 --- apm.8 3 Nov 2021 19:54:28 - 1.44 +++ apm.8 10 Feb 2022 13:52:38 - @@ -59,7 +59,7 @@ The options are as follows: .It Fl A Switch to automatic performance adjustment mode (the default). .It Fl a -Display the external charger (A/C status). +Display the external charger (AC) status. 0 means disconnected, 1 means connected, 2 means backup power source, and 255 means unknown. .It Fl b @@ -82,9 +82,10 @@ setting .Va hw.setperf to 0. .It Fl l -Display the estimated battery lifetime (in percent). +Display the estimated battery lifetime in percent. .It Fl m -Display the estimated battery lifetime (in minutes). +Display the estimated battery lifetime in minutes when running on battery, +or the estimated time to recharge when running on an external charger. .It Fl P Display the performance adjustment mode. 0 means manual mode.
apm -m means one of two things now
With the recent change to apm -m, reporting either the battery lifetime or the estimated time to charge (thank you), the manpage seems to have been left behind. While here, tweak some of the wording: - "in minutes" or "in percent" is not parenthetical; say it explicitly - surely -a displays the charger status, not the charger - AC is AC, not A/C, right? Jan Index: apm.8 === RCS file: /cvs/src/usr.sbin/apm/apm.8,v retrieving revision 1.44 diff -u -p -r1.44 apm.8 --- apm.8 3 Nov 2021 19:54:28 - 1.44 +++ apm.8 10 Feb 2022 13:52:38 - @@ -59,7 +59,7 @@ The options are as follows: .It Fl A Switch to automatic performance adjustment mode (the default). .It Fl a -Display the external charger (A/C status). +Display the external charger (AC) status. 0 means disconnected, 1 means connected, 2 means backup power source, and 255 means unknown. .It Fl b @@ -82,9 +82,10 @@ setting .Va hw.setperf to 0. .It Fl l -Display the estimated battery lifetime (in percent). +Display the estimated battery lifetime in percent. .It Fl m -Display the estimated battery lifetime (in minutes). +Display the estimated battery lifetime in minutes when running or battery, +or the estimated time to recharge when running on an external charger. .It Fl P Display the performance adjustment mode. 0 means manual mode.
Re: request for testing: malloc and large allocations
On Feb 05 17:35:46, o...@drijf.net wrote: > On Sat, Feb 05, 2022 at 05:22:50PM +0100, Jan Stary wrote: > > > On Feb 02 00:04:37, alexander.bl...@gmx.net wrote: > > > On Tue, Feb 01, 2022 at 08:00:36AM +0100, Otto Moerbeek wrote: > > > > > Are you running with any malloc flags? > > > > > > > > This bug report enabled me to find a bug that would pop up if G mode > > > > is enabled. > > > > > > > > New diff below. New tests appreciated. > > > > > > Passed a make build on macppc (Mac Mini, dmesg below). > > > > 4288m32.43s real 3309m41.24s user 802m02.37s system > > Recompiling now with the new malloc to see the difference. > > Note that during a make build, libs get installed after building them > so all dynamically linked programs will use the new malloc from that > point, as there is no revision bump. Does that mean that both passes of compiling the compiler (i.e., compiling clang with the current clang, and then compiling clang with the new clang, if I remember correctly) already use the new libc? (Compiling clang has taken most of the ~3 days of make build.) Jan > > [ using 1308496 bytes of bsd ELF symbol table ] > > console out [ATY,RockHopper2_A] console in [keyboard], using USB > > using parent ATY,RockHopper2Paren:: memaddr 9800, size 800 : > > consaddr 9c008000 : ioaddr 9002, size 2: width 1920 linebytes 2048 > > height 1080 depth 8 > > Copyright (c) 1982, 1986, 1989, 1991, 1993 > > The Regents of the University of California. All rights reserved. > > Copyright (c) 1995-2022 OpenBSD. All rights reserved. > > https://www.OpenBSD.org > > > > OpenBSD 7.0-current (GENERIC) #0: Mon Jan 31 13:22:27 CET 2022 > > h...@ppc.stare.cz:/usr/src/sys/arch/macppc/compile/GENERIC > > real mem = 1073741824 (1024MB) > > avail mem = 1025527808 (978MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root: model PowerMac10,2 > > cpu0 at mainbus0: 7447A (Revision 0x102): 1499 MHz: 512KB L2 cache > > mem0 at mainbus0 > > spdmem0 at mem0: 1GB DDR SDRAM non-parity PC3200CL3.0 > > memc0 at mainbus0: uni-n rev 0xd2 > > "hw-clock" at memc0 not configured > > kiic0 at memc0 offset 0xf8001000 > > iic0 at kiic0 > > mpcpcibr0 at mainbus0 pci: uni-north > > pci0 at mpcpcibr0 bus 0 > > pchb0 at pci0 dev 11 function 0 "Apple UniNorth AGP" rev 0x00 > > agp at pchb0 not configured > > radeondrm0 at pci0 dev 16 function 0 "ATI Radeon 9200" rev 0x01 > > drm0 at radeondrm0 > > radeondrm0: irq 48 > > mpcpcibr1 at mainbus0 pci: uni-north > > pci1 at mpcpcibr1 bus 0 > > macobio0 at pci1 dev 23 function 0 "Apple Intrepid" rev 0x00 > > openpic0 at macobio0 offset 0x4: version 0x4614 feature 3f0302 LE > > macgpio0 at macobio0 offset 0x50 > > "modem-reset" at macgpio0 offset 0x1d not configured > > "modem-power" at macgpio0 offset 0x1c not configured > > macgpio1 at macgpio0 offset 0x9: irq 47 > > "programmer-switch" at macgpio0 offset 0x11 not configured > > "gpio5" at macgpio0 offset 0x6f not configured > > "gpio6" at macgpio0 offset 0x70 not configured > > "extint-gpio15" at macgpio0 offset 0x67 not configured > > "escc-legacy" at macobio0 offset 0x12000 not configured > > zs0 at macobio0 offset 0x13000: irq 22,23 > > zstty0 at zs0 channel 0 > > zstty1 at zs0 channel 1 > > aoa0 at macobio0 offset 0x1: irq 30,1,2 > > "timer" at macobio0 offset 0x15000 not configured > > adb0 at macobio0 offset 0x16000 > > apm0 at adb0: battery flags 0x0, 0% charged > > piic0 at adb0 > > iic1 at piic0 > > maxtmp0 at iic1 addr 0xc8: max6642 > > kiic1 at macobio0 offset 0x18000 > > iic2 at kiic1 > > wdc0 at macobio0 offset 0x2 irq 24: DMA > > audio0 at aoa0 > > ohci0 at pci1 dev 26 function 0 "Apple Intrepid USB" rev 0x00: irq 29, > > version 1.0, legacy support > > ohci1 at pci1 dev 27 function 0 "NEC USB" rev 0x43: irq 63, version 1.0 > > ohci2 at pci1 dev 27 function 1 "NEC USB" rev 0x43: irq 63, version 1.0 > > ehci0 at pci1 dev 27 function 2 "NEC USB" rev 0x04: irq 63 > > usb0 at ehci0: USB revision 2.0 > > uhub0 at usb0 configuration 1 interface 0 "NEC EHCI root hub" rev 2.00/1.00 > > addr 1 > > usb1 at ohci0: USB revision 1.0 > > uhub1 at usb1 configuration 1 interface 0 "Apple OHCI root hub" rev > > 1
Re: request for testing: malloc and large allocations
On Feb 02 00:04:37, alexander.bl...@gmx.net wrote: > On Tue, Feb 01, 2022 at 08:00:36AM +0100, Otto Moerbeek wrote: > > > Are you running with any malloc flags? > > > > This bug report enabled me to find a bug that would pop up if G mode > > is enabled. > > > > New diff below. New tests appreciated. Passed a make build on macppc (Mac Mini, dmesg below). 4288m32.43s real 3309m41.24s user 802m02.37s system Recompiling now with the new malloc to see the difference. Jan [ using 1308496 bytes of bsd ELF symbol table ] console out [ATY,RockHopper2_A] console in [keyboard], using USB using parent ATY,RockHopper2Paren:: memaddr 9800, size 800 : consaddr 9c008000 : ioaddr 9002, size 2: width 1920 linebytes 2048 height 1080 depth 8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2022 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 7.0-current (GENERIC) #0: Mon Jan 31 13:22:27 CET 2022 h...@ppc.stare.cz:/usr/src/sys/arch/macppc/compile/GENERIC real mem = 1073741824 (1024MB) avail mem = 1025527808 (978MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root: model PowerMac10,2 cpu0 at mainbus0: 7447A (Revision 0x102): 1499 MHz: 512KB L2 cache mem0 at mainbus0 spdmem0 at mem0: 1GB DDR SDRAM non-parity PC3200CL3.0 memc0 at mainbus0: uni-n rev 0xd2 "hw-clock" at memc0 not configured kiic0 at memc0 offset 0xf8001000 iic0 at kiic0 mpcpcibr0 at mainbus0 pci: uni-north pci0 at mpcpcibr0 bus 0 pchb0 at pci0 dev 11 function 0 "Apple UniNorth AGP" rev 0x00 agp at pchb0 not configured radeondrm0 at pci0 dev 16 function 0 "ATI Radeon 9200" rev 0x01 drm0 at radeondrm0 radeondrm0: irq 48 mpcpcibr1 at mainbus0 pci: uni-north pci1 at mpcpcibr1 bus 0 macobio0 at pci1 dev 23 function 0 "Apple Intrepid" rev 0x00 openpic0 at macobio0 offset 0x4: version 0x4614 feature 3f0302 LE macgpio0 at macobio0 offset 0x50 "modem-reset" at macgpio0 offset 0x1d not configured "modem-power" at macgpio0 offset 0x1c not configured macgpio1 at macgpio0 offset 0x9: irq 47 "programmer-switch" at macgpio0 offset 0x11 not configured "gpio5" at macgpio0 offset 0x6f not configured "gpio6" at macgpio0 offset 0x70 not configured "extint-gpio15" at macgpio0 offset 0x67 not configured "escc-legacy" at macobio0 offset 0x12000 not configured zs0 at macobio0 offset 0x13000: irq 22,23 zstty0 at zs0 channel 0 zstty1 at zs0 channel 1 aoa0 at macobio0 offset 0x1: irq 30,1,2 "timer" at macobio0 offset 0x15000 not configured adb0 at macobio0 offset 0x16000 apm0 at adb0: battery flags 0x0, 0% charged piic0 at adb0 iic1 at piic0 maxtmp0 at iic1 addr 0xc8: max6642 kiic1 at macobio0 offset 0x18000 iic2 at kiic1 wdc0 at macobio0 offset 0x2 irq 24: DMA audio0 at aoa0 ohci0 at pci1 dev 26 function 0 "Apple Intrepid USB" rev 0x00: irq 29, version 1.0, legacy support ohci1 at pci1 dev 27 function 0 "NEC USB" rev 0x43: irq 63, version 1.0 ohci2 at pci1 dev 27 function 1 "NEC USB" rev 0x43: irq 63, version 1.0 ehci0 at pci1 dev 27 function 2 "NEC USB" rev 0x04: irq 63 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "NEC EHCI root hub" rev 2.00/1.00 addr 1 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 configuration 1 interface 0 "Apple OHCI root hub" rev 1.00/1.00 addr 1 usb2 at ohci1: USB revision 1.0 uhub2 at usb2 configuration 1 interface 0 "NEC OHCI root hub" rev 1.00/1.00 addr 1 usb3 at ohci2: USB revision 1.0 uhub3 at usb3 configuration 1 interface 0 "NEC OHCI root hub" rev 1.00/1.00 addr 1 mpcpcibr2 at mainbus0 pci: uni-north pci2 at mpcpcibr2 bus 0 kauaiata0 at pci2 dev 13 function 0 "Apple Intrepid ATA" rev 0x00 wdc1 at kauaiata0 irq 39: DMA wd0 at wdc1 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors wd0(wdc1:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 "Apple UniNorth Firewire" rev 0x81 at pci2 dev 14 function 0 not configured gem0 at pci2 dev 15 function 0 "Apple Uni-N2 GMAC" rev 0x80: irq 41, address 00:14:51:17:42:34 bmtphy0 at gem0 phy 0: BCM5221 100baseTX PHY, rev. 4 uhub4 at uhub3 port 1 configuration 1 interface 0 "Mitsumi Electric Hub in Apple Extended USB Keyboard" rev 1.10/4.10 addr 2 uhidev0 at uhub4 port 3 configuration 1 interface 0 "Mitsumi Electric Apple Extended USB Keyboard" rev 1.10/4.10 addr 3 uhidev0: iclass 3/1 ukbd0 at uhidev0: 8 variable keys, 6 key codes, country code 13 wskbd0 at ukbd0: console keyboard uhidev1 at uhub4 port 3 configuration 1 interface 1 "Mitsumi Electric Apple Extended USB Keyboard" rev 1.10/4.10 addr 3 uhidev1: iclass 3/0, 3 report ids uhid0 at uhidev1 reportid 2: input=1, output=0, feature=0 ucc0 at uhidev1 reportid 3: 4 usages, 4 keys, enum wskbd1 at ucc0 mux 1 vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets bootpath: /pci@f400/ata-6@d/disk@0:/bsd root on wd0a (64c5f028a86139ec.a) swap on wd0b dump on wd0b
Re: locale-specific collation sequence?
On Feb 01 17:00:29, dera...@openbsd.org wrote:
> I don't understand your point. We should not require shell-script writers
> to read C manual pages. Imagine the following:
>
> DESCRIPTION
> The cat utility calls open(2) for files sequentially, then read(2)'s the
> contents into a buffer before using write(2) the standard output.
>
> No. I don't see a problem with explaining what a program does in simple,
> clear english.
The point isn't to introduce a link to a C manpage,
or to avoid simple english, but to avoid the wording
of "the locale-specific" collation sequence
when LC_COLLATE is in fact ignored.
I agreee that the diff is not a very good way to go about that.
But the current wording suggests that after one specifies a locale,
expr will compare strings according the that.
locale(1) describes LC_COLLATE of course,
Intended to affect collation order. It may for example
affect alphabetic sorting, regular expressions including
equivalence classes, and the strcoll(3) and strxfrm(3) functions.
so only in strcoll(3) does one eventualy read that
the locale has in fact no effect on collation.
That was the intention.
Jan
> Jan Stary wrote:
>
> > Looking at the source, it's simply strcoll().
> >
> > Jan
> >
> >
> > Index: bin/expr/expr.1
> > ===
> > RCS file: /cvs/src/bin/expr/expr.1,v
> > retrieving revision 1.24
> > diff -u -p -r1.24 expr.1
> > --- bin/expr/expr.1 16 Aug 2017 20:10:58 - 1.24
> > +++ bin/expr/expr.1 1 Feb 2022 22:53:12 -
> > @@ -39,9 +39,10 @@ Returns the evaluation of
> > if neither expression evaluates to an empty string or zero;
> > otherwise, returns zero.
> > .It Ar expr1 Li "{=, >, >=, <, <=, !=}" Ar expr2
> > -Returns the results of integer comparison if both arguments are
> > -decimal integers; otherwise, returns the results of string comparison
> > -using the locale-specific collation sequence.
> > +Returns the results of integer comparison
> > +if both arguments are decimal integers;
> > +otherwise, returns the results of string comparison using
> > +.Xr strcoll 3 .
> > The result of each comparison is 1 if the specified relation is true,
> > or 0 if the relation is false.
> > .It Ar expr1 Li "{+, -}" Ar expr2
> >
>
>
locale-specific collation sequence?
Looking at the source, it's simply strcoll().
Jan
Index: bin/expr/expr.1
===
RCS file: /cvs/src/bin/expr/expr.1,v
retrieving revision 1.24
diff -u -p -r1.24 expr.1
--- bin/expr/expr.1 16 Aug 2017 20:10:58 - 1.24
+++ bin/expr/expr.1 1 Feb 2022 22:53:12 -
@@ -39,9 +39,10 @@ Returns the evaluation of
if neither expression evaluates to an empty string or zero;
otherwise, returns zero.
.It Ar expr1 Li "{=, >, >=, <, <=, !=}" Ar expr2
-Returns the results of integer comparison if both arguments are
-decimal integers; otherwise, returns the results of string comparison
-using the locale-specific collation sequence.
+Returns the results of integer comparison
+if both arguments are decimal integers;
+otherwise, returns the results of string comparison using
+.Xr strcoll 3 .
The result of each comparison is 1 if the specified relation is true,
or 0 if the relation is false.
.It Ar expr1 Li "{+, -}" Ar expr2
unistd.h already declares optind and friends
Index: yppoll/yppoll.c
===
RCS file: /cvs/src/usr.sbin/yppoll/yppoll.c,v
retrieving revision 1.15
diff -u -p -r1.15 yppoll.c
--- yppoll/yppoll.c 16 Jan 2015 06:40:22 - 1.15
+++ yppoll/yppoll.c 1 Feb 2022 22:35:00 -
@@ -126,8 +126,6 @@ int
main(int argc, char *argv[])
{
char *domainname, *hostname = NULL, *inmap, *master;
- extern char *optarg;
- extern int optind;
int order, c, r;
time_t torder;
Index: ypserv/makedbm/makedbm.c
===
RCS file: /cvs/src/usr.sbin/ypserv/makedbm/makedbm.c,v
retrieving revision 1.33
diff -u -p -r1.33 makedbm.c
--- ypserv/makedbm/makedbm.c9 Feb 2015 23:00:15 - 1.33
+++ ypserv/makedbm/makedbm.c1 Feb 2022 22:35:00 -
@@ -302,9 +302,6 @@ main(int argc, char *argv[])
char*infile, *outfile;
int ch;
- extern int optind;
- extern char *optarg;
-
yp_input_file = yp_output_file = NULL;
yp_master_name = yp_domain_name = NULL;
aflag = uflag = bflag = lflag = sflag = Uflag = 0;
Index: ypserv/yppush/yppush.c
===
RCS file: /cvs/src/usr.sbin/ypserv/yppush/yppush.c,v
retrieving revision 1.31
diff -u -p -r1.31 yppush.c
--- ypserv/yppush/yppush.c 16 Jan 2015 06:40:23 - 1.31
+++ ypserv/yppush/yppush.c 1 Feb 2022 22:35:00 -
@@ -216,8 +216,6 @@ int
main(int argc, char *argv[])
{
struct ypall_callback ypcb;
- extern char *optarg;
- extern int optind;
char*domain, *map, *hostname;
int c, r, i;
char *ypmap = "ypservers";
Index: ypset/ypset.c
===
RCS file: /cvs/src/usr.sbin/ypset/ypset.c,v
retrieving revision 1.20
diff -u -p -r1.20 ypset.c
--- ypset/ypset.c 16 Jan 2015 06:40:23 - 1.20
+++ ypset/ypset.c 1 Feb 2022 22:35:00 -
@@ -106,8 +106,6 @@ main(int argc, char *argv[])
{
struct sockaddr_in sin;
struct hostent *hent;
- extern char *optarg;
- extern int optind;
char *domainname;
int c;
Re: kern.file in sysctl(8)
On Dec 24 10:20:03, h...@stare.cz wrote:
> Similarly for kern.proc and ps(1).
In fact,
warnx("use netstat to view %s", string);
warnx("use dmesg to view %s", string);
warnx("use ps to view %s information", string);
warnx("use vmstat or systat to view %s information",
warnx("use fstat to view %s information", string);
warnx("use pfctl to view %s information", string);
warnx("use vmstat to view %s information",
warnx("use vmstat or systat to view %s information", string);
warnx("use netstat to view %s information",
warnx("use netstat to view %s information",
warnx("use netstat to view %s information", string);
warnx("use nfsstat to view %s information",
warnx("use pstat -t to view %s information",
So perhaps thesse variables are
mentioned in sysctl(2) on purpose.
Sorry for the noise.
Jan
> On Dec 24 10:18:15, h...@stare.cz wrote:
> > The sysctl(2) manpage also lists the corresponding sysctl(8) variables:
> >
> > Information may be retrieved and set using the sysctl(8) utility;
> > the variable names used by this utility are given here in parentheses.
> >
> > Among these is kern.file, which, understandably, just points to fstat(8).
> > Would it be better to not list it as a sysctl(8) var?
> > Or is it left there on purpose?
> >
> > Jan
> >
> >
> > Index: sysctl.2
> > ===
> > RCS file: /cvs/src/lib/libc/sys/sysctl.2,v
> > retrieving revision 1.46
> > diff -u -p -r1.46 sysctl.2
> > --- sysctl.23 Nov 2021 00:48:08 - 1.46
> > +++ sysctl.224 Dec 2021 09:13:26 -
> > @@ -582,7 +582,7 @@ and a bit mask indicating the status of
> > third level name.
> > .It Dv KERN_DOMAINNAME Pq Va kern.domainname
> > Get or set the YP domain name.
> > -.It Dv KERN_FILE Pq Va kern.file
> > +.It Dv KERN_FILE
> > Return the entire file table, or a subset of it.
> > An array of
> > .Vt struct kinfo_file
Re: kern.file in sysctl(8)
Similarly for kern.proc and ps(1). On Dec 24 10:18:15, h...@stare.cz wrote: > The sysctl(2) manpage also lists the corresponding sysctl(8) variables: > > Information may be retrieved and set using the sysctl(8) utility; > the variable names used by this utility are given here in parentheses. > > Among these is kern.file, which, understandably, just points to fstat(8). > Would it be better to not list it as a sysctl(8) var? > Or is it left there on purpose? > > Jan > > > Index: sysctl.2 > === > RCS file: /cvs/src/lib/libc/sys/sysctl.2,v > retrieving revision 1.46 > diff -u -p -r1.46 sysctl.2 > --- sysctl.2 3 Nov 2021 00:48:08 - 1.46 > +++ sysctl.2 24 Dec 2021 09:13:26 - > @@ -582,7 +582,7 @@ and a bit mask indicating the status of > third level name. > .It Dv KERN_DOMAINNAME Pq Va kern.domainname > Get or set the YP domain name. > -.It Dv KERN_FILE Pq Va kern.file > +.It Dv KERN_FILE > Return the entire file table, or a subset of it. > An array of > .Vt struct kinfo_file
kern.file in sysctl(8)
The sysctl(2) manpage also lists the corresponding sysctl(8) variables: Information may be retrieved and set using the sysctl(8) utility; the variable names used by this utility are given here in parentheses. Among these is kern.file, which, understandably, just points to fstat(8). Would it be better to not list it as a sysctl(8) var? Or is it left there on purpose? Jan Index: sysctl.2 === RCS file: /cvs/src/lib/libc/sys/sysctl.2,v retrieving revision 1.46 diff -u -p -r1.46 sysctl.2 --- sysctl.23 Nov 2021 00:48:08 - 1.46 +++ sysctl.224 Dec 2021 09:13:26 - @@ -582,7 +582,7 @@ and a bit mask indicating the status of third level name. .It Dv KERN_DOMAINNAME Pq Va kern.domainname Get or set the YP domain name. -.It Dv KERN_FILE Pq Va kern.file +.It Dv KERN_FILE Return the entire file table, or a subset of it. An array of .Vt struct kinfo_file
Re: Please test: UVM fault unlocking (aka vmobjlock)
On Dec 04 14:28:23, h...@stare.cz wrote: > On Dec 04 12:23:42, h...@stare.cz wrote: > > On Dec 01 09:07:43, h...@stare.cz wrote: > > > > > > On 24/11/21(Wed) 11:16, Martin Pieuchot wrote: > > > > > > > Diff below unlock the bottom part of the UVM fault handler. I'm > > > > > > > interested in squashing the remaining bugs. Please test with > > > > > > > your usual > > > > > > > setup & report back. > > > > > > > > > > > > Thanks to all the testers, here's a new version that includes a bug > > > > > > fix. > > > > > > Tests on !x86 architectures are much appreciated! current/amd64 on a Thinkpad T410 (dmesg below) having this patch just panicked with the following message: uvm_fault(0xfd8135c51178, 0x48, 0, 1) -> e I don't know if it's related to the patch, but given that the panic is uvm_faiult() ... Upon boot, the kernel said Dec 5 17:00:34 t410 /bsd: witness: lock order reversal: Dec 5 17:00:34 t410 /bsd: 1st 0xfd8115667438 uobjlk (>vmobjlock) Dec 5 17:00:34 t410 /bsd: 2nd 0x80bcf700 objmm (>mm.lock) Dec 5 17:00:34 t410 /bsd: lock order ">mm.lock"(rwlock) -> ">vmobjlock"(rwlock) first seen at: Dec 5 17:00:34 t410 /bsd: #0 rw_enter+0x65 Dec 5 17:00:34 t410 /bsd: #1 uvm_obj_wire+0x46 Dec 5 17:00:34 t410 /bsd: #2 shmem_get_pages+0xaf Dec 5 17:00:34 t410 /bsd: #3 __i915_gem_object_get_pages+0x9d Dec 5 17:00:34 t410 /bsd: #4 i915_vma_pin_ww+0x49b Dec 5 17:00:34 t410 /bsd: #5 i915_ggtt_pin+0x61 Dec 5 17:00:34 t410 /bsd: #6 __intel_context_do_pin_ww+0x2d1 Dec 5 17:00:34 t410 /bsd: #7 __intel_context_do_pin+0x4b Dec 5 17:00:34 t410 /bsd: #8 intel_engines_init+0x4a1 Dec 5 17:00:34 t410 /bsd: #9 intel_gt_init+0x133 Dec 5 17:00:34 t410 /bsd: #10 i915_gem_init+0xa3 Dec 5 17:00:34 t410 /bsd: #11 i915_driver_probe+0x75a Dec 5 17:00:34 t410 /bsd: #12 inteldrm_attachhook+0x45 Dec 5 17:00:34 t410 /bsd: #13 config_process_deferred_mountroot+0x6b Dec 5 17:00:34 t410 /bsd: #14 main+0x743 Dec 5 17:00:34 t410 /bsd: lock order ">vmobjlock"(rwlock) -> ">mm.lock"(rwlock) first seen at: Dec 5 17:00:34 t410 /bsd: #0 rw_enter+0x65 Dec 5 17:00:34 t410 /bsd: #1 __i915_gem_object_get_pages+0x30 Dec 5 17:00:34 t410 /bsd: #2 i915_gem_fault+0x408 Dec 5 17:00:34 t410 /bsd: #3 drm_fault+0x156 Dec 5 17:00:34 t410 /bsd: #4 uvm_fault+0x179 Dec 5 17:00:34 t410 /bsd: #5 upageflttrap+0x62 Dec 5 17:00:34 t410 /bsd: #6 usertrap+0x18b Dec 5 17:00:34 t410 /bsd: #7 recall_trap+0x8 Dec 5 17:00:34 t410 /bsd: witness: lock order reversal: Dec 5 17:00:34 t410 /bsd: 1st 0xfd8115667438 uobjlk (>vmobjlock) Dec 5 17:00:34 t410 /bsd: 2nd 0x80bd0e48 vmapg (>pages_mutex) Dec 5 17:00:34 t410 /bsd: lock order data w2 -> w1 missing Dec 5 17:00:34 t410 /bsd: lock order ">vmobjlock"(rwlock) -> ">pages_mutex"(rwlock) first seen at: Dec 5 17:00:34 t410 /bsd: #0 rw_enter+0x65 Dec 5 17:00:34 t410 /bsd: #1 i915_vma_pin_ww+0x1c7 Dec 5 17:00:34 t410 /bsd: #2 i915_gem_object_ggtt_pin_ww+0x222 Dec 5 17:00:34 t410 /bsd: #3 i915_gem_fault+0x450 Dec 5 17:00:34 t410 /bsd: #4 drm_fault+0x156 Dec 5 17:00:34 t410 /bsd: #5 uvm_fault+0x179 Dec 5 17:00:34 t410 /bsd: #6 upageflttrap+0x62 Dec 5 17:00:34 t410 /bsd: #7 usertrap+0x18b Dec 5 17:00:34 t410 /bsd: #8 recall_trap+0x8 Dec 5 17:00:34 t410 /bsd: witness: lock order reversal: Dec 5 17:00:34 t410 /bsd: 1st 0xfd8115667438 uobjlk (>vmobjlock) Dec 5 17:00:34 t410 /bsd: 2nd 0x80111070 vmlk (>mutex) Dec 5 17:00:34 t410 /bsd: lock order data w2 -> w1 missing Dec 5 17:00:34 t410 /bsd: lock order ">vmobjlock"(rwlock) -> ">mutex"(rwlock) first seen at: Dec 5 17:00:34 t410 /bsd: #0 rw_enter+0x65 Dec 5 17:00:34 t410 /bsd: #1 i915_vma_pin_ww+0x2f2 Dec 5 17:00:34 t410 /bsd: #2 i915_gem_object_ggtt_pin_ww+0x222 Dec 5 17:00:34 t410 /bsd: #3 i915_gem_fault+0x450 Dec 5 17:00:34 t410 /bsd: #4 drm_fault+0x156 Dec 5 17:00:34 t410 /bsd: #5 uvm_fault+0x179 Dec 5 17:00:34 t410 /bsd: #6 upageflttrap+0x62 Dec 5 17:00:34 t410 /bsd: #7 usertrap+0x18b Dec 5 17:00:34 t410 /bsd: #8 recall_trap+0x8 but the machine was running as usual, with about three chrome tabs, and mplayer playing some audio files. Then, after about two hours: Dec 5 18:46:36 t410 /bsd: uvm_fault(0xfd8135c51178, 0x48, 0, 1) -> e Dec 5 18:46:36 t410 /bsd: kernel: page fault trap, code=0 Dec 5 18:46:36 t410 /bsd: Stopped at pledge_recvfd+0x59: movl 0x48(%rsi),%eax Dec 5 18:46:36 t410 /bsd: TIDPIDUID PRFLAGS PFLAGS CPU COMMAND Dec 5 18:46:36 t410 /bsd: * 13684 98899 10000x33 0x4000K chrome Dec 5 18:46:36 t410 /bsd: 137636 44471 990x100010 02 sndiod Dec 5 18:46:36 t410 /bsd: pledge_recvfd(8000334e4a90,0) at pledge_recvfd+0x59 Dec 5 18:46:36 t410 /bsd: unp_externalize(fd8063543600,210,80) at unp_externalize+0x10c Dec 5 18:46:36 t410 /bsd:
Re: Please test: UVM fault unlocking (aka vmobjlock)
On Dec 04 12:23:42, h...@stare.cz wrote: > On Dec 01 09:07:43, h...@stare.cz wrote: > > > > > On 24/11/21(Wed) 11:16, Martin Pieuchot wrote: > > > > > > Diff below unlock the bottom part of the UVM fault handler. I'm > > > > > > interested in squashing the remaining bugs. Please test with your > > > > > > usual > > > > > > setup & report back. > > > > > > > > > > Thanks to all the testers, here's a new version that includes a bug > > > > > fix. > > > > > Tests on !x86 architectures are much appreciated! > > > > > > This is current/arm64 on a Thinkpad W500 (dmesg below), Sorry, current/amd64, obviously. > running with the patch and option WITNESS and kern.witness.watch=2. > Three reversals are reported after boot: > > witness: lock order reversal: > 1st 0xfd8217a167c0 uobjlk (>vmobjlock) > 2nd 0x813e1b00 objmm (>mm.lock) > lock order ">mm.lock"(rwlock) -> ">vmobjlock"(rwlock) first seen > at: > #0 rw_enter+0x65 > #1 uvm_obj_wire+0x46 > #2 shmem_get_pages+0xaf > #3 __i915_gem_object_get_pages+0x9d > #4 i915_vma_pin_ww+0x49b > #5 i915_ggtt_pin+0x61 > #6 __intel_context_do_pin_ww+0x2d1 > #7 __intel_context_do_pin+0x4b > #8 intel_engines_init+0x4a1 > #9 intel_gt_init+0x133 > #10 i915_gem_init+0xa3 > #11 i915_driver_probe+0x75a > #12 inteldrm_attachhook+0x45 > #13 config_process_deferred_mountroot+0x6b > #14 main+0x743 > lock order ">vmobjlock"(rwlock) -> ">mm.lock"(rwlock) first seen > at: > #0 rw_enter+0x65 > #1 __i915_gem_object_get_pages+0x30 > #2 i915_gem_fault+0x1aa > #3 drm_fault+0x156 > #4 uvm_fault+0x179 > #5 upageflttrap+0x62 > #6 usertrap+0x18b > #7 recall_trap+0x8 > > witness: lock order reversal: > 1st 0xfd8218c24a98 uobjlk (>vmobjlock) > 2nd 0x80117070 vmlk (>mutex) > lock order data w2 -> w1 missing > lock order ">vmobjlock"(rwlock) -> ">mutex"(rwlock) first seen at: > #0 rw_enter+0x65 > #1 i915_vma_pin_ww+0x2f2 > #2 i915_gem_object_ggtt_pin_ww+0x222 > #3 i915_gem_fault+0x450 > #4 drm_fault+0x156 > #5 uvm_fault+0x179 > #6 upageflttrap+0x62 > #7 usertrap+0x18b > #8 recall_trap+0x8 > > witness: lock order reversal: > 1st 0xfd8217731670 uobjlk (>vmobjlock) > 2nd 0x814154c8 vmapg (>pages_mutex) > lock order data w2 -> w1 missing > lock order ">vmobjlock"(rwlock) -> ">pages_mutex"(rwlock) first > seen at: > #0 rw_enter+0x65 > #1 i915_vma_pin_ww+0x1c7 > #2 i915_gem_object_ggtt_pin_ww+0x222 > #3 i915_gem_fault+0x450 > #4 drm_fault+0x156 > #5 uvm_fault+0x179 > #6 upageflttrap+0x62 > #7 usertrap+0x18b > #8 recall_trap+0x8 > > > Jan > > OpenBSD 7.0-current (GENERIC.MP) #0: Sat Dec 4 10:02:46 CET 2021 > h...@w500.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8463781888 (8071MB) > avail mem = 8122720256 (7746MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries) > bios0: vendor LENOVO version "6FET79WW (3.09 )" date 10/02/2009 > bios0: LENOVO 40612JG > acpi0 at bios0: ACPI 3.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA > SSDT SSDT SSDT > acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) > EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) > HDEF(S4) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpiec0 at acpi0 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz, 2527.42 MHz, 06-17-06 > 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN > cpu0: 6MB 64b/line 16-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges > cpu0: apic clock running at 265MHz > cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz, 2527.01 MHz, 06-17-06 > 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN > cpu1: 6MB 64b/line 16-way L2 cache > cpu1: smt 0, core 1, package 0 > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped > acpimcfg0 at acpi0 > acpimcfg0: addr 0xe000, bus 0-63 > acpihpet0 at acpi0: 14318179 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus 1 (AGP_) > acpiprt2 at acpi0: bus 2 (EXP0) > acpiprt3 at acpi0: bus 3 (EXP1) > acpiprt4 at acpi0: bus -1 (EXP2) > acpiprt5 at acpi0: bus 5 (EXP3) > acpiprt6 at acpi0: bus 13 (EXP4) > acpiprt7 at acpi0: bus 21 (PCI1) > acpibtn0 at acpi0: LID_ > acpibtn1 at acpi0: SLPB > acpipci0 at
Re: Please test: UVM fault unlocking (aka vmobjlock)
On Dec 01 09:07:43, h...@stare.cz wrote: > > > > On 24/11/21(Wed) 11:16, Martin Pieuchot wrote: > > > > > Diff below unlock the bottom part of the UVM fault handler. I'm > > > > > interested in squashing the remaining bugs. Please test with your > > > > > usual > > > > > setup & report back. > > > > > > > > Thanks to all the testers, here's a new version that includes a bug fix. > > > > Tests on !x86 architectures are much appreciated! > > > This is current/arm64 on a Thinkpad W500 (dmesg below), running with the patch and option WITNESS and kern.witness.watch=2. Three reversals are reported after boot: witness: lock order reversal: 1st 0xfd8217a167c0 uobjlk (>vmobjlock) 2nd 0x813e1b00 objmm (>mm.lock) lock order ">mm.lock"(rwlock) -> ">vmobjlock"(rwlock) first seen at: #0 rw_enter+0x65 #1 uvm_obj_wire+0x46 #2 shmem_get_pages+0xaf #3 __i915_gem_object_get_pages+0x9d #4 i915_vma_pin_ww+0x49b #5 i915_ggtt_pin+0x61 #6 __intel_context_do_pin_ww+0x2d1 #7 __intel_context_do_pin+0x4b #8 intel_engines_init+0x4a1 #9 intel_gt_init+0x133 #10 i915_gem_init+0xa3 #11 i915_driver_probe+0x75a #12 inteldrm_attachhook+0x45 #13 config_process_deferred_mountroot+0x6b #14 main+0x743 lock order ">vmobjlock"(rwlock) -> ">mm.lock"(rwlock) first seen at: #0 rw_enter+0x65 #1 __i915_gem_object_get_pages+0x30 #2 i915_gem_fault+0x1aa #3 drm_fault+0x156 #4 uvm_fault+0x179 #5 upageflttrap+0x62 #6 usertrap+0x18b #7 recall_trap+0x8 witness: lock order reversal: 1st 0xfd8218c24a98 uobjlk (>vmobjlock) 2nd 0x80117070 vmlk (>mutex) lock order data w2 -> w1 missing lock order ">vmobjlock"(rwlock) -> ">mutex"(rwlock) first seen at: #0 rw_enter+0x65 #1 i915_vma_pin_ww+0x2f2 #2 i915_gem_object_ggtt_pin_ww+0x222 #3 i915_gem_fault+0x450 #4 drm_fault+0x156 #5 uvm_fault+0x179 #6 upageflttrap+0x62 #7 usertrap+0x18b #8 recall_trap+0x8 witness: lock order reversal: 1st 0xfd8217731670 uobjlk (>vmobjlock) 2nd 0x814154c8 vmapg (>pages_mutex) lock order data w2 -> w1 missing lock order ">vmobjlock"(rwlock) -> ">pages_mutex"(rwlock) first seen at: #0 rw_enter+0x65 #1 i915_vma_pin_ww+0x1c7 #2 i915_gem_object_ggtt_pin_ww+0x222 #3 i915_gem_fault+0x450 #4 drm_fault+0x156 #5 uvm_fault+0x179 #6 upageflttrap+0x62 #7 usertrap+0x18b #8 recall_trap+0x8 Jan OpenBSD 7.0-current (GENERIC.MP) #0: Sat Dec 4 10:02:46 CET 2021 h...@w500.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8463781888 (8071MB) avail mem = 8122720256 (7746MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries) bios0: vendor LENOVO version "6FET79WW (3.09 )" date 10/02/2009 bios0: LENOVO 40612JG acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz, 2527.42 MHz, 06-17-06 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 6MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 265MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz, 2527.01 MHz, 06-17-06 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus 5 (EXP3) acpiprt6 at acpi0: bus 13 (EXP4) acpiprt7 at acpi0: bus 21 (PCI1) acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 acpibat0 at acpi0: BAT0 model "COMPATIBLE" serial 1388 type LION oem "SANYO" acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0: version 1.0 "PNP0C14" at acpi0 not configured acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at
Re: Please test: UVM fault unlocking (aka vmobjlock)
> > > On 24/11/21(Wed) 11:16, Martin Pieuchot wrote: > > > > Diff below unlock the bottom part of the UVM fault handler. I'm > > > > interested in squashing the remaining bugs. Please test with your usual > > > > setup & report back. > > > > > > Thanks to all the testers, here's a new version that includes a bug fix. > > > Tests on !x86 architectures are much appreciated! > > This is current/arm64 on a RPI4 (dmesg below), running with the patch and option WITNESS and kern.witness.watch=2; it has been recompiling the kernel for about 12 hours without reporting anything. Jan OpenBSD 7.0-current (GENERIC.MP) #0: Tue Nov 30 16:06:48 CET 2021 h...@pi.stare.cz:/usr/src/sys/arch/arm64/compile/GENERIC.MP real mem = 8419885056 (8029MB) avail mem = 8059887616 (7686MB) random: good seed from bootblocks mainbus0 at root: Raspberry Pi 4 Model B Rev 1.4 cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3 cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu0: 1024KB 64b/line 16-way L2 cache cpu0: CRC32,ASID16 cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p3 cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu1: 1024KB 64b/line 16-way L2 cache cpu1: CRC32,ASID16 cpu2 at mainbus0 mpidr 2: ARM Cortex-A72 r0p3 cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu2: 1024KB 64b/line 16-way L2 cache cpu2: CRC32,ASID16 cpu3 at mainbus0 mpidr 3: ARM Cortex-A72 r0p3 cpu3: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu3: 1024KB 64b/line 16-way L2 cache cpu3: CRC32,ASID16 efi0 at mainbus0: UEFI 2.8 efi0: Das U-Boot rev 0x20210100 apm0 at mainbus0 "system" at mainbus0 not configured "axi" at mainbus0 not configured simplebus0 at mainbus0: "soc" bcmclock0 at simplebus0 bcmmbox0 at simplebus0 bcmgpio0 at simplebus0 bcmaux0 at simplebus0 ampintc0 at simplebus0 nirq 256, ncpu 4 ipi: 0, 1: "interrupt-controller" bcmtmon0 at simplebus0 bcmdmac0 at simplebus0: DMA0 DMA2 DMA4 DMA5 DMA6 DMA7 DMA8 DMA9 "timer" at simplebus0 not configured pluart0 at simplebus0: console "local_intc" at simplebus0 not configured bcmdog0 at simplebus0 bcmirng0 at simplebus0 "firmware" at simplebus0 not configured "power" at simplebus0 not configured "mailbox" at simplebus0 not configured sdhc0 at simplebus0 sdhc0: SDHC 3.0, 250 MHz base clock sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed "gpiomem" at simplebus0 not configured "fb" at simplebus0 not configured "vcsm" at simplebus0 not configured "clocks" at mainbus0 not configured "phy" at mainbus0 not configured "clk-27M" at mainbus0 not configured "clk-108M" at mainbus0 not configured simplebus1 at mainbus0: "emmc2bus" sdhc1 at simplebus1 sdhc1: SDHC 3.0, 100 MHz base clock sdmmc1 at sdhc1: 8-bit, sd high-speed, mmc high-speed, ddr52, dma "arm-pmu" at mainbus0 not configured agtimer0 at mainbus0: 54000 kHz simplebus2 at mainbus0: "scb" bcmpcie0 at simplebus2 pci0 at bcmpcie0 ppb0 at pci0 dev 0 function 0 "Broadcom BCM2711" rev 0x10 pci1 at ppb0 bus 1 xhci0 at pci1 dev 0 function 0 "VIA VL805 xHCI" rev 0x01: intx, xHCI 1.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "VIA xHCI root hub" rev 3.00/1.00 addr 1 bse0 at simplebus2: address dc:a6:32:e0:50:d3 brgphy0 at bse0 phy 1: BCM54210E 10/100/1000baseT PHY, rev. 2 "dma" at simplebus2 not configured "hevc-decoder" at simplebus2 not configured "rpivid-local-intc" at simplebus2 not configured "h264-decoder" at simplebus2 not configured "vp9-decoder" at simplebus2 not configured gpioleds0 at mainbus0: "led0", "led1" "sd_io_1v8_reg" at mainbus0 not configured "sd_vcc_reg" at mainbus0 not configured "fixedregulator_3v3" at mainbus0 not configured "fixedregulator_5v0" at mainbus0 not configured simplebus3 at mainbus0: "v3dbus" "bootloader" at mainbus0 not configured dt: 451 probes scsibus0 at sdmmc1: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: removable sd0: 30436MB, 512 bytes/sector, 62333952 sectors uhub1 at uhub0 port 1 configuration 1 interface 0 "VIA Labs USB2.0 Hub" rev 2.10/4.21 addr 2 bwfm0 at sdmmc0 function 1 manufacturer 0x02d0, product 0xa9a6 at sdmmc0 function 2 not configured manufacturer 0x02d0, product 0xa9a6 at sdmmc0 function 3 not configured vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets root on sd0a (d1a7e0233ab9545d.a) swap on sd0b dump on sd0b WARNING: CHECK AND RESET THE DATE! gpio0 at bcmgpio0: 58 pins bwfm0: address dc:a6:32:e0:50:d4
Re: Please test: UVM fault unlocking (aka vmobjlock)
On Nov 30 10:40:25, s...@spacehopper.org wrote: > On 2021/11/29 22:50, Martin Pieuchot wrote: > > On 24/11/21(Wed) 11:16, Martin Pieuchot wrote: > > > Diff below unlock the bottom part of the UVM fault handler. I'm > > > interested in squashing the remaining bugs. Please test with your usual > > > setup & report back. > > > > Thanks to all the testers, here's a new version that includes a bug fix. > > Tests on !x86 architectures are much appreciated! > This is current/amd64 with the patch on a PC (dmesg below); this is a work machine, running chrome and all, with kern.witness.watch=2 kern.witness.locktrace=0 Shortly after boot, dmesg says witness: lock order reversal: 1st 0xfd83bbfd8788 uobjlk (>vmobjlock) 2nd 0x80b74f00 objmm (>mm.lock) lock order ">mm.lock"(rwlock) -> ">vmobjlock"(rwlock) first seen at: #0 rw_enter+0x65 #1 uvm_obj_wire+0x46 #2 shmem_get_pages+0xaf #3 __i915_gem_object_get_pages+0x9d #4 i915_vma_pin_ww+0x49b #5 i915_ggtt_pin+0x61 #6 __intel_context_do_pin_ww+0x2d1 #7 __intel_context_do_pin+0x4b #8 intel_engines_init+0x4a1 #9 intel_gt_init+0x133 #10 i915_gem_init+0xa3 #11 i915_driver_probe+0x75a #12 inteldrm_attachhook+0x45 #13 config_process_deferred_mountroot+0x6b #14 main+0x743 lock order ">vmobjlock"(rwlock) -> ">mm.lock"(rwlock) first seen at: #0 rw_enter+0x65 #1 __i915_gem_object_get_pages+0x30 #2 i915_gem_fault+0x1aa #3 drm_fault+0x156 #4 uvm_fault+0x179 #5 upageflttrap+0x62 #6 usertrap+0x18b #7 recall_trap+0x8 While here, I notice that sysctl.witness.watch is documented in witness(4), but kern.witness.locktrace is not - is that intended? Jan OpenBSD 7.0-current (GENERIC.MP) #0: Tue Nov 30 15:37:35 CET 2021 h...@box.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17009606656 (16221MB) avail mem = 16347242496 (15589MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries) bios0: vendor Award Software International, Inc. version "F3" date 03/31/2011 bios0: Gigabyte Technology Co., Ltd. H67MA-USB3-B3 acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xf400, bus 0-63 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.72 MHz, 06-2a-07 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,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.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.31 MHz, 06-2a-07 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,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-2600 CPU @ 3.40GHz, 3392.31 MHz, 06-2a-07 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,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-2600 CPU @ 3.40GHz, 3392.31 MHz, 06-2a-07 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.30 MHz, 06-2a-07 cpu4:
Re: Stop building the kernel with -Wno-uninitialized on clang archs
> > Stop building the kernel with -Wno-uninitialized on clang archs.
> > This hides real problems like the recently fixed uninitialised memory
> > use in pf and igc.
> >
> > [-Wsometimes-uninitialized] /sys/arch/arm/arm/cpu.c:352:6: warning:
> > variable 'ci' is used uninitialized whenever 'if' condition is false
> > [-Wsometimes-uninitialized] /sys/arch/arm64/arm64/cpu.c:613:6: warning:
> > variable 'ci' is used uninitialized whenever 'if' condition is false
> > [-Wsometimes-uninitialized] /sys/arch/riscv64/riscv64/cpu.c:169:6: warning:
> > variable 'ci' is used uninitialized whenever 'if' condition is false
> > [-Wsometimes-uninitialized] /tmp/src/sys/arch/powerpc/powerpc/trap.c:467:7:
> > error: variable 'offset' is used uninitialized whenever 'if' condition is
> > false
> > [-Wuninitialized] /sys/arch/arm64/dev/acpiiort.c:174:28: warning: variable
> > 'rid' is uninitialized when used here
> >
> > cpu.c warnings occur with MULTIPROCESSOR not defined
> > powerpc trap.c occurs with DDB not defined
> >
> > patch to address these and remove the flag below
> > acpiiort part from patrick@
On each of the following platforms, the kernel builds fine for me
with this patch and the compilation shows none of the above warnings.
i386 (ALIX.1E)
amd64 (Thinkpad T400)
arm64 (Raspberry Pi 3 and 4)
armv7 (BeagleBone Black)
macppc (Mac Mini 7447A)
Jan
> > Index: arch/amd64/conf/Makefile.amd64
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/conf/Makefile.amd64,v
> > retrieving revision 1.121
> > diff -u -p -r1.121 Makefile.amd64
> > --- arch/amd64/conf/Makefile.amd64 12 Jul 2021 06:07:33 - 1.121
> > +++ arch/amd64/conf/Makefile.amd64 26 Nov 2021 04:54:10 -
> > @@ -48,7 +48,7 @@ INCLUDES= -nostdinc -I$S -I${.OBJDIR} -I
> > CPPFLAGS= ${INCLUDES} ${IDENT} ${PARAM} -D_KERNEL -MD -MP \
> > -DCONFIG_DRM_AMD_DC_DCN3_0
> > CWARNFLAGS=-Werror -Wall -Wimplicit-function-declaration \
> > - -Wno-uninitialized -Wno-pointer-sign \
> > + -Wno-pointer-sign \
> > -Wframe-larger-than=2047
> >
> > CMACHFLAGS=-mcmodel=kernel -mno-red-zone -mno-sse2 -mno-sse
> > -mno-3dnow \
> > Index: arch/arm/arm/cpu.c
> > ===
> > RCS file: /cvs/src/sys/arch/arm/arm/cpu.c,v
> > retrieving revision 1.55
> > diff -u -p -r1.55 cpu.c
> > --- arch/arm/arm/cpu.c 25 Mar 2021 04:12:00 - 1.55
> > +++ arch/arm/arm/cpu.c 23 Nov 2021 00:19:43 -
> > @@ -349,14 +349,11 @@ cpu_attach(struct device *parent, struct
> > __asm volatile("mrc p15, 0, %0, c0, c0, 5" : "=r"(mpidr));
> > KASSERT(faa->fa_nreg > 0);
> >
> > +#ifdef MULTIPROCESSOR
> > if (faa->fa_reg[0].addr == (mpidr & MPIDR_AFF)) {
> > ci = _info_primary;
> > -#ifdef MULTIPROCESSOR
> > ci->ci_flags |= CPUF_RUNNING | CPUF_PRESENT | CPUF_PRIMARY;
> > -#endif
> > - }
> > -#ifdef MULTIPROCESSOR
> > - else {
> > + } else {
> > ci = malloc(sizeof(*ci), M_DEVBUF, M_WAITOK | M_ZERO);
> > cpu_info[dev->dv_unit] = ci;
> > ci->ci_next = cpu_info_list->ci_next;
> > @@ -364,6 +361,8 @@ cpu_attach(struct device *parent, struct
> > ci->ci_flags |= CPUF_AP;
> > ncpus++;
> > }
> > +#else
> > + ci = _info_primary;
> > #endif
> >
> > ci->ci_dev = dev;
> > Index: arch/arm64/arm64/cpu.c
> > ===
> > RCS file: /cvs/src/sys/arch/arm64/arm64/cpu.c,v
> > retrieving revision 1.58
> > diff -u -p -r1.58 cpu.c
> > --- arch/arm64/arm64/cpu.c 23 Nov 2021 01:03:35 - 1.58
> > +++ arch/arm64/arm64/cpu.c 23 Nov 2021 01:28:26 -
> > @@ -604,20 +604,19 @@ cpu_attach(struct device *parent, struct
> > {
> > struct fdt_attach_args *faa = aux;
> > struct cpu_info *ci;
> > +#ifdef MULTIPROCESSOR
> > uint64_t mpidr = READ_SPECIALREG(mpidr_el1);
> > +#endif
> > uint64_t id_aa64mmfr1, sctlr;
> > uint32_t opp;
> >
> > KASSERT(faa->fa_nreg > 0);
> >
> > +#ifdef MULTIPROCESSOR
> > if (faa->fa_reg[0].addr == (mpidr & MPIDR_AFF)) {
> > ci = _info_primary;
> > -#ifdef MULTIPROCESSOR
> > ci->ci_flags |= CPUF_RUNNING | CPUF_PRESENT | CPUF_PRIMARY;
> > -#endif
> > - }
> > -#ifdef MULTIPROCESSOR
> > - else {
> > + } else {
> > ci = malloc(sizeof(*ci), M_DEVBUF, M_WAITOK | M_ZERO);
> > cpu_info[dev->dv_unit] = ci;
> > ci->ci_next = cpu_info_list->ci_next;
> > @@ -625,6 +624,8 @@ cpu_attach(struct device *parent, struct
> > ci->ci_flags |= CPUF_AP;
> > ncpus++;
> > }
> > +#else
> > + ci = _info_primary;
> > #endif
> >
> > ci->ci_dev = dev;
> > Index: arch/arm64/conf/Makefile.arm64
> > ===
> > RCS file:
Re: smtpd: LINE_MAX might not be enough for a response
On Nov 25 01:38:35, h...@stare.cz wrote:
> On Nov 24 14:47:48, j...@maudlin.dev wrote:
> >
> > Jan Stary writes:
> > > smtpd just failed to parse a SMTP response (below),
> > > saying 'line too long'.
> > >
> > > Looking at the source, this seems to be parse_smtp_response() in util.c,
> > > which errors out right away with
> > >
> > > if (len >= LINE_MAX)
> > > return "line too long";
> > >
> > > Apparently,
> > >
> > > /usr/include/sys/syslimits.h:#define LINE_MAX 2048
> > >
> > > is not enough, as shown by this line from
> > > (you guessed it) outlook.office365.com:
> >
> > > There is also
> > >
> > > smtp_session.c:#define SMTP_LINE_MAX 65535
> >
> > > Index: util.c
> > > ===
> > > RCS file: /cvs/src/usr.sbin/smtpd/util.c,v
> > > retrieving revision 1.154
> > > diff -u -p -r1.154 util.c
> > > --- util.c14 Jun 2021 17:58:16 - 1.154
> > > +++ util.c24 Nov 2021 17:59:14 -
> > > @@ -685,9 +685,6 @@ session_socket_error(int fd)
> > > const char *
> > > parse_smtp_response(char *line, size_t len, char **msg, int *cont)
> > > {
> > > - if (len >= LINE_MAX)
> > > - return "line too long";
> > > -
> > > if (len > 3) {
> > > if (msg)
> > > *msg = line + 4;
> >
> > [...]
> > At this point it seems to me that changing LINE_MAX to SMTP_LINE_MAX
> > would require a bit more digging, and I didn't look into any RFCs for
> > whether this is a standard value that outlook is ignoring.
https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1
https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1.5
I have no idea what the server is trying to say
with the long reply.
Jan
Re: smtpd: LINE_MAX might not be enough for a response
On Nov 24 14:47:48, j...@maudlin.dev wrote:
>
> Jan Stary writes:
> > smtpd just failed to parse a SMTP response (below),
> > saying 'line too long'.
> >
> > Looking at the source, this seems to be parse_smtp_response() in util.c,
> > which errors out right away with
> >
> > if (len >= LINE_MAX)
> > return "line too long";
> >
> > Apparently,
> >
> > /usr/include/sys/syslimits.h:#define LINE_MAX 2048
> >
> > is not enough, as shown by this line from
> > (you guessed it) outlook.office365.com:
>
> > There is also
> >
> > smtp_session.c:#define SMTP_LINE_MAX 65535
>
> > Index: util.c
> > ===
> > RCS file: /cvs/src/usr.sbin/smtpd/util.c,v
> > retrieving revision 1.154
> > diff -u -p -r1.154 util.c
> > --- util.c 14 Jun 2021 17:58:16 - 1.154
> > +++ util.c 24 Nov 2021 17:59:14 -
> > @@ -685,9 +685,6 @@ session_socket_error(int fd)
> > const char *
> > parse_smtp_response(char *line, size_t len, char **msg, int *cont)
> > {
> > - if (len >= LINE_MAX)
> > - return "line too long";
> > -
> > if (len > 3) {
> > if (msg)
> > *msg = line + 4;
>
> We really shouldn't simply remove this check.
Absolutely, that was just to see what the long line was.
Thanks for digging in.
Jan
> In this case parse_smtp_response gets called in two places:
>
> *
> https://github.com/openbsd/src/blob/ceeebefe3564938ff6ba87e7f465f6c35aeb8b03/usr.sbin/smtpd/bounce.c#L726
> *
> https://github.com/openbsd/src/blob/ceeebefe3564938ff6ba87e7f465f6c35aeb8b03/usr.sbin/smtpd/mta_session.c#L1252
>
> I think the correct thing to do in this case is examine how 'char *line'
> is allocated, which should help to determine if SMTP_LINE_MAX would in
> fact be a suitable replacement for LINE_MAX.
>
> Digging a little further, it appears that in usr.sbin/smtpd/bounce.c:711
> we see that LINE_MAX is used for comparison before later calling
> parse_smtp_response with char *line and size_t len:
>
> case IO_DATAIN:
> nextline:
> line = io_getline(s->io, );
> if (line == NULL && io_datalen(s->io) >= LINE_MAX) {
> bounce_status(s, "Input too long");
> bounce_free(s);
> return;
> }
>
> At this point it seems to me that changing LINE_MAX to SMTP_LINE_MAX
> would require a bit more digging, and I didn't look into any RFCs for
> whether this is a standard value that outlook is ignoring.
>
>
smtpd: LINE_MAX might not be enough for a response
This is current/amd64 on a PC.
smtpd just failed to parse a SMTP response (below),
saying 'line too long'.
Looking at the source, this seems to be parse_smtp_response() in util.c,
which errors out right away with
if (len >= LINE_MAX)
return "line too long";
Apparently,
/usr/include/sys/syslimits.h:#define LINE_MAX 2048
is not enough, as shown by this line from
(you guessed it) outlook.office365.com:
h...@stare.cz: 554 5.2.252 SendAsDenied; stary...@cvut.cz not allowed to send
as h...@biblio.stare.cz;
STOREDRV.Submission.Exception:SendAsDeniedException.MapiExceptionSendAsDenied;
Failed to process message due to a permanent exception with message Cannot
submit message. 0.35250:CF3A, 1.36674:0100, 1.61250:,
1.45378:0200, 1.44866:, 1.36674:7A00, 1.61250:,
1.45378:0500, 1.44866:0014, 1.36674:0A00, 1.61250:,
1.45378:1600, 1.44866:AE1A, 1.36674:0E00, 1.61250:,
1.45378:C71A, 1.44866:E000, 16.55847:EE0C,
17.43559:30020100,
20.52176:140F69921A001F001432, 20.50032:140F69928A1770200201E265,
0.35180:40001E32, 255.23226:2100, 255.27962:7A00, 255.27962:0A00,
255.27962:0E00, 255.31418:03000136, 0.35250:0300A531, 1.36674:0A00,
1.61250:, 1.45378:0200, 1.44866:1800, 1.36674:3200,
1.61250:, 1.45378:1D00, 1.44866:0100, 16.55847:8400,
17.43559:8803,
20.52176:140F69921A0070200A001380, 20.50032:140F69928A1710106F00,
0.35180:03000B67, 255.23226:0A00CD30, 255.27962:0A00, 255.27962:3200,
255.17082:DC04, 0.27745:7900, 4.21921:DC04, 255.27962:FA00,
255.1494:7E00, 0.38698:05000780, 1.41134:4600, 0.37692:8600,
0.37948:8600, 5.33852:534D5450,
7.36354:010001098600, 4.56248:DC04,
7.40748:0100010B8600, 7.57132:8600,
1.63016:3200, 4.39640:DC04,
8.45434:9A6929EA0096114FBBA64268B1990A848600, 1.46798:0400,
5.10786:31352E32302E343731332E3032363A414D39505230364D42383138303A65613539613834342D653163302D343234332D613934632D3263343563353536646533383A34353639323400DA10100300,
7.51330:8C34EA6973AFD9080700, 0.39570:0300, 1.55954:0A00,
0.49266:0200, 1.33010:0A00, 2.54258:, 0.40002:7A00,
1.56562:, 1.64146:3200, 1.33010:3200, 2.54258:DC04,
255.1750:0300
Yes, this is exactly 2048 bytes of an unfinished line.
(The actual error is my misconfiguration,
but that's beside the point here.)
There is also
smtp_session.c:#define SMTP_LINE_MAX 65535
which I guess would be the right replacement, but as this is
is only defined in one C file and I don't know the code base,
I'll leave that to someone else.
Naively, I am just removing the len >= condition,
which is probably not correct; I don't see where the
parsing function needs that, but perhaps this limitation
is relied upon elsewhere.
Jan
Index: util.c
===
RCS file: /cvs/src/usr.sbin/smtpd/util.c,v
retrieving revision 1.154
diff -u -p -r1.154 util.c
--- util.c 14 Jun 2021 17:58:16 - 1.154
+++ util.c 24 Nov 2021 17:59:14 -
@@ -685,9 +685,6 @@ session_socket_error(int fd)
const char *
parse_smtp_response(char *line, size_t len, char **msg, int *cont)
{
- if (len >= LINE_MAX)
- return "line too long";
-
if (len > 3) {
if (msg)
*msg = line + 4;
Re: extern optind etc already declared
On Nov 23 00:10:08, h...@stare.cz wrote:
> extern optind and friends are already declared
> once unistd.h is included, to these can be removed.
This is the same for usr.bin except ssh.
Jan
Index: usr.bin//env/env.c
===
RCS file: /cvs/src/usr.bin/env/env.c,v
retrieving revision 1.17
diff -u -p -r1.17 env.c
--- usr.bin//env/env.c 28 Oct 2016 07:22:59 - 1.17
+++ usr.bin//env/env.c 22 Nov 2021 23:27:39 -
@@ -42,7 +42,6 @@ int
main(int argc, char *argv[])
{
extern char **environ;
- extern int optind;
char **ep, *p;
int ch;
Index: usr.bin//finger/finger.c
===
RCS file: /cvs/src/usr.bin/finger/finger.c,v
retrieving revision 1.27
diff -u -p -r1.27 finger.c
--- usr.bin//finger/finger.c26 Apr 2018 12:42:51 - 1.27
+++ usr.bin//finger/finger.c22 Nov 2021 23:27:39 -
@@ -76,7 +76,6 @@ PERSON *phead, *ptail;
int
main(int argc, char *argv[])
{
- extern int optind;
extern char *__progname;
int ch;
char domain[HOST_NAME_MAX+1];
Index: usr.bin//ftp/cmds.c
===
RCS file: /cvs/src/usr.bin/ftp/cmds.c,v
retrieving revision 1.84
diff -u -p -r1.84 cmds.c
--- usr.bin//ftp/cmds.c 18 Nov 2019 04:37:35 - 1.84
+++ usr.bin//ftp/cmds.c 22 Nov 2021 23:27:39 -
@@ -217,7 +217,6 @@ usage:
void
mput(int argc, char *argv[])
{
- extern int optind, optreset;
int ch, i, restartit = 0;
sig_t oldintr;
char *cmd, *tp, *xargv[] = { argv[0], NULL, NULL };
Index: usr.bin//ftp/small.c
===
RCS file: /cvs/src/usr.bin/ftp/small.c,v
retrieving revision 1.12
diff -u -p -r1.12 small.c
--- usr.bin//ftp/small.c18 Nov 2019 04:37:35 - 1.12
+++ usr.bin//ftp/small.c22 Nov 2021 23:27:39 -
@@ -326,13 +326,11 @@ mabort(int signo)
void
mget(int argc, char *argv[])
{
- extern int optind, optreset;
sig_t oldintr;
int xargc = 2;
char *cp, localcwd[PATH_MAX], *xargv[] = { argv[0], NULL, NULL };
static int restartit = 0;
#ifndef SMALL
- extern char *optarg;
const char *errstr;
int ch, i = 1;
char type = 0, *dummyargv[] = { argv[0], ".", NULL };
Index: usr.bin//getopt/getopt.c
===
RCS file: /cvs/src/usr.bin/getopt/getopt.c,v
retrieving revision 1.10
diff -u -p -r1.10 getopt.c
--- usr.bin//getopt/getopt.c9 Oct 2015 01:37:07 - 1.10
+++ usr.bin//getopt/getopt.c22 Nov 2021 23:27:39 -
@@ -13,8 +13,6 @@
int
main(int argc, char *argv[])
{
- extern int optind;
- extern char *optarg;
int c;
int status = 0;
Index: usr.bin//locate/code/locate.code.c
===
RCS file: /cvs/src/usr.bin/locate/code/locate.code.c,v
retrieving revision 1.21
diff -u -p -r1.21 locate.code.c
--- usr.bin//locate/code/locate.code.c 17 Jan 2019 06:15:44 - 1.21
+++ usr.bin//locate/code/locate.code.c 22 Nov 2021 23:27:39 -
@@ -106,8 +106,6 @@ int bgindex(char *);
void usage(void);
-extern int optind;
-extern int optopt;
int
main(int argc, char *argv[])
Index: usr.bin//mklocale/yacc.y
===
RCS file: /cvs/src/usr.bin/mklocale/yacc.y,v
retrieving revision 1.10
diff -u -p -r1.10 yacc.y
--- usr.bin//mklocale/yacc.y8 May 2016 15:25:44 - 1.10
+++ usr.bin//mklocale/yacc.y22 Nov 2021 23:27:40 -
@@ -250,9 +250,6 @@ main(int ac, char *av[])
{
int x;
-extern char *optarg;
-extern int optind;
-
if (pledge("stdio rpath wpath cpath", NULL) == -1) {
perror("pledge");
exit(1);
Index: usr.bin//netstat/main.c
===
RCS file: /cvs/src/usr.bin/netstat/main.c,v
retrieving revision 1.121
diff -u -p -r1.121 main.c
--- usr.bin//netstat/main.c 26 Jan 2021 18:22:45 - 1.121
+++ usr.bin//netstat/main.c 22 Nov 2021 23:27:40 -
@@ -138,8 +138,6 @@ int af; /* address famil
int
main(int argc, char *argv[])
{
- extern char *optarg;
- extern int optind;
const char *errstr;
struct protox *tp = NULL; /* for printing cblocks & stats */
int ch;
Index: usr.bin//nfsstat/nfsstat.c
===
RCS file: /cvs/src/usr.bin/nfsstat/nfsstat.c,v
retrieving revision 1.36
diff -u -p -r1.36 nfsstat.c
--- usr.bin//nfsstat/nfsstat.c 27 Aug 2016 04:07:42 - 1.36
+++ usr.bin//nfsstat/nfsstat.c 22 Nov 2021 23:27:40 -
@@ -78,8 +78,6 @@ int
main(int argc, char *argv[])
{
u_int interval, display = SHOW_ALL;
- extern int
extern optind etc already declared in unistd.h
extern optind and friends are already declared
once unistd.h is included, to these can be removed.
This is the usr.sbin part; I am not touching nsd
and other third-party stuff.
Jan
Index: usr.sbin//yppoll/yppoll.c
===
RCS file: /cvs/src/usr.sbin/yppoll/yppoll.c,v
retrieving revision 1.15
diff -u -p -r1.15 yppoll.c
--- usr.sbin//yppoll/yppoll.c 16 Jan 2015 06:40:22 - 1.15
+++ usr.sbin//yppoll/yppoll.c 22 Nov 2021 23:06:04 -
@@ -126,8 +126,6 @@ int
main(int argc, char *argv[])
{
char *domainname, *hostname = NULL, *inmap, *master;
- extern char *optarg;
- extern int optind;
int order, c, r;
time_t torder;
Index: usr.sbin//ypserv/makedbm/makedbm.c
===
RCS file: /cvs/src/usr.sbin/ypserv/makedbm/makedbm.c,v
retrieving revision 1.33
diff -u -p -r1.33 makedbm.c
--- usr.sbin//ypserv/makedbm/makedbm.c 9 Feb 2015 23:00:15 - 1.33
+++ usr.sbin//ypserv/makedbm/makedbm.c 22 Nov 2021 23:06:04 -
@@ -302,9 +302,6 @@ main(int argc, char *argv[])
char*infile, *outfile;
int ch;
- extern int optind;
- extern char *optarg;
-
yp_input_file = yp_output_file = NULL;
yp_master_name = yp_domain_name = NULL;
aflag = uflag = bflag = lflag = sflag = Uflag = 0;
Index: usr.sbin//ypserv/yppush/yppush.c
===
RCS file: /cvs/src/usr.sbin/ypserv/yppush/yppush.c,v
retrieving revision 1.31
diff -u -p -r1.31 yppush.c
--- usr.sbin//ypserv/yppush/yppush.c16 Jan 2015 06:40:23 - 1.31
+++ usr.sbin//ypserv/yppush/yppush.c22 Nov 2021 23:06:04 -
@@ -216,8 +216,6 @@ int
main(int argc, char *argv[])
{
struct ypall_callback ypcb;
- extern char *optarg;
- extern int optind;
char*domain, *map, *hostname;
int c, r, i;
char *ypmap = "ypservers";
Index: usr.sbin//ypset/ypset.c
===
RCS file: /cvs/src/usr.sbin/ypset/ypset.c,v
retrieving revision 1.20
diff -u -p -r1.20 ypset.c
--- usr.sbin//ypset/ypset.c 16 Jan 2015 06:40:23 - 1.20
+++ usr.sbin//ypset/ypset.c 22 Nov 2021 23:06:04 -
@@ -106,8 +106,6 @@ main(int argc, char *argv[])
{
struct sockaddr_in sin;
struct hostent *hent;
- extern char *optarg;
- extern int optind;
char *domainname;
int c;
Re: New hw.perfpolicy behavior
On Nov 10 00:21:59, h...@stare.cz wrote: > On Nov 02 12:30:56, dera...@openbsd.org wrote: > > Paul de Weerd wrote: > > > > > A recent commit by Theo changed the hw.perfpolicy behavior to always > > > run at full speed when AC power is on. This means that my workstation > > > (and servers, once I upgrade them) now consumes significantly more > > > power, even though they usually idle. > > > > Did you measure how much more power? > > > > You must measure, to make such a claim. > > > > Your OptiPlex 9020 is probably a modern i5/i7, which probably contains > > C states similar to this: > > > > acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS > > > > Which means when the idle loop calls the "mwait" instruction, the cpu > > will 'instantly' slow down to a lower clock and make other power use > > reductions, until an interrupt happens and requires labour again. > > > > Most modern cpus dynamically downscale in such way, which mostly > > obliterates the requirement to manually control things, or even handle > > it in a slow-paced data-weak way in the scheduler. > > Measuring on this PC running current/amd64 (dmesg below), > with a Sep 26 snapshot and the latest snapshot. > > As a naive test, I am measuring the power consumption > of compiling the kernel (is that too small?). > > The numbers are mostly the same on both of these systems, > with each of apmd with apm -A, -H, -L respectively, > or without running apmd at all. For comparison, the numbers are not the same on a Thinkpad T400 (dmesg below) running on battery. acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS apm -A (hw.setperf=0 hw.perfpolicy=auto) took 14m23.20s to compile the kernel, consuming 28.93 - 21.28 = 7.65 Wh (by hw.sensors.acpibat0.watthour3) apm -H (hw.setperf=100 hw.perfpolicy=manual hw.cpuspeed=2267) took 14m27.63s, consuming 19.25 - 11.04 = 8.21 Wh apm -L (hw.setperf=0 hw.perfpolicy=manual hw.cpuspeed=800) took 37m18.40s, consuming 22.25 - 10.02 = 12.23 Wh So at last here, apm -A is better than apm -H, but apm -L is clearly the worst. Jan OpenBSD 7.0-current (GENERIC.MP) #104: Thu Nov 18 09:10:05 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8461684736 (8069MB) avail mem = 8189267968 (7809MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries) bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012 bios0: LENOVO 64741EG acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 2261.33 MHz, 06-17-06 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 3MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 266MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 2261.01 MHz, 06-17-06 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 3MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus 5 (EXP3) acpiprt6 at acpi0: bus 13 (EXP4) acpiprt7 at acpi0: bus 21 (PCI1) acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 tpm0 at acpi0 TPM_ 1.2 (TIS) addr 0xfed4/0x5000, device 0x10208086 rev 0x6 acpibat0 at acpi0: BAT0 model "92P1137" serial57 type LION oem "SANYO" acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0: version 1.0 "PNP0C14" at acpi0 not configured acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0:
Re: cwm: fix invalid KeyCode in configuration
On Nov 19 00:01:04, stef...@sdaoden.eu wrote:
> Jan Stary wrote in
> :
> |On Nov 18 20:13:03, h...@stare.cz wrote:
> |> On Nov 16 21:33:31, hen...@camandro.org wrote:
> |>> I've tried to setup a line like:
> |>> bind-key XF86MonBrightnessDown ""
> |>> in my .cwmrc and the result was that no key event was sent to my \
> |>> windows.
> |>
> |> Please excuse my X ignorance, but shouldn't XF86MonBrightnessDown
> |> be catched by the X server (to take the brightness down),
> |> as opposed to passing it on to cwm?
> |
> |Or even sooner? For example, xev(1) does not report anything
> |when I press [Fn]+[LightsDown] on my Thinkpad T400 running cwm.
>
> Just tell him that his keyboard does not generate the event,
I am not sure what you mean by that,
but pressing those keys does dim my monitor.
That makes me thinks the event is "catched"
("consumed", "processed" - I don't know the terminology)
before it reaches the xev application (running in cwm).
And that is (I speculate) why the OP also doesn't see the key processed
in his window manager - because it never even reaches the window manager.
Jan
Re: cwm: fix invalid KeyCode in configuration
On Nov 18 20:13:03, h...@stare.cz wrote: > On Nov 16 21:33:31, hen...@camandro.org wrote: > > I've tried to setup a line like: > > bind-key XF86MonBrightnessDown "" > > in my .cwmrc and the result was that no key event was sent to my windows. > > Please excuse my X ignorance, but shouldn't XF86MonBrightnessDown > be catched by the X server (to take the brightness down), > as opposed to passing it on to cwm? Or even sooner? For example, xev(1) does not report anything when I press [Fn]+[LightsDown] on my Thinkpad T400 running cwm.
Re: cwm: fix invalid KeyCode in configuration
On Nov 16 21:33:31, hen...@camandro.org wrote: > I've tried to setup a line like: > bind-key XF86MonBrightnessDown "" > in my .cwmrc and the result was that no key event was sent to my windows. Please excuse my X ignorance, but shouldn't XF86MonBrightnessDown be catched by the X server (to take the brightness down), as opposed to passing it on to cwm?
Re: Fix vi(1) recovery - new method
On Oct 09 20:26:13, tro...@kagu-tsuchi.com wrote: > This is a new attempt at fixing vi(1) recovery by actually writing > to the recovery file. Previously I restored the SIGALRM method that > was deleted in the 90's but wondered if that was still the best way > to handle this. Checking and syncing to the recovery every 2 minutes > seems arbitrary and overly cautious. > > This attempt takes it to the other direction. I'm writing each > change to the recovery file immediately after the in-memory database > is modified. Though, I can see that this might have a noticeable > impact on slower file systems. This recovers close to what the file was at the KILL moment. The writing impact is still bareable e.g. on a SD card in a Raspberry (that is to say, slow, but not much slower than without this). Thank you! Jan
Re: locale in expr(1)
On Nov 15 17:58:38, schwa...@usta.de wrote:
> Hi Marc,
>
> Marc Espie wrote on Mon, Nov 15, 2021 at 05:06:23PM +0100:
> > On Mon, Nov 15, 2021 at 03:43:47PM +0100, Jan Stary wrote:
> >> On Nov 10 18:46:08, h...@stare.cz wrote:
> >>> On Nov 10 18:15:44, h...@stare.cz wrote:
>
> >>>> expr(1) says
> >>>>
> >>>> expr1 {=, >, >=, <, <=, !=} expr2
> >>>>
> >>>> Returns the results of integer comparison if both arguments
> >>>> are decimal integers; otherwise, returns the results of
> >>>> string comparison using the locale-specific collation
>
> Yikes. Yes, that is true in general. Then again, the OpenBSD
> C library intentionally supports only one single collation sequence:
> POSIX.
>
> >>>> sequence. The result of each comparison is 1 if the specified
> >>>> relation is true, or 0 if the relation is false.
> >>>>
> >>>> Looking at expr.c, it boils down to strcoll(), which ignores the locale.
> >>>> So the statement is technically true, but there isn't really any
> >>>> "locale-specific collation sequence".
> >>>>
> >>>> Would it be simpler to leave the mention of locale completely out?
>
> Yes, probably, and then add a CAVEATS section warning that on other
> operating systems, the collation order may vary depending on the
> LC_COLLATE environment variable.
I left that out on purpose and linked to strcoll(3) instead, because
(a) that's what the code actually does and
(b) strcoll(3) mentions the LC_COLLATE thing.
> >>>> Or state something similar to what sort(1) or strcoll(3) and other
> >>>> string-comparing routines say?
>
> >>> For example,
> >>>
> >>>$ expr č '<' d
> >>>0
> >>>
> >>> Which locale-specific collation sequence determined that?
> >>> Byte by byte, it's
> >>>
> >>>c48d U+00010d č LATIN SMALL LETTER C HACEK
> >>>64U+64 d LATIN SMALL LETTER D
> >>>
> >>> and I don't think there is anything more to it.
>
> Yes.
>
> >>> (Although in the Czech alphabet, č comes just before d.)
>
> Fair enough, but adding knowledge about that to the C library
> would be quite insane.
Cthulhu forbid; all I meant was it boils down to 0xc4 > 0x64 anyway,
so why talk about a "locale-specific collation sequence" at all.
I believe the manpage would be better off without it.
Jan
Re: locale in expr(1)
Here's a try (see below);
one sentence one line while here.
I would also replace 'results' with 'result' everywhere,
but I am not a native speaker.
Jan
On Nov 10 18:46:08, h...@stare.cz wrote:
> On Nov 10 18:15:44, h...@stare.cz wrote:
> > expr(1) says
> >
> > expr1 {=, >, >=, <, <=, !=} expr2
> >
> > Returns the results of integer comparison if both arguments
> > are decimal integers; otherwise, returns the results of
> > string comparison using the locale-specific collation
> > sequence. The result of each comparison is 1 if the specified
> > relation is true, or 0 if the relation is false.
> >
> > Looking at expr.c, it boils down to strcoll(), which ignores the locale.
> > So the statement is technically true, but there isn't really any
> > "locale-specific collation sequence".
> >
> > Would it be simpler to leave the mention of locale completely out?
> > Or state something similar to what sort(1) or strcoll(3) and other
> > string-comparing routines say?
>
> For example,
>
>$ expr č '<' d
>0
>
> Which locale-specific collation sequence determined that?
> Byte by byte, it's
>
>c48d U+00010d č LATIN SMALL LETTER C HACEK
>64U+64 d LATIN SMALL LETTER D
>
> and I don't think there is anything more to it.
> (Although in the Czech alphabet, č comes just before d.)
>
> Jan
Index: expr.1
===
RCS file: /cvs/src/bin/expr/expr.1,v
retrieving revision 1.24
diff -u -p -r1.24 expr.1
--- expr.1 16 Aug 2017 20:10:58 - 1.24
+++ expr.1 15 Nov 2021 14:40:33 -
@@ -39,9 +39,10 @@ Returns the evaluation of
if neither expression evaluates to an empty string or zero;
otherwise, returns zero.
.It Ar expr1 Li "{=, >, >=, <, <=, !=}" Ar expr2
-Returns the results of integer comparison if both arguments are
-decimal integers; otherwise, returns the results of string comparison
-using the locale-specific collation sequence.
+Returns the results of integer comparison
+if both arguments are decimal integers;
+otherwise, returns the results of string comparison using
+.Xr strcoll 3 .
The result of each comparison is 1 if the specified relation is true,
or 0 if the relation is false.
.It Ar expr1 Li "{+, -}" Ar expr2
>
Re: extern int optind etc already declared in unistd.h
(Does anyone want to commit this please?)
On Nov 10 09:31:57, mill...@openbsd.org wrote:
> On Wed, 10 Nov 2021 17:29:55 +0100, Jan Stary wrote:
>
> > With included, there is no need
> > to declare extern int optind and friends again.
>
> Right, most of this is old code that dates from before those were
> declared in unistd.h. OK millert@
On Nov 10 09:34:43, dera...@openbsd.org wrote:
> Yes
>
> Jan Stary wrote:
>
> > With included, there is no need
> > to declare extern int optind and friends again.
> >
> > Jan
> >
> > Index: usr.sbin/amd/amd/get_args.c
> > ===
> > RCS file: /cvs/src/usr.sbin/amd/amd/get_args.c,v
> > retrieving revision 1.15
> > diff -u -p -r1.15 get_args.c
> > --- usr.sbin/amd/amd/get_args.c 21 Oct 2021 10:55:56 - 1.15
> > +++ usr.sbin/amd/amd/get_args.c 10 Nov 2021 16:27:26 -
> > @@ -44,9 +44,6 @@
> > #include
> > #include
> >
> > -extern int optind;
> > -extern char *optarg;
> > -
> > #if defined(DEBUG) && defined(PARANOID)
> > char **gargv;
> > #endif /* defined(DEBUG) && defined(PARANOID) */
> > Index: usr.sbin/amd/amq/amq.c
> > ===
> > RCS file: /cvs/src/usr.sbin/amd/amq/amq.c,v
> > retrieving revision 1.21
> > diff -u -p -r1.21 amq.c
> > --- usr.sbin/amd/amq/amq.c 21 Jan 2017 08:33:51 - 1.21
> > +++ usr.sbin/amd/amq/amq.c 10 Nov 2021 16:27:26 -
> > @@ -59,9 +59,6 @@ static char *xlog_optstr;
> > static char localhost[] = "localhost";
> > static char *def_server = localhost;
> >
> > -extern int optind;
> > -extern char *optarg;
> > -
> > static struct timeval tmo = { 10, 0 };
> > #defineTIMEOUT tmo
> >
> > Index: usr.sbin/crunchgen/crunchgen.c
> > ===
> > RCS file: /cvs/src/usr.sbin/crunchgen/crunchgen.c,v
> > retrieving revision 1.24
> > diff -u -p -r1.24 crunchgen.c
> > --- usr.sbin/crunchgen/crunchgen.c 24 Oct 2021 21:24:18 - 1.24
> > +++ usr.sbin/crunchgen/crunchgen.c 10 Nov 2021 16:27:26 -
> > @@ -117,8 +117,6 @@ main(int argc, char *argv[])
> > {
> > char *p;
> > int optc;
> > - extern int optind;
> > - extern char*optarg;
> >
> > if (pledge("stdio rpath wpath cpath proc exec", NULL) == -1) {
> > perror("pledge");
> > Index: usr.sbin/mtree/mtree.c
> > ===
> > RCS file: /cvs/src/usr.sbin/mtree/mtree.c,v
> > retrieving revision 1.26
> > diff -u -p -r1.26 mtree.c
> > --- usr.sbin/mtree/mtree.c 16 Sep 2018 12:43:40 - 1.26
> > +++ usr.sbin/mtree/mtree.c 10 Nov 2021 16:27:26 -
> > @@ -55,8 +55,6 @@ static void usage(void);
> > int
> > main(int argc, char *argv[])
> > {
> > - extern int optind;
> > - extern char *optarg;
> > int ch;
> > char *dir, *p;
> > int status;
> > Index: usr.sbin/npppctl/npppctl.c
> > ===
> > RCS file: /cvs/src/usr.sbin/npppctl/npppctl.c,v
> > retrieving revision 1.9
> > diff -u -p -r1.9 npppctl.c
> > --- usr.sbin/npppctl/npppctl.c 28 Jun 2019 13:32:49 - 1.9
> > +++ usr.sbin/npppctl/npppctl.c 10 Nov 2021 16:27:26 -
> > @@ -80,8 +80,6 @@ main(int argc, char *argv[])
> > struct parse_result *result;
> > struct sockaddr_un sun;
> > const char *npppd_ctlpath = NPPPD_SOCKET;
> > - extern int optind;
> > - extern char *optarg;
> >
> > while ((ch = getopt(argc, argv, "ns:")) != -1)
> > switch (ch) {
> > Index: usr.sbin/npppd/npppd/npppd.c
> > ===
> > RCS file: /cvs/src/usr.sbin/npppd/npppd/npppd.c,v
> > retrieving revision 1.51
> > diff -u -p -r1.51 npppd.c
> > --- usr.sbin/npppd/npppd/npppd.c29 Mar 2021 03:54:39 - 1.51
> > +++ usr.sbin/npppd/npppd/npppd.c10 Nov 2021 16:27:26 -
> > @@ -136,7 +136,6 @@ int
> > main(int argc, char *argv[])
> > {
> > intch, stop_by_error, runasdaemon = 1, nflag = 0;
> > - extern char *optarg;
> > const char*npppd_conf0 = DEFAULT_NPPPD_
Re: obsolete()
On Nov 10 19:10:59, h...@stare.cz wrote: > https://marc.info/?l=openbsd-tech=163389736000516=2 > > Not related to the original head -5 -n 6 discussion, > but a copy of obsolete() exists in usr.bin/join/ > (and seems to be the only instance, AFAIG). Ah, that one seems to be specific to the obsolete options of join(1); sorry for the noise. Jan
obsolete()
https://marc.info/?l=openbsd-tech=163389736000516=2 Not related to the original head -5 -n 6 discussion, but a copy of obsolete() exists in usr.bin/join/ (and seems to be the only instance, AFAIG). Jan
Re: locale in expr(1)
On Nov 10 18:15:44, h...@stare.cz wrote:
> expr(1) says
>
> expr1 {=, >, >=, <, <=, !=} expr2
>
> Returns the results of integer comparison if both arguments
> are decimal integers; otherwise, returns the results of
> string comparison using the locale-specific collation
> sequence. The result of each comparison is 1 if the specified
> relation is true, or 0 if the relation is false.
>
> Looking at expr.c, it boils down to strcoll(), which ignores the locale.
> So the statement is technically true, but there isn't really any
> "locale-specific collation sequence".
>
> Would it be simpler to leave the mention of locale completely out?
> Or state something similar to what sort(1) or strcoll(3) and other
> string-comparing routines say?
For example,
$ expr č '<' d
0
Which locale-specific collation sequence determined that?
Byte by byte, it's
c48d U+00010d č LATIN SMALL LETTER C HACEK
64U+64 d LATIN SMALL LETTER D
and I don't think there is anything more to it.
(Although in the Czech alphabet, č comes just before d.)
Jan
locale in expr(1)
expr(1) says
expr1 {=, >, >=, <, <=, !=} expr2
Returns the results of integer comparison if both arguments
are decimal integers; otherwise, returns the results of
string comparison using the locale-specific collation
sequence. The result of each comparison is 1 if the specified
relation is true, or 0 if the relation is false.
Looking at expr.c, it boils down to strcoll(), which ignores the locale.
So the statement is technically true, but there isn't really any
"locale-specific collation sequence".
Would it be simpler to leave the mention of locale completely out?
Or state something similar to what sort(1) or strcoll(3) and other
string-comparing routines say?
Jan
extern int optind etc already declared in unistd.h
With included, there is no need
to declare extern int optind and friends again.
Jan
Index: usr.sbin/amd/amd/get_args.c
===
RCS file: /cvs/src/usr.sbin/amd/amd/get_args.c,v
retrieving revision 1.15
diff -u -p -r1.15 get_args.c
--- usr.sbin/amd/amd/get_args.c 21 Oct 2021 10:55:56 - 1.15
+++ usr.sbin/amd/amd/get_args.c 10 Nov 2021 16:27:26 -
@@ -44,9 +44,6 @@
#include
#include
-extern int optind;
-extern char *optarg;
-
#if defined(DEBUG) && defined(PARANOID)
char **gargv;
#endif /* defined(DEBUG) && defined(PARANOID) */
Index: usr.sbin/amd/amq/amq.c
===
RCS file: /cvs/src/usr.sbin/amd/amq/amq.c,v
retrieving revision 1.21
diff -u -p -r1.21 amq.c
--- usr.sbin/amd/amq/amq.c 21 Jan 2017 08:33:51 - 1.21
+++ usr.sbin/amd/amq/amq.c 10 Nov 2021 16:27:26 -
@@ -59,9 +59,6 @@ static char *xlog_optstr;
static char localhost[] = "localhost";
static char *def_server = localhost;
-extern int optind;
-extern char *optarg;
-
static struct timeval tmo = { 10, 0 };
#defineTIMEOUT tmo
Index: usr.sbin/crunchgen/crunchgen.c
===
RCS file: /cvs/src/usr.sbin/crunchgen/crunchgen.c,v
retrieving revision 1.24
diff -u -p -r1.24 crunchgen.c
--- usr.sbin/crunchgen/crunchgen.c 24 Oct 2021 21:24:18 - 1.24
+++ usr.sbin/crunchgen/crunchgen.c 10 Nov 2021 16:27:26 -
@@ -117,8 +117,6 @@ main(int argc, char *argv[])
{
char *p;
int optc;
- extern int optind;
- extern char*optarg;
if (pledge("stdio rpath wpath cpath proc exec", NULL) == -1) {
perror("pledge");
Index: usr.sbin/mtree/mtree.c
===
RCS file: /cvs/src/usr.sbin/mtree/mtree.c,v
retrieving revision 1.26
diff -u -p -r1.26 mtree.c
--- usr.sbin/mtree/mtree.c 16 Sep 2018 12:43:40 - 1.26
+++ usr.sbin/mtree/mtree.c 10 Nov 2021 16:27:26 -
@@ -55,8 +55,6 @@ static void usage(void);
int
main(int argc, char *argv[])
{
- extern int optind;
- extern char *optarg;
int ch;
char *dir, *p;
int status;
Index: usr.sbin/npppctl/npppctl.c
===
RCS file: /cvs/src/usr.sbin/npppctl/npppctl.c,v
retrieving revision 1.9
diff -u -p -r1.9 npppctl.c
--- usr.sbin/npppctl/npppctl.c 28 Jun 2019 13:32:49 - 1.9
+++ usr.sbin/npppctl/npppctl.c 10 Nov 2021 16:27:26 -
@@ -80,8 +80,6 @@ main(int argc, char *argv[])
struct parse_result *result;
struct sockaddr_un sun;
const char *npppd_ctlpath = NPPPD_SOCKET;
- extern int optind;
- extern char *optarg;
while ((ch = getopt(argc, argv, "ns:")) != -1)
switch (ch) {
Index: usr.sbin/npppd/npppd/npppd.c
===
RCS file: /cvs/src/usr.sbin/npppd/npppd/npppd.c,v
retrieving revision 1.51
diff -u -p -r1.51 npppd.c
--- usr.sbin/npppd/npppd/npppd.c29 Mar 2021 03:54:39 - 1.51
+++ usr.sbin/npppd/npppd/npppd.c10 Nov 2021 16:27:26 -
@@ -136,7 +136,6 @@ int
main(int argc, char *argv[])
{
intch, stop_by_error, runasdaemon = 1, nflag = 0;
- extern char *optarg;
const char*npppd_conf0 = DEFAULT_NPPPD_CONF;
struct passwd *pw;
Index: usr.sbin/pstat/pstat.c
===
RCS file: /cvs/src/usr.sbin/pstat/pstat.c,v
retrieving revision 1.126
diff -u -p -r1.126 pstat.c
--- usr.sbin/pstat/pstat.c 20 Oct 2021 06:35:40 - 1.126
+++ usr.sbin/pstat/pstat.c 10 Nov 2021 16:27:26 -
@@ -150,8 +150,6 @@ main(int argc, char *argv[])
int fileflag = 0, swapflag = 0, ttyflag = 0, vnodeflag = 0, ch;
char buf[_POSIX2_LINE_MAX];
const char *dformat = NULL;
- extern char *optarg;
- extern int optind;
int i;
hideroot = getuid();
Index: usr.sbin/quotaon/quotaon.c
===
RCS file: /cvs/src/usr.sbin/quotaon/quotaon.c,v
retrieving revision 1.27
diff -u -p -r1.27 quotaon.c
--- usr.sbin/quotaon/quotaon.c 26 Apr 2018 12:42:51 - 1.27
+++ usr.sbin/quotaon/quotaon.c 10 Nov 2021 16:27:26 -
@@ -66,7 +66,6 @@ main(int argc, char *argv[])
char *qfnp, *whoami;
long argnum, done = 0;
int i, offmode = 0, errs = 0;
- extern int optind;
int ch;
whoami = strrchr(*argv, '/') + 1;
Index: usr.sbin/rarpd/rarpd.c
===
RCS file: /cvs/src/usr.sbin/rarpd/rarpd.c,v
retrieving revision 1.78
diff -u -p -r1.78 rarpd.c
---
Re: arm64: new gpiokeys(4)
On Nov 10 13:20:45, k...@openbsd.org wrote: > On Wed, Nov 10, 2021 at 12:07:37AM +0100, Jan Stary wrote: > > On Nov 09 15:43:04, k...@openbsd.org wrote: > > > This populates `systat sensors' with the correct lid status on my > > > Pinebook Pro: > > > > > > -gpio-key-lid at mainbus0 not configured > > > -gpio-key-power at mainbus0 not configured > > > +gpiokeys0 at mainbus0: "Lid" > > > +gpiokeys0 at mainbus0: "Power" > > > > > > This is what the diff added on RPI4 (dmesg below). > > > > -gpioleds0 at mainbus0: no LEDs > > +gpioleds0 at mainbus0: "led0", "led1" > > This is from another recent commit I made to gpioleds(4), specifically > to recognise LEDs on this machine. Ah, sorry for the confusion. Thanks anyway :-) Jan > It has nothing to do with gpiokeys(4). > > > (Nothing new in systat sens, > > as leds are not sensors.) > > Correct, that's because there are no GPIO keys on the Pi 4 (Model B), > i.e. there's nothing in the device tree to match gpiokeys(4). > >
locale in who(1)
Why does who(1) need to setlocale()?
Jan
Index: who.c
===
RCS file: /cvs/src/usr.bin/who/who.c,v
retrieving revision 1.30
diff -u -p -r1.30 who.c
--- who.c 12 Jul 2021 15:09:20 - 1.30
+++ who.c 10 Nov 2021 12:37:05 -
@@ -44,7 +44,6 @@
#include
#include
#include
-#include
void output(struct utmp *);
void output_labels(void);
@@ -71,8 +70,6 @@ main(int argc, char *argv[])
FILE *ufp;
char *t;
int c;
-
- setlocale(LC_ALL, "");
if (pledge("stdio unveil rpath getpw", NULL) == -1)
err(1, "pledge");
Re: New hw.perfpolicy behavior
On Nov 10 00:21:59, h...@stare.cz wrote: > Regarding C states, this machine has > > acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), > C1(1000@1 mwait.1), PSS > > I suppose the cpu supports C1, C2, C3, but can someone please kindly > explain (or point to an explanation of) what the whole line says? For comparison, my Thinkpad T400 has acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS What does the ! mean?
Re: New hw.perfpolicy behavior
On Nov 02 12:30:56, dera...@openbsd.org wrote: > Paul de Weerd wrote: > > > A recent commit by Theo changed the hw.perfpolicy behavior to always > > run at full speed when AC power is on. This means that my workstation > > (and servers, once I upgrade them) now consumes significantly more > > power, even though they usually idle. > > Did you measure how much more power? > > You must measure, to make such a claim. > > Your OptiPlex 9020 is probably a modern i5/i7, which probably contains > C states similar to this: > > acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS > > Which means when the idle loop calls the "mwait" instruction, the cpu > will 'instantly' slow down to a lower clock and make other power use > reductions, until an interrupt happens and requires labour again. > > Most modern cpus dynamically downscale in such way, which mostly > obliterates the requirement to manually control things, or even handle > it in a slow-paced data-weak way in the scheduler. Measuring on this PC running current/amd64 (dmesg below), with a Sep 26 snapshot and the latest snapshot. As a naive test, I am measuring the power consumption of compiling the kernel (is that too small?). The numbers are mostly the same on both of these systems, with each of apmd with apm -A, -H, -L respectively, or without running apmd at all. Namely, it takes about 04:30 to make, and it consumes about 0.007 kWh. Then again, doing nothing for 04:30 consumes about 0.004. (Are these too small to be a measurement?) Regarding C states, this machine has acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS I suppose the cpu supports C1, C2, C3, but can someone please kindly explain (or point to an explanation of) what the whole line says? Thank you Jan OpenBSD 7.0-current (GENERIC.MP) #85: Tue Nov 9 13:24:56 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17009606656 (16221MB) avail mem = 16478068736 (15714MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries) bios0: vendor Award Software International, Inc. version "F3" date 03/31/2011 bios0: Gigabyte Technology Co., Ltd. H67MA-USB3-B3 acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xf400, bus 0-63 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.74 MHz, 06-2a-07 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,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.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.30 MHz, 06-2a-07 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,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-2600 CPU @ 3.40GHz, 3392.30 MHz, 06-2a-07 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,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-2600 CPU @ 3.40GHz, 3392.30 MHz, 06-2a-07 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3:
Re: arm64: new gpiokeys(4)
On Nov 09 15:43:04, k...@openbsd.org wrote: > This populates `systat sensors' with the correct lid status on my > Pinebook Pro: > > -gpio-key-lid at mainbus0 not configured > -gpio-key-power at mainbus0 not configured > +gpiokeys0 at mainbus0: "Lid" > +gpiokeys0 at mainbus0: "Power" This is what the diff added on RPI4 (dmesg below). -gpioleds0 at mainbus0: no LEDs +gpioleds0 at mainbus0: "led0", "led1" (Nothing new in systat sens, as leds are not sensors.) Jan OpenBSD 7.0-current (GENERIC.MP) #0: Tue Nov 9 21:52:42 CET 2021 h...@pi.stare.cz:/usr/src/sys/arch/arm64/compile/GENERIC.MP real mem = 8419885056 (8029MB) avail mem = 8128704512 (7752MB) random: good seed from bootblocks mainbus0 at root: Raspberry Pi 4 Model B Rev 1.4 cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3 cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu0: 1024KB 64b/line 16-way L2 cache cpu0: CRC32,ASID16 cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p3 cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu1: 1024KB 64b/line 16-way L2 cache cpu1: CRC32,ASID16 cpu2 at mainbus0 mpidr 2: ARM Cortex-A72 r0p3 cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu2: 1024KB 64b/line 16-way L2 cache cpu2: CRC32,ASID16 cpu3 at mainbus0 mpidr 3: ARM Cortex-A72 r0p3 cpu3: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu3: 1024KB 64b/line 16-way L2 cache cpu3: CRC32,ASID16 efi0 at mainbus0: UEFI 2.8 efi0: Das U-Boot rev 0x20210100 apm0 at mainbus0 "system" at mainbus0 not configured "axi" at mainbus0 not configured simplebus0 at mainbus0: "soc" bcmclock0 at simplebus0 bcmmbox0 at simplebus0 bcmgpio0 at simplebus0 bcmaux0 at simplebus0 ampintc0 at simplebus0 nirq 256, ncpu 4 ipi: 0, 1: "interrupt-controller" bcmtmon0 at simplebus0 bcmdmac0 at simplebus0: DMA0 DMA2 DMA4 DMA5 DMA6 DMA7 DMA8 DMA9 "timer" at simplebus0 not configured pluart0 at simplebus0: console "local_intc" at simplebus0 not configured bcmdog0 at simplebus0 bcmirng0 at simplebus0 "firmware" at simplebus0 not configured "power" at simplebus0 not configured "mailbox" at simplebus0 not configured sdhc0 at simplebus0 sdhc0: SDHC 3.0, 250 MHz base clock sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed "gpiomem" at simplebus0 not configured "fb" at simplebus0 not configured "vcsm" at simplebus0 not configured "clocks" at mainbus0 not configured "phy" at mainbus0 not configured "clk-27M" at mainbus0 not configured "clk-108M" at mainbus0 not configured simplebus1 at mainbus0: "emmc2bus" sdhc1 at simplebus1 sdhc1: SDHC 3.0, 100 MHz base clock sdmmc1 at sdhc1: 8-bit, sd high-speed, mmc high-speed, ddr52, dma "arm-pmu" at mainbus0 not configured agtimer0 at mainbus0: 54000 kHz simplebus2 at mainbus0: "scb" bcmpcie0 at simplebus2 pci0 at bcmpcie0 ppb0 at pci0 dev 0 function 0 "Broadcom BCM2711" rev 0x10 pci1 at ppb0 bus 1 xhci0 at pci1 dev 0 function 0 "VIA VL805 xHCI" rev 0x01: intx, xHCI 1.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "VIA xHCI root hub" rev 3.00/1.00 addr 1 bse0 at simplebus2: address dc:a6:32:e0:50:d3 brgphy0 at bse0 phy 1: BCM54210E 10/100/1000baseT PHY, rev. 2 "dma" at simplebus2 not configured "hevc-decoder" at simplebus2 not configured "rpivid-local-intc" at simplebus2 not configured "h264-decoder" at simplebus2 not configured "vp9-decoder" at simplebus2 not configured gpioleds0 at mainbus0: "led0", "led1" "sd_io_1v8_reg" at mainbus0 not configured "sd_vcc_reg" at mainbus0 not configured "fixedregulator_3v3" at mainbus0 not configured "fixedregulator_5v0" at mainbus0 not configured simplebus3 at mainbus0: "v3dbus" "bootloader" at mainbus0 not configured dt: 445 probes scsibus0 at sdmmc1: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: removable sd0: 30436MB, 512 bytes/sector, 62333952 sectors uhub1 at uhub0 port 1 configuration 1 interface 0 "VIA Labs USB2.0 Hub" rev 2.10/4.21 addr 2 bwfm0 at sdmmc0 function 1 manufacturer 0x02d0, product 0xa9a6 at sdmmc0 function 2 not configured manufacturer 0x02d0, product 0xa9a6 at sdmmc0 function 3 not configured vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets root on sd0a (d1a7e0233ab9545d.a) swap on sd0b dump on sd0b WARNING: CHECK AND RESET THE DATE! gpio0 at bcmgpio0: 58 pins bwfm0: address dc:a6:32:e0:50:d4
Re: add 802.11n 40MHz support to iwn(4)
On Nov 09 00:36:03, h...@stare.cz wrote: > As a naive test of speed, I am downloading a 100MB file > from a http server just behind the AP with > ftp -o /dev/null http://stare.cz/.tmp/file > An average of ten runs is 5.31 MB/s without the diff > and 3.37 MB/s with the (updated) diff. Any idea how enabling 40 MHz could slow it down? Jan
Re: add 802.11n 40MHz support to iwn(4)
On Nov 01 12:56:26, s...@stsp.name wrote: > This patch adds 802.11n 40MHz support to the iwn(4) driver. > > This driver supports many different devices. Please try to be precise > about which device you have tested so I can maintain a record of our > test coverage. This is current/amd64 on a Thinkpad T400 with iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5300" rev 0x00: msi, MIMO 3T3R, MoW, address 00:21:6a:01:9f:ce > I have tested on a 6205 device. More tests are needed, especially on > the old 4965AGN generation because those chips require the driver to > do specific calibration work which newer chips perform in firmware. > I suspect you will find 4965 devices in older thinkpads which first > introduced 11n wifi to these laptops (the x60/x61 generation probably). I only had a 4965 in a Thinkpad R61 which I got rid of, sorry. > Because iwn(4) does not support MIMO yet, this pushes maximum throughput > from about 50 Mbit/s up to about 100 Mbit/s. Adding MIMO support would > probably double the speed again, but that is left for the future. > > To check whether your access point uses a 40MHz channel, run this command > while associated to the access point: > tcpdump -n -i iwn0 -v -y IEEE802_11_RADIO -s 4096 type mgt and subtype beacon 21:48:50.970252 802.11 flags=0<>: beacon, caps=2061, ssid (doma), rates 1M* 2M* 5M* 11M* 6M 9M 12M 18M, ds (chan 9), tim 0x0001, erp 0x00, rsn=, xrates 24M 36M 48M 54M, htcaps=<20/40MHz,LDPC,SGI@20MHz,SGI@40MHz,TXSTBC,RXSTBC 1 stream,A-MSDU 3839,DSSS/CCK@40MHz,A-MPDU max 65535,A-MPDU spacing 8.00us,RxMCS 0x>, htop=<40MHz chan 9:8,RIFS,htprot 20MHz,non-greenfield STA,basic MCS set 0x>, 127:8 0x0040, vendor 0x0050f2010150f2040150f2040150f202, vendor 0x0050f202010183a427a442435e0062322f00, vendor 0x00037f0101ff7f, The wifi connection seems fine, everything works as before. As a naive test of speed, I am downloading a 100MB file from a http server just behind the AP with ftp -o /dev/null http://stare.cz/.tmp/file An average of ten runs is 5.31 MB/s without the diff and 3.37 MB/s with the (updated) diff. Jan
doas needs doas.conf
Say explicitly that doas needs doas.conf to exist, and point to the example one. Jan Index: doas.1 === RCS file: /cvs/src/usr.bin/doas/doas.1,v retrieving revision 1.25 diff -u -p -r1.25 doas.1 --- doas.1 16 Jan 2021 09:18:41 - 1.25 +++ doas.1 19 Feb 2021 19:20:58 - @@ -43,6 +43,15 @@ is specified. The user will be required to authenticate by entering their password, unless configured otherwise. .Pp +.Nm +will not execute the +.Ar command +if the file +.Pa /etc/doas.conf +does not exist. +An example is provided in +.Pa /etc/examples/ . +.Pp By default, a new environment is created. The variables .Ev HOME , @@ -110,6 +119,11 @@ or Execute the command as .Ar user . The default is root. +.El +.Sh FILES +.Bl -tag -compact +.It Pa /etc/doas.conf +.It Pa /etc/examples/doas.conf .El .Sh EXIT STATUS .Ex -std doas
Re: extern int optreset not needed
On Dec 26 23:24:57, h...@stare.cz wrote:
> ftpd doesn't need to declare extern int optreset
> as that is already done in the included unistd.h
Here's more for usr.sbin/, if desirable.
Jan
Index: usr.sbin//amd/amd/get_args.c
===
RCS file: /cvs/src/usr.sbin/amd/amd/get_args.c,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 get_args.c
--- usr.sbin//amd/amd/get_args.c20 Oct 2014 02:33:42 - 1.14
+++ usr.sbin//amd/amd/get_args.c27 Dec 2020 18:44:15 -
@@ -44,9 +44,6 @@
#include
#include
-extern int optind;
-extern char *optarg;
-
#if defined(DEBUG) && defined(PARANOID)
char **gargv;
#endif /* defined(DEBUG) && defined(PARANOID) */
Index: usr.sbin//amd/amq/amq.c
===
RCS file: /cvs/src/usr.sbin/amd/amq/amq.c,v
retrieving revision 1.21
diff -u -p -u -p -r1.21 amq.c
--- usr.sbin//amd/amq/amq.c 21 Jan 2017 08:33:51 - 1.21
+++ usr.sbin//amd/amq/amq.c 27 Dec 2020 18:44:15 -
@@ -59,9 +59,6 @@ static char *xlog_optstr;
static char localhost[] = "localhost";
static char *def_server = localhost;
-extern int optind;
-extern char *optarg;
-
static struct timeval tmo = { 10, 0 };
#defineTIMEOUT tmo
Index: usr.sbin//crunchgen/crunchgen.c
===
RCS file: /cvs/src/usr.sbin/crunchgen/crunchgen.c,v
retrieving revision 1.21
diff -u -p -u -p -r1.21 crunchgen.c
--- usr.sbin//crunchgen/crunchgen.c 18 Oct 2018 14:25:14 - 1.21
+++ usr.sbin//crunchgen/crunchgen.c 27 Dec 2020 18:44:15 -
@@ -117,8 +117,6 @@ main(int argc, char *argv[])
{
char *p;
int optc;
- extern int optind;
- extern char*optarg;
if (pledge("stdio rpath wpath cpath proc exec", NULL) == -1) {
perror("pledge");
Index: usr.sbin//mtree/mtree.c
===
RCS file: /cvs/src/usr.sbin/mtree/mtree.c,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 mtree.c
--- usr.sbin//mtree/mtree.c 16 Sep 2018 12:43:40 - 1.26
+++ usr.sbin//mtree/mtree.c 27 Dec 2020 18:44:15 -
@@ -55,8 +55,6 @@ static void usage(void);
int
main(int argc, char *argv[])
{
- extern int optind;
- extern char *optarg;
int ch;
char *dir, *p;
int status;
Index: usr.sbin//npppctl/npppctl.c
===
RCS file: /cvs/src/usr.sbin/npppctl/npppctl.c,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 npppctl.c
--- usr.sbin//npppctl/npppctl.c 28 Jun 2019 13:32:49 - 1.9
+++ usr.sbin//npppctl/npppctl.c 27 Dec 2020 18:44:15 -
@@ -80,8 +80,6 @@ main(int argc, char *argv[])
struct parse_result *result;
struct sockaddr_un sun;
const char *npppd_ctlpath = NPPPD_SOCKET;
- extern int optind;
- extern char *optarg;
while ((ch = getopt(argc, argv, "ns:")) != -1)
switch (ch) {
Index: usr.sbin//npppd/npppd/npppd.c
===
RCS file: /cvs/src/usr.sbin/npppd/npppd/npppd.c,v
retrieving revision 1.50
diff -u -p -u -p -r1.50 npppd.c
--- usr.sbin//npppd/npppd/npppd.c 10 May 2019 01:29:31 - 1.50
+++ usr.sbin//npppd/npppd/npppd.c 27 Dec 2020 18:44:15 -
@@ -136,7 +136,6 @@ int
main(int argc, char *argv[])
{
intch, stop_by_error, runasdaemon = 1, nflag = 0;
- extern char *optarg;
const char*npppd_conf0 = DEFAULT_NPPPD_CONF;
struct passwd *pw;
Index: usr.sbin//pstat/pstat.c
===
RCS file: /cvs/src/usr.sbin/pstat/pstat.c,v
retrieving revision 1.123
diff -u -p -u -p -r1.123 pstat.c
--- usr.sbin//pstat/pstat.c 28 Sep 2020 15:53:13 - 1.123
+++ usr.sbin//pstat/pstat.c 27 Dec 2020 18:44:15 -
@@ -150,8 +150,6 @@ main(int argc, char *argv[])
int fileflag = 0, swapflag = 0, ttyflag = 0, vnodeflag = 0, ch;
char buf[_POSIX2_LINE_MAX];
const char *dformat = NULL;
- extern char *optarg;
- extern int optind;
int i;
hideroot = getuid();
Index: usr.sbin//quotaon/quotaon.c
===
RCS file: /cvs/src/usr.sbin/quotaon/quotaon.c,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 quotaon.c
--- usr.sbin//quotaon/quotaon.c 26 Apr 2018 12:42:51 - 1.27
+++ usr.sbin//quotaon/quotaon.c 27 Dec 2020 18:44:15 -
@@ -66,7 +66,6 @@ main(int argc, char *argv[])
char *qfnp, *whoami;
long argnum, done = 0;
int i, offmode = 0, errs = 0;
- extern int optind;
int ch;
whoami = strrchr(*argv, '/') + 1;
Index:
extern int optreset not needed
ftpd doesn't need to declare extern int optreset as that is already done in the included unistd.h Jan Index: popen.c === RCS file: /cvs/src/libexec/ftpd/popen.c,v retrieving revision 1.29 diff -u -p -r1.29 popen.c --- popen.c 15 Jan 2020 22:06:59 - 1.29 +++ popen.c 26 Dec 2020 22:05:49 - @@ -113,7 +113,6 @@ ftpd_ls(const char *path, pid_t *pidptr) (void)close(pdes[0]); closelog(); - extern int optreset; extern int ls_main(int, char **); /* reset getopt for ls_main */
Re: mixerctl names
On Oct 17 11:12:28, cpb_t...@bennettconstruction.us wrote: > On Sat, Oct 17, 2020 at 05:52:58PM +0200, Jan Stary wrote: > > Currently, mixerctl.conf(5) says > > > > Most devices have a number of digital to analogue converters > > (DACs), used for sound playback, and each DAC has a corresponding > > output mixer. The mixers are labelled “mix” or “sel”. > > > > That doesn't seem to be the case, at least not universaly > > as the wording seems to imply. For example, this is > > mixerctl output on a Thinkpad T400: > > > > inputs.dac-0:1=222,222 > > inputs.dac-2:3=222,222 > > inputs.beep=0 > > record.adc-2:3_source=mic2 > > record.adc-2:3=219,219 > > record.adc-0:1_source=mic > > record.adc-0:1=219,219 > > outputs.hp_source=dac-0:1 > > outputs.hp_boost=on > > inputs.mic=189,189 > > outputs.mic_dir=input-vr80 > > outputs.spkr_source=dac-2:3 > > outputs.spkr_eapd=on > > inputs.mic2=189,189 > > outputs.hp_sense=unplugged > > outputs.mic_sense=unplugged > > outputs.master=240,240 > > outputs.master.mute=off > > outputs.master.slaves= > > record.volume=240,240 > > record.volume.mute=off > > record.volume.slaves= > > record.enable=sysctl > > > > Apparently, it has two DACS (for the speakers and the headphones). > > The current wording might confuse the user into thinking he has > > no output mixer, but the > > > > inputs.dac-0:1=222,222 > > inputs.dac-2:3=222,222 > > > > do control the respective volumes, > > while no "mix" or "sel" exists. > > > > Similarly for recording via the two ADCs. > > > > > > Jan > > > Thank you! +1 > > I had no idea what was going on and had basically given up on having the > speakers off. > > changing outputs.master moves BOTH inputs.dac. Which is superbly > confusing! I balieve this is the purpose of outputs.master - it sets the volume for multiple widgets; outputs.master.slaves says which. See azalia(4). > Now I just manually changed each inputs.dac alone. You are not supposed to tweak these controls directly; that's mixerctl does, and it requires root privileges. Try to set your controls with sndioctl as a regular user.
mixerctl names
Currently, mixerctl.conf(5) says Most devices have a number of digital to analogue converters (DACs), used for sound playback, and each DAC has a corresponding output mixer. The mixers are labelled “mix” or “sel”. That doesn't seem to be the case, at least not universaly as the wording seems to imply. For example, this is mixerctl output on a Thinkpad T400: inputs.dac-0:1=222,222 inputs.dac-2:3=222,222 inputs.beep=0 record.adc-2:3_source=mic2 record.adc-2:3=219,219 record.adc-0:1_source=mic record.adc-0:1=219,219 outputs.hp_source=dac-0:1 outputs.hp_boost=on inputs.mic=189,189 outputs.mic_dir=input-vr80 outputs.spkr_source=dac-2:3 outputs.spkr_eapd=on inputs.mic2=189,189 outputs.hp_sense=unplugged outputs.mic_sense=unplugged outputs.master=240,240 outputs.master.mute=off outputs.master.slaves= record.volume=240,240 record.volume.mute=off record.volume.slaves= record.enable=sysctl Apparently, it has two DACS (for the speakers and the headphones). The current wording might confuse the user into thinking he has no output mixer, but the inputs.dac-0:1=222,222 inputs.dac-2:3=222,222 do control the respective volumes, while no "mix" or "sel" exists. Similarly for recording via the two ADCs. Jan Index: mixerctl.conf.5 === RCS file: /cvs/src/share/man/man5/mixerctl.conf.5,v retrieving revision 1.10 diff -u -p -r1.10 mixerctl.conf.5 --- mixerctl.conf.5 21 Apr 2020 21:32:26 - 1.10 +++ mixerctl.conf.5 17 Oct 2020 15:31:23 - @@ -66,10 +66,6 @@ TOSLink, RCA, or 1/8" mini stereo. Most devices have a number of digital to analogue converters (DACs), used for sound playback, and each DAC has a corresponding output mixer. -The mixers are labelled -.Dq mix -or -.Dq sel . Each DAC represents two channels of playback. .Pp Verify that playback works by playing an audio file @@ -104,10 +100,6 @@ shows the number of channels available. Most devices have a number of analogue to digital converters (ADCs), used for recording sound, and each ADC has a corresponding input mixer. -The mixers are labelled -.Dq mix -or -.Dq sel . Each ADC represents two channels of recording. .Pp Connect line in on the audio card to an audio source,
Re: acpicpu(4) and ACPI0007
On Aug 01 18:23:08, jonat...@d14n.org wrote:
> Much better theory: the acpicpu_sc array has MAXCPUS elements, but on this
> system (and all R6415s, as far as I can tell) we have more acpicpu devices
> than that. I suppose we should just make acpicpu_match fail if cf->cf_unit
> is >= MAXCPUS as we do with the actual cpu devices.
>
>
> Index: acpicpu.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpicpu.c,v
> retrieving revision 1.85
> diff -u -p -r1.85 acpicpu.c
> --- acpicpu.c 27 May 2020 05:02:21 - 1.85
> +++ acpicpu.c 1 Aug 2020 08:18:49 -
> @@ -186,6 +186,11 @@ struct cfdriver acpicpu_cd = {
> NULL, "acpicpu", DV_DULL
> };
>
> +const char *acpicpu_hids[] = {
> + "ACPI0007",
> + NULL
> +};
> +
> extern int setperf_prio;
>
> struct acpicpu_softc *acpicpu_sc[MAXCPUS];
> @@ -650,6 +655,12 @@ acpicpu_match(struct device *parent, voi
> struct acpi_attach_args *aa = aux;
> struct cfdata *cf = match;
>
> + if (cf->cf_unit >= MAXCPUS)
> + return (0);
> +
> + if (acpi_matchhids(aa, acpicpu_hids, cf->cf_driver->cd_name))
> + return (1);
> +
> /* sanity */
> if (aa->aaa_name == NULL ||
> strcmp(aa->aaa_name, cf->cf_driver->cd_name) != 0 ||
> @@ -665,6 +676,7 @@ acpicpu_attach(struct device *parent, st
> struct acpicpu_softc*sc = (struct acpicpu_softc *)self;
> struct acpi_attach_args *aa = aux;
> struct aml_valueres;
> + int64_t uid;
> int i;
> uint32_tstatus = 0;
> CPU_INFO_ITERATOR cii;
> @@ -675,6 +687,10 @@ acpicpu_attach(struct device *parent, st
> acpicpu_sc[sc->sc_dev.dv_unit] = sc;
>
> SLIST_INIT(>sc_cstates);
> +
> + if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode,
> + "_UID", 0, NULL, ) == 0)
> + sc->sc_cpu = uid;
>
> if (aml_evalnode(sc->sc_acpi, sc->sc_devnode, 0, NULL, ) == 0) {
> if (res.type == AML_OBJTYPE_PROCESSOR) {
>
See below for the old and the new dmesg of current/amd64 at an APU2.
Edited highlights of the diff:
--- apu2e.20200610 Wed Jun 10 22:24:25 2020
+++ apu2e.20200801 Sat Aug 1 19:17:00 2020
-"ACPI0007" at acpi0 not configured
-"ACPI0007" at acpi0 not configured
-"ACPI0007" at acpi0 not configured
-"ACPI0007" at acpi0 not configured
-"ACPI0007" at acpi0 not configured
-"ACPI0007" at acpi0 not configured
-"ACPI0007" at acpi0 not configured
-"ACPI0007" at acpi0 not configured
+acpicpu0 at acpi0copyvalue: 6: C2(0@400 io@0x1771), C1(@1 halt!), PSS
+acpicpu1 at acpi0copyvalue: 6: C2(0@400 io@0x1771), C1(@1 halt!), PSS
+acpicpu2 at acpi0copyvalue: 6: C2(0@400 io@0x1771), C1(@1 halt!), PSS
+acpicpu3 at acpi0copyvalue: 6: C2(0@400 io@0x1771), C1(@1 halt!), PSS
+acpicpu4 at acpi0copyvalue: 6: no cpu matching ACPI ID 4
+acpicpu5 at acpi0copyvalue: 6: no cpu matching ACPI ID 5
+acpicpu6 at acpi0copyvalue: 6: no cpu matching ACPI ID 6
+acpicpu7 at acpi0copyvalue: 6: no cpu matching ACPI ID 7
+cpu0: 998 MHz: speeds: 1000 800 600 MHz
Jan
OpenBSD 6.7-current (GENERIC.MP) #0: Wed Jun 10 22:14:40 CEST 2020
h...@uvt.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1996484608 (1903MB)
avail mem = 1921105920 (1832MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7ee8d020 (13 entries)
bios0: vendor coreboot version "v4.11.0.5" date 03/29/2020
bios0: PC Engines apu2
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT HPET
acpi0: wakeup devices PWRB(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4)
UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-64
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD GX-412TC SOC, 998.26 MHz, 16-30-01
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD GX-412TC SOC, 998.14 MHz, 16-30-01
cpu1:
Re: LOCALE_HOME for strtime(3)
ping
On Jul 16 09:23:22, h...@stare.cz wrote:
> On Jul 15 15:48:41, mill...@openbsd.org wrote:
> > Upstream tzcode removed the LOCALE_HOME bits in 2014. There's no
> > reason for us to keep it.
>
> With that removed, the header file can go too.
>
> Jan
>
>
> Index: lib/libc/time/strftime.c
> ===
> RCS file: /cvs/src/lib/libc/time/strftime.c,v
> retrieving revision 1.32
> diff -u -p -r1.32 strftime.c
> --- lib/libc/time/strftime.c 29 Jun 2019 16:12:21 - 1.32
> +++ lib/libc/time/strftime.c 16 Jul 2020 07:20:23 -
> @@ -29,7 +29,6 @@
> */
>
> #include
> -#include
> #include
>
> #include "private.h"
> @@ -48,16 +47,7 @@ struct lc_time_T {
> const char *date_fmt;
> };
>
> -#ifdef LOCALE_HOME
> -#include "sys/stat.h"
> -static struct lc_time_T localebuf;
> -static struct lc_time_T *_loc(void);
> -#define Locale _loc()
> -#endif /* defined LOCALE_HOME */
> -#ifndef LOCALE_HOME
> #define Locale (_time_locale)
> -#endif /* !defined LOCALE_HOME */
> -
> static const struct lc_time_TC_time_locale = {
> {
> "Jan", "Feb", "Mar", "Apr", "May", "Jun",
> @@ -124,9 +114,6 @@ strftime(char *s, size_t maxsize, const
> int warn;
>
> tzset();
> -#ifdef LOCALE_HOME
> - localebuf.mon[0] = 0;
> -#endif /* defined LOCALE_HOME */
> warn = IN_NONE;
> p = _fmt(((format == NULL) ? "%c" : format), t, s, s + maxsize, );
> if (p == s + maxsize) {
> @@ -558,135 +545,3 @@ _yconv(int a, int b, int convert_top, in
> pt = _conv(((trail < 0) ? -trail : trail), "%02d", pt, ptlim);
> return pt;
> }
> -
> -#ifdef LOCALE_HOME
> -static struct lc_time_T *
> -_loc(void)
> -{
> - static const char locale_home[] = LOCALE_HOME;
> - static const char lc_time[] = "LC_TIME";
> - static char * locale_buf;
> -
> - int fd;
> - int oldsun; /* "...ain't got nothin' to do..." */
> - int len;
> - char * lbuf;
> - char * nlbuf;
> - char * name;
> - char * p;
> - const char ** ap;
> - const char *plim;
> - charfilename[PATH_MAX];
> - struct stat st;
> - size_t namesize;
> - size_t bufsize;
> -
> - /*
> - ** Use localebuf.mon[0] to signal whether locale is already set up.
> - */
> - if (localebuf.mon[0])
> - return
> - name = setlocale(LC_TIME, (char *) NULL);
> - if (name == NULL || *name == '\0')
> - goto no_locale;
> - /*
> - ** If the locale name is the same as our cache, use the cache.
> - */
> - lbuf = locale_buf;
> - if (lbuf != NULL && strcmp(name, lbuf) == 0) {
> - p = lbuf;
> - for (ap = (const char **)
> - ap < (const char **) ( + 1);
> - ++ap)
> - *ap = p += strlen(p) + 1;
> - return
> - }
> - /*
> - ** Slurp the locale file into the cache.
> - */
> - namesize = strlen(name) + 1;
> - if (sizeof filename <
> - ((sizeof locale_home) + namesize + (sizeof lc_time)))
> - goto no_locale;
> - oldsun = 0;
> - len = snprintf(filename, sizeof filename, "%s/%s/%s", locale_home,
> - name, lc_time);
> - if (len < 0 || len >= sizeof filename)
> - goto no_locale;
> - fd = open(filename, O_RDONLY);
> - if (fd == -1) {
> - /*
> - ** Old Sun systems have a different naming and data convention.
> - */
> - oldsun = 1;
> - len = snprintf(filename, sizeof filename, "%s/%s/%s",
> - locale_home, lc_time, name);
> - if (len < 0 || len >= sizeof filename)
> - goto no_locale;
> - fd = open(filename, O_RDONLY);
> - if (fd == -1)
> - goto no_locale;
> - }
> - if (fstat(fd, ) == -1)
> - goto bad_locale;
> - if (st.st_size <= 0)
> - goto bad_locale;
> - bufsize = namesize + st.st_size;
> - locale_buf = NULL;
> - nlbuf = realloc(lbuf, bufsize);
> - if (nlbuf == NULL) {
> - free(lbuf);
> - lbuf = NULL;
> - goto bad_locale;
> - }
> - lbuf = nlbuf;
> - (void) strlcpy(lbuf, name, bufsize);
> - p = lbuf + namesize;
> - plim = p + st.st_size;
> - if (read(fd, p, st.st_size) != st.st_size)
> - goto bad_lbuf;
> - if (close(fd) != 0)
> - goto bad_lbuf;
> - /*
> - ** Parse the locale file into localebuf.
> - */
> - if (plim[-1] != '\n')
> - goto bad_lbuf;
> - for
LC_MESSAGES in xargs(1)
Does xargs need to set LC_MESSAGES? Jan Index: usr.bin/xargs/xargs.c === RCS file: /cvs/src/usr.bin/xargs/xargs.c,v retrieving revision 1.34 diff -u -p -r1.34 xargs.c --- usr.bin/xargs/xargs.c 12 Jun 2018 15:24:31 - 1.34 +++ usr.bin/xargs/xargs.c 16 Jul 2020 07:40:26 - @@ -42,7 +42,6 @@ #include #include #include -#include #include #include #include @@ -85,8 +84,6 @@ main(int argc, char *argv[]) ep = environ; eofstr = ""; Jflag = nflag = 0; - - (void)setlocale(LC_MESSAGES, ""); /* * POSIX.2 limits the exec line length to ARG_MAX - 2K. Running that
Re: LOCALE_HOME for strtime(3)
On Jul 15 15:48:41, mill...@openbsd.org wrote:
> Upstream tzcode removed the LOCALE_HOME bits in 2014. There's no
> reason for us to keep it.
With that removed, the header file can go too.
Jan
Index: lib/libc/time/strftime.c
===
RCS file: /cvs/src/lib/libc/time/strftime.c,v
retrieving revision 1.32
diff -u -p -r1.32 strftime.c
--- lib/libc/time/strftime.c29 Jun 2019 16:12:21 - 1.32
+++ lib/libc/time/strftime.c16 Jul 2020 07:20:23 -
@@ -29,7 +29,6 @@
*/
#include
-#include
#include
#include "private.h"
@@ -48,16 +47,7 @@ struct lc_time_T {
const char *date_fmt;
};
-#ifdef LOCALE_HOME
-#include "sys/stat.h"
-static struct lc_time_Tlocalebuf;
-static struct lc_time_T * _loc(void);
-#define Locale _loc()
-#endif /* defined LOCALE_HOME */
-#ifndef LOCALE_HOME
#define Locale (_time_locale)
-#endif /* !defined LOCALE_HOME */
-
static const struct lc_time_T C_time_locale = {
{
"Jan", "Feb", "Mar", "Apr", "May", "Jun",
@@ -124,9 +114,6 @@ strftime(char *s, size_t maxsize, const
int warn;
tzset();
-#ifdef LOCALE_HOME
- localebuf.mon[0] = 0;
-#endif /* defined LOCALE_HOME */
warn = IN_NONE;
p = _fmt(((format == NULL) ? "%c" : format), t, s, s + maxsize, );
if (p == s + maxsize) {
@@ -558,135 +545,3 @@ _yconv(int a, int b, int convert_top, in
pt = _conv(((trail < 0) ? -trail : trail), "%02d", pt, ptlim);
return pt;
}
-
-#ifdef LOCALE_HOME
-static struct lc_time_T *
-_loc(void)
-{
- static const char locale_home[] = LOCALE_HOME;
- static const char lc_time[] = "LC_TIME";
- static char * locale_buf;
-
- int fd;
- int oldsun; /* "...ain't got nothin' to do..." */
- int len;
- char * lbuf;
- char * nlbuf;
- char * name;
- char * p;
- const char ** ap;
- const char *plim;
- charfilename[PATH_MAX];
- struct stat st;
- size_t namesize;
- size_t bufsize;
-
- /*
- ** Use localebuf.mon[0] to signal whether locale is already set up.
- */
- if (localebuf.mon[0])
- return
- name = setlocale(LC_TIME, (char *) NULL);
- if (name == NULL || *name == '\0')
- goto no_locale;
- /*
- ** If the locale name is the same as our cache, use the cache.
- */
- lbuf = locale_buf;
- if (lbuf != NULL && strcmp(name, lbuf) == 0) {
- p = lbuf;
- for (ap = (const char **)
- ap < (const char **) ( + 1);
- ++ap)
- *ap = p += strlen(p) + 1;
- return
- }
- /*
- ** Slurp the locale file into the cache.
- */
- namesize = strlen(name) + 1;
- if (sizeof filename <
- ((sizeof locale_home) + namesize + (sizeof lc_time)))
- goto no_locale;
- oldsun = 0;
- len = snprintf(filename, sizeof filename, "%s/%s/%s", locale_home,
- name, lc_time);
- if (len < 0 || len >= sizeof filename)
- goto no_locale;
- fd = open(filename, O_RDONLY);
- if (fd == -1) {
- /*
- ** Old Sun systems have a different naming and data convention.
- */
- oldsun = 1;
- len = snprintf(filename, sizeof filename, "%s/%s/%s",
- locale_home, lc_time, name);
- if (len < 0 || len >= sizeof filename)
- goto no_locale;
- fd = open(filename, O_RDONLY);
- if (fd == -1)
- goto no_locale;
- }
- if (fstat(fd, ) == -1)
- goto bad_locale;
- if (st.st_size <= 0)
- goto bad_locale;
- bufsize = namesize + st.st_size;
- locale_buf = NULL;
- nlbuf = realloc(lbuf, bufsize);
- if (nlbuf == NULL) {
- free(lbuf);
- lbuf = NULL;
- goto bad_locale;
- }
- lbuf = nlbuf;
- (void) strlcpy(lbuf, name, bufsize);
- p = lbuf + namesize;
- plim = p + st.st_size;
- if (read(fd, p, st.st_size) != st.st_size)
- goto bad_lbuf;
- if (close(fd) != 0)
- goto bad_lbuf;
- /*
- ** Parse the locale file into localebuf.
- */
- if (plim[-1] != '\n')
- goto bad_lbuf;
- for (ap = (const char **)
- ap < (const char **) ( + 1);
- ++ap) {
- if (p == plim)
-
LOCALE_HOME for strtime(3)
The OpenBSD libc tends to ignore the LC_* except LC_CTYPE.
However, strftime(3) seems to support a LOCALE_HOME thing,
where the user overrides LC_TIME with his own names of months etc.
Looking at http://cvsweb.openbsd.org/src/lib/libc/time/strftime.c ,
it has been there since the beginning.
The manpage does not mention it; on the contrary,
The OpenBSD implementation always uses the C locale and ignores
the global locale, the thread-specific locale, and the locale argument.
and
On systems other than OpenBSD, the LC_TIME locale(1) category can
cause erratic output; see CAVEATS in setlocale(3) for details.
Is that code intentionally there?
The diff below removes it.
Jan
Index: lib/libc/time/strftime.c
===
RCS file: /cvs/src/lib/libc/time/strftime.c,v
retrieving revision 1.32
diff -u -p -r1.32 strftime.c
--- lib/libc/time/strftime.c29 Jun 2019 16:12:21 - 1.32
+++ lib/libc/time/strftime.c15 Jul 2020 21:40:10 -
@@ -48,16 +48,7 @@ struct lc_time_T {
const char *date_fmt;
};
-#ifdef LOCALE_HOME
-#include "sys/stat.h"
-static struct lc_time_Tlocalebuf;
-static struct lc_time_T * _loc(void);
-#define Locale _loc()
-#endif /* defined LOCALE_HOME */
-#ifndef LOCALE_HOME
#define Locale (_time_locale)
-#endif /* !defined LOCALE_HOME */
-
static const struct lc_time_T C_time_locale = {
{
"Jan", "Feb", "Mar", "Apr", "May", "Jun",
@@ -124,9 +115,6 @@ strftime(char *s, size_t maxsize, const
int warn;
tzset();
-#ifdef LOCALE_HOME
- localebuf.mon[0] = 0;
-#endif /* defined LOCALE_HOME */
warn = IN_NONE;
p = _fmt(((format == NULL) ? "%c" : format), t, s, s + maxsize, );
if (p == s + maxsize) {
@@ -558,135 +546,3 @@ _yconv(int a, int b, int convert_top, in
pt = _conv(((trail < 0) ? -trail : trail), "%02d", pt, ptlim);
return pt;
}
-
-#ifdef LOCALE_HOME
-static struct lc_time_T *
-_loc(void)
-{
- static const char locale_home[] = LOCALE_HOME;
- static const char lc_time[] = "LC_TIME";
- static char * locale_buf;
-
- int fd;
- int oldsun; /* "...ain't got nothin' to do..." */
- int len;
- char * lbuf;
- char * nlbuf;
- char * name;
- char * p;
- const char ** ap;
- const char *plim;
- charfilename[PATH_MAX];
- struct stat st;
- size_t namesize;
- size_t bufsize;
-
- /*
- ** Use localebuf.mon[0] to signal whether locale is already set up.
- */
- if (localebuf.mon[0])
- return
- name = setlocale(LC_TIME, (char *) NULL);
- if (name == NULL || *name == '\0')
- goto no_locale;
- /*
- ** If the locale name is the same as our cache, use the cache.
- */
- lbuf = locale_buf;
- if (lbuf != NULL && strcmp(name, lbuf) == 0) {
- p = lbuf;
- for (ap = (const char **)
- ap < (const char **) ( + 1);
- ++ap)
- *ap = p += strlen(p) + 1;
- return
- }
- /*
- ** Slurp the locale file into the cache.
- */
- namesize = strlen(name) + 1;
- if (sizeof filename <
- ((sizeof locale_home) + namesize + (sizeof lc_time)))
- goto no_locale;
- oldsun = 0;
- len = snprintf(filename, sizeof filename, "%s/%s/%s", locale_home,
- name, lc_time);
- if (len < 0 || len >= sizeof filename)
- goto no_locale;
- fd = open(filename, O_RDONLY);
- if (fd == -1) {
- /*
- ** Old Sun systems have a different naming and data convention.
- */
- oldsun = 1;
- len = snprintf(filename, sizeof filename, "%s/%s/%s",
- locale_home, lc_time, name);
- if (len < 0 || len >= sizeof filename)
- goto no_locale;
- fd = open(filename, O_RDONLY);
- if (fd == -1)
- goto no_locale;
- }
- if (fstat(fd, ) == -1)
- goto bad_locale;
- if (st.st_size <= 0)
- goto bad_locale;
- bufsize = namesize + st.st_size;
- locale_buf = NULL;
- nlbuf = realloc(lbuf, bufsize);
- if (nlbuf == NULL) {
- free(lbuf);
- lbuf = NULL;
- goto bad_locale;
- }
- lbuf = nlbuf;
- (void) strlcpy(lbuf, name, bufsize);
- p = lbuf + namesize;
- plim = p + st.st_size;
- if (read(fd, p,
no need for "extern optind" etc
This is in the vein of
https://marc.info/?l=openbsd-cvs=158170787221615=2
declares "extern int optind" and friends,
so there is no need to declare them again.
Still builds on current/amd64.
Leaving out gnu, nsd, unbound (third party)
and tic (is that third party)?
Also leaving out pr and rcs
who do their own thing.
Jan
Index: sys/dev/microcode/aic7xxx/aicasm.c
===
RCS file: /cvs/src/sys/dev/microcode/aic7xxx/aicasm.c,v
retrieving revision 1.16
diff -u -p -r1.16 aicasm.c
--- sys/dev/microcode/aic7xxx/aicasm.c 19 Dec 2014 22:44:58 - 1.16
+++ sys/dev/microcode/aic7xxx/aicasm.c 15 Jul 2020 14:45:14 -
@@ -112,8 +112,6 @@ int main(int argc, char *argv[]);
int
main(int argc, char *argv[])
{
- extern char *optarg;
- extern int optind;
int ch;
int retval;
char *inputfilename;
Index: usr.bin/env/env.c
===
RCS file: /cvs/src/usr.bin/env/env.c,v
retrieving revision 1.17
diff -u -p -r1.17 env.c
--- usr.bin/env/env.c 28 Oct 2016 07:22:59 - 1.17
+++ usr.bin/env/env.c 15 Jul 2020 14:45:14 -
@@ -42,7 +42,6 @@ int
main(int argc, char *argv[])
{
extern char **environ;
- extern int optind;
char **ep, *p;
int ch;
Index: usr.bin/finger/finger.c
===
RCS file: /cvs/src/usr.bin/finger/finger.c,v
retrieving revision 1.27
diff -u -p -r1.27 finger.c
--- usr.bin/finger/finger.c 26 Apr 2018 12:42:51 - 1.27
+++ usr.bin/finger/finger.c 15 Jul 2020 14:45:14 -
@@ -76,7 +76,6 @@ PERSON *phead, *ptail;
int
main(int argc, char *argv[])
{
- extern int optind;
extern char *__progname;
int ch;
char domain[HOST_NAME_MAX+1];
Index: usr.bin/ftp/cmds.c
===
RCS file: /cvs/src/usr.bin/ftp/cmds.c,v
retrieving revision 1.84
diff -u -p -r1.84 cmds.c
--- usr.bin/ftp/cmds.c 18 Nov 2019 04:37:35 - 1.84
+++ usr.bin/ftp/cmds.c 15 Jul 2020 14:45:14 -
@@ -217,7 +217,6 @@ usage:
void
mput(int argc, char *argv[])
{
- extern int optind, optreset;
int ch, i, restartit = 0;
sig_t oldintr;
char *cmd, *tp, *xargv[] = { argv[0], NULL, NULL };
Index: usr.bin/ftp/small.c
===
RCS file: /cvs/src/usr.bin/ftp/small.c,v
retrieving revision 1.12
diff -u -p -r1.12 small.c
--- usr.bin/ftp/small.c 18 Nov 2019 04:37:35 - 1.12
+++ usr.bin/ftp/small.c 15 Jul 2020 14:45:14 -
@@ -326,7 +326,6 @@ mabort(int signo)
void
mget(int argc, char *argv[])
{
- extern int optind, optreset;
sig_t oldintr;
int xargc = 2;
char *cp, localcwd[PATH_MAX], *xargv[] = { argv[0], NULL, NULL };
Index: usr.bin/getopt/getopt.c
===
RCS file: /cvs/src/usr.bin/getopt/getopt.c,v
retrieving revision 1.10
diff -u -p -r1.10 getopt.c
--- usr.bin/getopt/getopt.c 9 Oct 2015 01:37:07 - 1.10
+++ usr.bin/getopt/getopt.c 15 Jul 2020 14:45:14 -
@@ -13,8 +13,6 @@
int
main(int argc, char *argv[])
{
- extern int optind;
- extern char *optarg;
int c;
int status = 0;
Index: usr.bin/locate/code/locate.code.c
===
RCS file: /cvs/src/usr.bin/locate/code/locate.code.c,v
retrieving revision 1.21
diff -u -p -r1.21 locate.code.c
--- usr.bin/locate/code/locate.code.c 17 Jan 2019 06:15:44 - 1.21
+++ usr.bin/locate/code/locate.code.c 15 Jul 2020 14:45:14 -
@@ -106,8 +106,6 @@ int bgindex(char *);
void usage(void);
-extern int optind;
-extern int optopt;
int
main(int argc, char *argv[])
Index: usr.bin/m4/main.c
===
RCS file: /cvs/src/usr.bin/m4/main.c,v
retrieving revision 1.87
diff -u -p -r1.87 main.c
--- usr.bin/m4/main.c 15 Jun 2017 13:48:42 - 1.87
+++ usr.bin/m4/main.c 15 Jul 2020 14:45:14 -
@@ -138,9 +138,6 @@ struct keyblk keywrds[] = { /* m4 keywor
#define MAXKEYS(sizeof(keywrds)/sizeof(struct keyblk))
-extern int optind;
-extern char *optarg;
-
#define MAXRECORD 50
static struct position {
char *name;
Index: usr.bin/mklocale/yacc.y
===
RCS file: /cvs/src/usr.bin/mklocale/yacc.y,v
retrieving revision 1.10
diff -u -p -r1.10 yacc.y
--- usr.bin/mklocale/yacc.y 8 May 2016 15:25:44 - 1.10
+++ usr.bin/mklocale/yacc.y 15 Jul 2020 14:45:14 -
@@ -250,9 +250,6 @@ main(int ac, char *av[])
{
int x;
-extern char *optarg;
-extern int optind;
-
if (pledge("stdio rpath wpath cpath", NULL) == -1) {
perror("pledge");
exit(1);
Index:
dd bs= supercede ibs= and obs=
On Feb 14 17:04:51, schwa...@usta.de wrote:
> Jason McIntyre wrote on Fri, Feb 14, 2020 at 07:28:59AM +:
> > On Thu, Feb 13, 2020 at 11:25:07PM +0100, Jan Stary wrote:
> >> * Fix a factual error in the description of bs: it does not
> >> supersede ibs/obs, dd will error out when both are specified.
>
> In fact, that's a bug in the code. POSIX requires:
>
> bs=expr
> Set both input and output block sizes to expr bytes,
> superseding ibs= and obs=.
>
> (see https://pubs.opengroup.org/onlinepubs/9699919799/utilities/dd.html )
This is the line that makes it illegal to specify bs=
if ibs= or obs= (or bs= for that matter) has already been specified.
Jan
Index: args.c
===
RCS file: /cvs/src/bin/dd/args.c,v
retrieving revision 1.31
diff -u -p -r1.31 args.c
--- args.c 16 Feb 2019 10:54:00 - 1.31
+++ args.c 15 Feb 2020 10:05:25 -
@@ -68,7 +68,7 @@ static const struct arg {
void (*f)(char *);
u_int set, noset;
} args[] = {
- { "bs", f_bs, C_BS,C_BS|C_IBS|C_OBS|C_OSYNC },
+ { "bs", f_bs, C_BS,C_BS|C_OSYNC },
{ "cbs",f_cbs, C_CBS, C_CBS },
{ "conv", f_conv, 0, 0 },
{ "count", f_count,C_COUNT, C_COUNT },
Re: dd(1) wording and style
Hi, On Feb 14 17:37:27, schwa...@usta.de wrote: > Hi, > > Jason McIntyre wrote on Fri, Feb 14, 2020 at 07:28:59AM +: > > On Thu, Feb 13, 2020 at 11:25:07PM +0100, Jan Stary wrote: > > >> -.It Cm seek= Ns Ar n > >> +.It Cm seek Ns = Ns Ar n > >> Seek > >> .Ar n > >> blocks from the beginning of the output before copying. > >> -On non-tape devices, an > >> -.Xr lseek 2 > >> -operation is used. > >> -Otherwise, existing blocks are read and the data discarded. > >> -If the user does not have read permission for the tape, it is positioned > >> -using the tape > >> +On a tape device, existing blocks are read and the data discarded; > >> +if the user does not have read permission for the tape, > >> +it is positioned using the tape > >> .Xr ioctl 2 > >> function calls. > >> +On all other devices devices, an > >> +.Xr lseek 2 > >> +operation is used. > >> If the seek operation is past the end of file, space from the current > >> end of file to the specified offset is filled with blocks of NUL bytes. > > > i think this change is ok. however i think non-tape is clearer than "on > > all other devices". it's not a biggie, but i think the current stress on > > non-tape devices is probably intentional. > > The patch is misleading. The sentence "If the seek operation is > past the end of file..." only applies to tape devices, so it must > not follow a sentence about lseek(2). Why does it only apply to tape devices? dd if=/dev/zero of=file bs=1 seek=10 count=1 will seek 10 bytes into the output (filling it with zeros) and then write the 1 byte from input, as intended. -rw-r--r-- 1 hans wheel 11 Feb 15 10:50 file Jan
Re: extern already declared
; RCS file: /cvs/src/regress/lib/libutil/fmt_scaled/fmt_test.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 fmt_test.c
> --- regress/lib/libutil/fmt_scaled/fmt_test.c 16 Mar 2017 02:42:31 -
> 1.15
> +++ regress/lib/libutil/fmt_scaled/fmt_test.c 9 Feb 2020 16:23:49 -
> @@ -36,8 +36,6 @@ __dead static void usage(int stat)
> int
> main(int argc, char **argv)
> {
> - extern char *optarg;
> - extern int optind;
> int i, ch;
>
> while ((ch = getopt(argc, argv, "hv")) != -1) {
>
>
On Feb 09 09:49:35, mill...@openbsd.org wrote:
> On Sun, 09 Feb 2020 17:46:51 +0100, Jan Stary wrote:
>
> > Whenever unistd.h declares getopt(3), it also declares
> > the extern optind and optarg, so files including unistd.h
> > don't need to declare those themselves, right?
>
> Correct. Most of those date back from before optind and optarg
> were defined for you by unistd.h.
So can they be removed now?
Re: remove needless #ifdef
On Feb 10 09:28:38, yasu...@openbsd.org wrote: > Hi, > > On Sun, 09 Feb 2020 19:28:50 +0100 > Jeremie Courreges-Anglas wrote: > > On Sun, Feb 09 2020, Jan Stary wrote: > >> Currently, sys/net/pipex_local.h asks #ifdef __OpenBSD__ > >> and if so, defines "Static" to be nothing, to use it later. > >> That can go away, right? > > > > I believe that's something the IIJ folks want to keep, cc'ing Yasuoka. > > I once thought keeping "static" is better for maintaining the code, > but now I don't think it's necessary. So it's ok to remove them. So can we remove the please? Jan > >> > >> Index: sys/net/pipex_local.h > >> === > >> RCS file: /cvs/src/sys/net/pipex_local.h,v > >> retrieving revision 1.30 > >> diff -u -p -r1.30 pipex_local.h > >> --- sys/net/pipex_local.h 31 Jan 2019 18:01:14 - 1.30 > >> +++ sys/net/pipex_local.h 9 Feb 2020 15:26:51 - > >> @@ -26,12 +26,6 @@ > >> * SUCH DAMAGE. > >> */ > >> > >> -#ifdef __OpenBSD__ > >> -#define Static > >> -#else > >> -#define Static static > >> -#endif > >> - > >> #define PIPEX_PPTP 1 > >> #define PIPEX_L2TP 1 > >> #define PIPEX_PPPOE 1 > >> @@ -372,59 +366,56 @@ extern struct pipex_hash_headpipex_id_h > >> #define PIPEX_TCP_OPTLEN 40 > >> #define PIPEX_L2TP_MINLEN 8 > >> > >> -/* > >> - * static function prototypes > >> - */ > >> -Static void pipex_iface_start (struct > >> pipex_iface_context *); > >> -Static void pipex_iface_stop (struct pipex_iface_context > >> *); > >> -Static int pipex_add_session (struct pipex_session_req > >> *, struct pipex_iface_context *); > >> -Static int pipex_close_session (struct > >> pipex_session_close_req *); > >> -Static int pipex_config_session (struct > >> pipex_session_config_req *); > >> -Static int pipex_get_stat (struct > >> pipex_session_stat_req *); > >> -Static int pipex_get_closed (struct > >> pipex_session_list_req *); > >> -Static int pipex_destroy_session (struct pipex_session > >> *); > >> -Static struct pipex_session *pipex_lookup_by_ip_address (struct in_addr); > >> -Static struct pipex_session *pipex_lookup_by_session_id (int, int); > >> -Static void pipex_ip_output (struct mbuf *, struct > >> pipex_session *); > >> -Static void pipex_ppp_output (struct mbuf *, struct > >> pipex_session *, int); > >> -Static int pipex_ppp_proto (struct mbuf *, struct > >> pipex_session *, int, int *); > >> -Static void pipex_ppp_input (struct mbuf *, struct > >> pipex_session *, int); > >> -Static void pipex_ip_input (struct mbuf *, struct > >> pipex_session *); > >> +void pipex_iface_start (struct pipex_iface_context *); > >> +void pipex_iface_stop (struct pipex_iface_context *); > >> +int pipex_add_session (struct pipex_session_req *, > >> struct pipex_iface_context *); > >> +int pipex_close_session (struct pipex_session_close_req > >> *); > >> +int pipex_config_session (struct > >> pipex_session_config_req *); > >> +int pipex_get_stat (struct pipex_session_stat_req *); > >> +int pipex_get_closed (struct pipex_session_list_req *); > >> +int pipex_destroy_session (struct pipex_session *); > >> +struct pipex_session *pipex_lookup_by_ip_address (struct in_addr); > >> +struct pipex_session *pipex_lookup_by_session_id (int, int); > >> +void pipex_ip_output (struct mbuf *, struct > >> pipex_session *); > >> +void pipex_ppp_output (struct mbuf *, struct > >> pipex_session *, int); > >> +int pipex_ppp_proto (struct mbuf *, struct > >> pipex_session *, int, int *); > >> +void pipex_ppp_input (struct mbuf *, struct > >> pipex_session *, int); > >> +void pipex_ip_input (struct mbuf *, struct pipex_session > >> *); > >> #ifdef INET6
Re: dd(1) wording and style
On Feb 13 23:25:07, h...@stare.cz wrote: > This diff changes the dd(1) manpage in the following ways: > > * Replace "It Cm if= Ns Ar file" with "It Cm if Ns = Ns Ar file" > and similarly for others. The operand is "if", not "if="; > the "Ns = Ns" might be a slightly excessive markup, > but common: grep -Fr 'Ns = Ns' /usr/share/man | wc -l > and is symmetric around the = > > * Fix a factual error in the description of bs: it does not > supersede ibs/obs, dd will error out when both are specified. > > * "On non-tape devices ... Otherwise ..." is a convoluted way > to say "tape"; describe tape first and remove the double negative. > > * Say "It Cm status Ns = Ns Ar value" instead of > > .It Xo > .Sm off > .Cm status= Ar value > .Sm on > .Xc > > * "Where every value" is not a beginning of a sentence. > > * Tweak the wording of osync: regular-sized output block > is enforced in every case, drop the "if not a multiple". > > Jan > > > Index: dd.1 > === > RCS file: /cvs/src/bin/dd/dd.1,v > retrieving revision 1.35 > diff -u -p -r1.35 dd.1 > --- dd.1 16 Feb 2019 17:01:24 - 1.35 > +++ dd.1 13 Feb 2020 21:45:56 - > @@ -57,11 +57,11 @@ and truncated input records to the stand > .Pp > The following operands are available: > .Bl -tag -width of=file > -.It Cm if= Ns Ar file > +.It Cm if Ns = Ns Ar file > Read input from > .Ar file > instead of the standard input. > -.It Cm of= Ns Ar file > +.It Cm of Ns = Ns Ar file > Write output to > .Ar file > instead of the standard output. > @@ -72,22 +72,24 @@ If an initial portion of the output file > .Cm seek > operand), > the output file is truncated at that point. > -.It Cm ibs= Ns Ar n > +.It Cm ibs Ns = Ns Ar n > Set the input block size to > .Ar n > bytes instead of the default 512. > -.It Cm obs= Ns Ar n > +.It Cm obs Ns = Ns Ar n > Set the output block size to > .Ar n > bytes instead of the default 512. > -.It Cm bs= Ns Ar n > +.It Cm bs Ns = Ns Ar n > Set both the input and output block size to > .Ar n > -bytes, superseding the > +bytes. > +It is an error to specify both > +.Cm bs > +and either of > .Cm ibs > -and > -.Cm obs > -operands. > +or > +.Cm obs . > If no conversion values other than > .Cm noerror , > .Cm notrunc , > @@ -95,36 +97,36 @@ or > .Cm sync > are specified, then each input block is copied to the output as a > single block without any aggregation of short blocks. > -.It Cm cbs= Ns Ar n > +.It Cm cbs Ns = Ns Ar n > Set the conversion record size to > .Ar n > bytes. > The conversion record size is required by the record oriented conversion > values. > -.It Cm count= Ns Ar n > +.It Cm count Ns = Ns Ar n > Copy only > .Ar n > input blocks. > -.It Cm files= Ns Ar n > +.It Cm files Ns = Ns Ar n > Copy > .Ar n > input files before terminating. > This operand is only applicable when the input device is a tape. > -.It Cm seek= Ns Ar n > +.It Cm seek Ns = Ns Ar n > Seek > .Ar n > blocks from the beginning of the output before copying. > -On non-tape devices, an > -.Xr lseek 2 > -operation is used. > -Otherwise, existing blocks are read and the data discarded. > -If the user does not have read permission for the tape, it is positioned > -using the tape > +On a tape device, existing blocks are read and the data discarded; > +if the user does not have read permission for the tape, > +it is positioned using the tape > .Xr ioctl 2 > function calls. > +On all other devices devices, an devices devices sorry > +.Xr lseek 2 > +operation is used. > If the seek operation is past the end of file, space from the current > end of file to the specified offset is filled with blocks of NUL bytes. > -.It Cm skip= Ns Ar n > +.It Cm skip Ns = Ns Ar n > Skip > .Ar n > blocks from the beginning of the input before copying. > @@ -135,14 +137,10 @@ Otherwise, input data is read and discar > For pipes, the correct number of bytes is read. > For all other devices, the correct number of blocks is read without > distinguishing between a partial or complete block being read. > -.It Xo > -.Sm off > -.Cm status= Ar value > -.Sm on > -.Xc > -Where > +.It Cm status Ns = Ns Ar value > +where > .Ar value > -is one of the symbols from the following list. > +is one of following. > .Bl -tag -width unblock > .It Cm noxfer > Do not print the transfer statistics as the last line of status output. > @@ -150,15 +148,10 @@ Do not print the transfer statistics as > Do not print the status output. > Error messages are shown; informational messages are not. > .El > -.It Xo > -.Sm off > -.Cm conv= Ar value Oo , > -.Sm on > -.Ar value ... Oc > -.Xc > -Where > +.It Cm conv Ns = Ns Ar value Ns Op , Ns Ar value , Ns ... > +where every > .Ar value > -is one of the symbols from the following list. > +is one of the following. > .Bl -tag -width unblock > .It Cm ascii > The same as the > @@ -235,13 +228,11 @@
dd(1) wording and style
This diff changes the dd(1) manpage in the following ways: * Replace "It Cm if= Ns Ar file" with "It Cm if Ns = Ns Ar file" and similarly for others. The operand is "if", not "if="; the "Ns = Ns" might be a slightly excessive markup, but common: grep -Fr 'Ns = Ns' /usr/share/man | wc -l and is symmetric around the = * Fix a factual error in the description of bs: it does not supersede ibs/obs, dd will error out when both are specified. * "On non-tape devices ... Otherwise ..." is a convoluted way to say "tape"; describe tape first and remove the double negative. * Say "It Cm status Ns = Ns Ar value" instead of .It Xo .Sm off .Cm status= Ar value .Sm on .Xc * "Where every value" is not a beginning of a sentence. * Tweak the wording of osync: regular-sized output block is enforced in every case, drop the "if not a multiple". Jan Index: dd.1 === RCS file: /cvs/src/bin/dd/dd.1,v retrieving revision 1.35 diff -u -p -r1.35 dd.1 --- dd.116 Feb 2019 17:01:24 - 1.35 +++ dd.113 Feb 2020 21:45:56 - @@ -57,11 +57,11 @@ and truncated input records to the stand .Pp The following operands are available: .Bl -tag -width of=file -.It Cm if= Ns Ar file +.It Cm if Ns = Ns Ar file Read input from .Ar file instead of the standard input. -.It Cm of= Ns Ar file +.It Cm of Ns = Ns Ar file Write output to .Ar file instead of the standard output. @@ -72,22 +72,24 @@ If an initial portion of the output file .Cm seek operand), the output file is truncated at that point. -.It Cm ibs= Ns Ar n +.It Cm ibs Ns = Ns Ar n Set the input block size to .Ar n bytes instead of the default 512. -.It Cm obs= Ns Ar n +.It Cm obs Ns = Ns Ar n Set the output block size to .Ar n bytes instead of the default 512. -.It Cm bs= Ns Ar n +.It Cm bs Ns = Ns Ar n Set both the input and output block size to .Ar n -bytes, superseding the +bytes. +It is an error to specify both +.Cm bs +and either of .Cm ibs -and -.Cm obs -operands. +or +.Cm obs . If no conversion values other than .Cm noerror , .Cm notrunc , @@ -95,36 +97,36 @@ or .Cm sync are specified, then each input block is copied to the output as a single block without any aggregation of short blocks. -.It Cm cbs= Ns Ar n +.It Cm cbs Ns = Ns Ar n Set the conversion record size to .Ar n bytes. The conversion record size is required by the record oriented conversion values. -.It Cm count= Ns Ar n +.It Cm count Ns = Ns Ar n Copy only .Ar n input blocks. -.It Cm files= Ns Ar n +.It Cm files Ns = Ns Ar n Copy .Ar n input files before terminating. This operand is only applicable when the input device is a tape. -.It Cm seek= Ns Ar n +.It Cm seek Ns = Ns Ar n Seek .Ar n blocks from the beginning of the output before copying. -On non-tape devices, an -.Xr lseek 2 -operation is used. -Otherwise, existing blocks are read and the data discarded. -If the user does not have read permission for the tape, it is positioned -using the tape +On a tape device, existing blocks are read and the data discarded; +if the user does not have read permission for the tape, +it is positioned using the tape .Xr ioctl 2 function calls. +On all other devices devices, an +.Xr lseek 2 +operation is used. If the seek operation is past the end of file, space from the current end of file to the specified offset is filled with blocks of NUL bytes. -.It Cm skip= Ns Ar n +.It Cm skip Ns = Ns Ar n Skip .Ar n blocks from the beginning of the input before copying. @@ -135,14 +137,10 @@ Otherwise, input data is read and discar For pipes, the correct number of bytes is read. For all other devices, the correct number of blocks is read without distinguishing between a partial or complete block being read. -.It Xo -.Sm off -.Cm status= Ar value -.Sm on -.Xc -Where +.It Cm status Ns = Ns Ar value +where .Ar value -is one of the symbols from the following list. +is one of following. .Bl -tag -width unblock .It Cm noxfer Do not print the transfer statistics as the last line of status output. @@ -150,15 +148,10 @@ Do not print the transfer statistics as Do not print the status output. Error messages are shown; informational messages are not. .El -.It Xo -.Sm off -.Cm conv= Ar value Oo , -.Sm on -.Ar value ... Oc -.Xc -Where +.It Cm conv Ns = Ns Ar value Ns Op , Ns Ar value , Ns ... +where every .Ar value -is one of the symbols from the following list. +is one of the following. .Bl -tag -width unblock .It Cm ascii The same as the @@ -235,13 +228,11 @@ The value is not supported for tapes. .It Cm osync Pad the final output block to the full output block size. -If the input file is not a multiple of the output block size -after conversion, this conversion forces the final output block -to be the same size as preceding blocks for use on devices that require +This forces the final output block to be the same size +as preceding
Re: Audio control API, part 1: libsndio, sndiod bits
On Feb 12 21:38:56, a...@caoua.org wrote: > On Wed, Feb 12, 2020 at 09:22:20PM +0100, Jan Stary wrote: > > Hi, > > > > On Feb 09 13:13:02, a...@caoua.org wrote: > > > cd /usr/src > > > patch -p0 <1.diff > > > patch -p0 <2.diff > > > patch -p0 <3.diff > > > cd /usr/src/include && doas make includes > > > cd /usr/src/lib/libsndio && make obj && make && doas make install > > > cd /usr/src/lib/libossaudio && make obj && make && doas make install > > > cd /usr/src/usr.bin/sndiod && make obj && make && doas make install > > > cd /usr/src/usr.bin/sndioctl && make obj && make && doas make install > > > doas rcctl restart sndiod > > > > > > I'm very interested in any regression. > > > > After restarting sndiod (with empty flags), > > starting sndioctl -m makes sndiod crash with > > > > Feb 12 21:02:31 box /bsd: sndiod[95433]: pledge "tty", syscall 54 > > > > That's ioctl(2). I don't see that in any of the three pledge(2) calls > > revealed by a grep in (the patched) .../sndiod/, but apparently > > the new code does call ioctl(). > > sndiod does unauthorized ioctls on this kernel, see below > > > > > Strangely, this happens on > > > > OpenBSD 6.6-current (GENERIC.MP) #0: Tue Feb 4 17:33:19 CET 2020 > > h...@box.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > but not on > > > > OpenBSD 6.6-current (GENERIC.MP) #0: Sun Feb 9 17:30:47 CET 2020 > > h...@dell.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > (Did I miss somethong pledge() related in that window?) > > > > Yes, there was a kernel commit to allow programs with the "audio" > promise (like sndiod) to use the mixer ioctl()s. Indeed, the problem disappears with the current curent. Sorry for the noise. Jan
Re: Audio control API, part 1: libsndio, sndiod bits
Hi, On Feb 09 13:13:02, a...@caoua.org wrote: > cd /usr/src > patch -p0 <1.diff > patch -p0 <2.diff > patch -p0 <3.diff > cd /usr/src/include && doas make includes > cd /usr/src/lib/libsndio && make obj && make && doas make install > cd /usr/src/lib/libossaudio && make obj && make && doas make install > cd /usr/src/usr.bin/sndiod && make obj && make && doas make install > cd /usr/src/usr.bin/sndioctl && make obj && make && doas make install > doas rcctl restart sndiod > cd /usr/ports > patch -p0 <4.diff > cd /usr/ports/audio/gqmpeg && make && make install > cd /usr/ports/sysutils/tray-app && make && make install > > Feedback about the new features > is of course welcome as well. sndioctl -m works fine with e.g. mplayer, i.e. sndioctl notices the "added" app, and reports the volume changes. With ffplay and firefox:youtube, volume changes are not reported. Is that expected? Do they tweak their "internal" volume knob but not the volume they register with sndio? As opposed to mplayer? At any rate, thanks for the new tool! Jan
Re: Audio control API, part 1: libsndio, sndiod bits
Hi, On Feb 09 13:13:02, a...@caoua.org wrote: > cd /usr/src > patch -p0 <1.diff > patch -p0 <2.diff > patch -p0 <3.diff > cd /usr/src/include && doas make includes > cd /usr/src/lib/libsndio && make obj && make && doas make install > cd /usr/src/lib/libossaudio && make obj && make && doas make install > cd /usr/src/usr.bin/sndiod && make obj && make && doas make install > cd /usr/src/usr.bin/sndioctl && make obj && make && doas make install > doas rcctl restart sndiod > > I'm very interested in any regression. After restarting sndiod (with empty flags), starting sndioctl -m makes sndiod crash with Feb 12 21:02:31 box /bsd: sndiod[95433]: pledge "tty", syscall 54 That's ioctl(2). I don't see that in any of the three pledge(2) calls revealed by a grep in (the patched) .../sndiod/, but apparently the new code does call ioctl(). Strangely, this happens on OpenBSD 6.6-current (GENERIC.MP) #0: Tue Feb 4 17:33:19 CET 2020 h...@box.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP but not on OpenBSD 6.6-current (GENERIC.MP) #0: Sun Feb 9 17:30:47 CET 2020 h...@dell.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP (Did I miss somethong pledge() related in that window?) Jan
Re: don't try to signal with newsyslog -r
On Feb 10 14:53:33, mill...@openbsd.org wrote: > On Mon, 10 Feb 2020 17:12:53 +0100, Jan Stary wrote: > > > The -r option of newsyslog(8) removes the requirement > > that newsyslog runs as root. Would it also make sense > > to not try to send the SIGHUP to syslogd in that case? > > This seems wrong to me. You are disabling more than just sending > a signal to SIGHUP, this will cause newsyslog to ignore *all* pid > files. Yes; it is wrong. A better way to avoid trying to send the signal seems to be to simply specify an empty command in the config file. Jan
Re: don't try to signal with newsyslog -r
Hi Ingo,
On Feb 10 22:40:20, schwa...@usta.de wrote:
> > The -r option of newsyslog(8) removes the requirement
> > that newsyslog runs as root. Would it also make sense
> > to not try to send the SIGHUP to syslogd in that case?
>
> While i'm not sure that i want to take care of this patch,
> given that i'm not quite sure what the point of the -r option
> even is in the first place,
for example, I use it to rotate ~/battery/battery.log on my laptop
upon boot, obtaining a concise history of the battery's life.
Without -r, newsyslog would refuse to run. It is my impression
that this is the inteded use: people rotating their own logs,
not just system logs. I don't know why newsyslog refuses to run
without root, creating a "need" for -r in the first place,
> i'd like to point out that you
> are also removing the warning. Is that intentional?
Yes.
> Naively, getting a warning when files are rotated but the
> daemon isn't notified seems useful to me, even if you kind
> of requested it with -r.
>
> In that case, wouldn't it make more sense to say something
> like (untested, and no code auditing done)
>
> else if (needroot == 0 || kill(pid, signal))
>
> ?
>
> That would also avoid the hopeless attempt to send a signal,
> but would still print the warning.
Sorry for being unclear.
The log I am rotating is not written by syslog; it is written
by my user's cronjob (basicaly saving the voltage and capacity
from hw.sensors.acpibat0 every cron minutes). Given that, and
the fact that I am not running newsyslog as root, I don't need
or expect to signal syslog; the warning then only informs me
about the hopeless attempt to send the signal.
Jan
> > Index: newsyslog.8
> > ===
> > RCS file: /cvs/src/usr.bin/newsyslog/newsyslog.8,v
> > retrieving revision 1.54
> > diff -u -p -r1.54 newsyslog.8
> > --- newsyslog.8 20 Jul 2017 18:39:16 - 1.54
> > +++ newsyslog.8 10 Feb 2020 16:08:51 -
> > @@ -124,7 +124,7 @@ Removes the restriction that
> > must be running as root.
> > Note that in this mode
> > .Nm
> > -will not be able to send a
> > +will not try to send a
> > .Dv SIGHUP
> > signal to
> > .Xr syslogd 8 .
> > Index: newsyslog.c
> > ===
> > RCS file: /cvs/src/usr.bin/newsyslog/newsyslog.c,v
> > retrieving revision 1.112
> > diff -u -p -r1.112 newsyslog.c
> > --- newsyslog.c 28 Jun 2019 13:35:02 - 1.112
> > +++ newsyslog.c 10 Feb 2020 16:08:51 -
> > @@ -394,7 +394,7 @@ send_signal(char *pidfile, int signal)
> > warnx("%s pid file: %s", err, pidfile);
> > else if (noaction)
> > (void)printf("kill -%s %ld\n", sys_signame[signal], (long)pid);
> > - else if (kill(pid, signal))
> > + else if (needroot && kill(pid, signal))
> > warnx("warning - could not send SIG%s to PID from pid file %s",
> > sys_signame[signal], pidfile);
> > }
>
>
don't try to signal with newsyslog -r
The -r option of newsyslog(8) removes the requirement
that newsyslog runs as root. Would it also make sense
to not try to send the SIGHUP to syslogd in that case?
Jan
Index: newsyslog.8
===
RCS file: /cvs/src/usr.bin/newsyslog/newsyslog.8,v
retrieving revision 1.54
diff -u -p -r1.54 newsyslog.8
--- newsyslog.8 20 Jul 2017 18:39:16 - 1.54
+++ newsyslog.8 10 Feb 2020 16:08:51 -
@@ -124,7 +124,7 @@ Removes the restriction that
must be running as root.
Note that in this mode
.Nm
-will not be able to send a
+will not try to send a
.Dv SIGHUP
signal to
.Xr syslogd 8 .
Index: newsyslog.c
===
RCS file: /cvs/src/usr.bin/newsyslog/newsyslog.c,v
retrieving revision 1.112
diff -u -p -r1.112 newsyslog.c
--- newsyslog.c 28 Jun 2019 13:35:02 - 1.112
+++ newsyslog.c 10 Feb 2020 16:08:51 -
@@ -394,7 +394,7 @@ send_signal(char *pidfile, int signal)
warnx("%s pid file: %s", err, pidfile);
else if (noaction)
(void)printf("kill -%s %ld\n", sys_signame[signal], (long)pid);
- else if (kill(pid, signal))
+ else if (needroot && kill(pid, signal))
warnx("warning - could not send SIG%s to PID from pid file %s",
sys_signame[signal], pidfile);
}
setlocale() in cron
Why does cron(8) and crontab(1) need to setlocale()? Jan Index: cron.c === RCS file: /cvs/src/usr.sbin/cron/cron.c,v retrieving revision 1.77 diff -u -p -r1.77 cron.c --- cron.c 23 Oct 2017 15:15:22 - 1.77 +++ cron.c 10 Feb 2020 12:12:13 - @@ -28,7 +28,6 @@ #include #include #include -#include #include #include #include @@ -83,8 +82,6 @@ main(int argc, char *argv[]) struct sigaction sact; sigset_t blocked, omask; struct group *grp; - - setlocale(LC_ALL, ""); setvbuf(stdout, NULL, _IOLBF, 0); setvbuf(stderr, NULL, _IOLBF, 0); Index: crontab.c === RCS file: /cvs/src/usr.sbin/cron/crontab.c,v retrieving revision 1.93 diff -u -p -r1.93 crontab.c --- crontab.c 28 Jun 2019 13:32:47 - 1.93 +++ crontab.c 10 Feb 2020 12:12:13 - @@ -26,7 +26,6 @@ #include #include #include -#include #include #include #include @@ -92,7 +91,6 @@ main(int argc, char *argv[]) user_gid = getgid(); crontab_gid = getegid(); - setlocale(LC_ALL, ""); openlog(__progname, LOG_PID, LOG_CRON); setvbuf(stderr, NULL, _IOLBF, 0);
cp.c and rm.c embedded in mv(1)
mv code contains copies of cp.c and rm.c - is that so that mv can avoid the fork+exec (and call the relevant cp/rm code itself)? If so, is it so that mv can be pledged? It isn't. There must be something worth the duplication ... Jan
Re: Add -R alias to -r for scp(1)
On Jan 02 11:30:35, es...@nerim.net wrote: > Once in three times, I type scp -R and go "oh fuck" when it doesn't work. Same here with 'ssh -p' vs 'scp -P'.
remove the 'support' for troff fonts in lp[rd]
(Replying to an old thread)
On Jan 28 12:06:42, chrisbenn...@bennettconstruction.us wrote:
> #define _PATH_VFONT "/usr/libdata/vfont/"
> #define _PATH_VFONTB"/usr/libdata/vfont/B"
> #define _PATH_VFONTI"/usr/libdata/vfont/I"
> #define _PATH_VFONTR"/usr/libdata/vfont/R"
> #define _PATH_VFONTS"/usr/libdata/vfont/S"
On Jan 28 11:18:58, todd.mil...@courtesan.com wrote:
> The troff support in lpd is of the old phototypesetter variety. It
> has no real value in today's world. The "ditroff" support is what
> we would consider modern troff.
>
> I think we can safely remove the old font bits and the associated
> control file bits.
The diff below
* removes the nonexistent font support from lpr and lpd
* removes the -1234 options from the code and manpage
* removes the BUGS section mentioning that the nonexistent fonts
must be located at the printserver, where they are not implemented
Jan
Index: usr.sbin/lpd/printer.c
===
RCS file: /cvs/src/usr.sbin/lpd/printer.c,v
retrieving revision 1.2
diff -u -p -r1.2 printer.c
--- usr.sbin/lpd/printer.c 3 Jul 2019 03:24:03 - 1.2
+++ usr.sbin/lpd/printer.c 9 Feb 2020 21:32:41 -
@@ -474,13 +474,6 @@ printjob(const char *cfname, int retry)
log_warnx("strtonum: %s", errstr);
break;
- case '1': /* troff fonts */
- case '2':
- case '3':
- case '4':
- /* XXX not implemented */
- break;
-
default:
if (line[0] < 'a' || line[0] > 'z')
break;
Index: usr.sbin/lpr/common_source/pathnames.h
===
RCS file: /cvs/src/usr.sbin/lpr/common_source/pathnames.h,v
retrieving revision 1.6
diff -u -p -r1.6 pathnames.h
--- usr.sbin/lpr/common_source/pathnames.h 28 Oct 2015 13:25:55 -
1.6
+++ usr.sbin/lpr/common_source/pathnames.h 9 Feb 2020 21:32:41 -
@@ -40,8 +40,3 @@
#define_PATH_PR"/usr/bin/pr"
#define_PATH_PRINTCAP "/etc/printcap"
#define_PATH_SOCKETNAME"/var/run/printer"
-#define_PATH_VFONT "/usr/libdata/vfont/"
-#define_PATH_VFONTB"/usr/libdata/vfont/B"
-#define_PATH_VFONTI"/usr/libdata/vfont/I"
-#define_PATH_VFONTR"/usr/libdata/vfont/R"
-#define_PATH_VFONTS"/usr/libdata/vfont/S"
Index: usr.sbin/lpr/lpd/lpd.8
===
RCS file: /cvs/src/usr.sbin/lpr/lpd/lpd.8,v
retrieving revision 1.30
diff -u -p -r1.30 lpd.8
--- usr.sbin/lpr/lpd/lpd.8 8 Feb 2020 01:09:58 - 1.30
+++ usr.sbin/lpr/lpd/lpd.8 9 Feb 2020 21:32:41 -
@@ -261,18 +261,6 @@ The file contains a raster image.
.It r
The file contains text data with
FORTRAN carriage control characters.
-.It \&1
-Troff Font R.
-Name of the font file to use instead of the default.
-.It \&2
-Troff Font I.
-Name of the font file to use instead of the default.
-.It \&3
-Troff Font B.
-Name of the font file to use instead of the default.
-.It \&4
-Troff Font S.
-Name of the font file to use instead of the default.
.It W
Width.
Changes the page width (in characters) used by
Index: usr.sbin/lpr/lpd/printjob.c
===
RCS file: /cvs/src/usr.sbin/lpr/lpd/printjob.c,v
retrieving revision 1.61
diff -u -p -r1.61 printjob.c
--- usr.sbin/lpr/lpd/printjob.c 3 Jul 2019 03:24:03 - 1.61
+++ usr.sbin/lpr/lpd/printjob.c 9 Feb 2020 21:32:41 -
@@ -316,16 +316,6 @@ again:
goto again;
}
-#defineFONTLEN 50
-char fonts[4][FONTLEN]; /* fonts for troff */
-
-char ifonts[4][40] = {
- _PATH_VFONTR,
- _PATH_VFONTI,
- _PATH_VFONTB,
- _PATH_VFONTS,
-};
-
/*
* The remaining part is the reading of the control file (cf)
* and performing the various actions.
@@ -348,15 +338,6 @@ printit(char *file)
return(OK);
}
/*
-* Reset troff fonts.
-*/
- for (i = 0; i < 4; i++)
- strlcpy(fonts[i], ifonts[i], FONTLEN);
- (void)snprintf([2], sizeof(width) - 2, "%ld", PW);
- indent[2] = '0';
- indent[3] = '\0';
-
- /*
* read the control file for work to do
*
* file format -- first character in the line is a command
@@ -381,10 +362,6 @@ printit(char *file)
* g -- "file name" plot(1G) file to print
* v -- "file name" plain raster file to print
* c -- "file name" cifplot file to print
-* 1 -- "R font file" for
Re: extern already declared
On Feb 09 09:49:35, mill...@openbsd.org wrote: > On Sun, 09 Feb 2020 17:46:51 +0100, Jan Stary wrote: > > > Whenever unistd.h declares getopt(3), it also declares > > the extern optind and optarg, so files including unistd.h > > don't need to declare those themselves, right? > > Correct. Most of those date back from before optind and optarg > were defined for you by unistd.h. But the externs should be mentioned in the manpage, right? That's the only place they are mentioned before being talked about in the text; although I suspect that's why people keep declaring them in source code - it's what SYNOPSIS said. Jan
afile.h not wav.h
The afile.h include has been so named for some time but the corresponding #define has not been changed from WAV_H - not that it matters much of course. Jan Index: afile.h === RCS file: /cvs/src/usr.bin/aucat/afile.h,v retrieving revision 1.1 diff -u -p -r1.1 afile.h --- afile.h 21 Jan 2015 08:43:55 - 1.1 +++ afile.h 9 Feb 2020 17:42:02 - @@ -14,8 +14,8 @@ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -#ifndef WAV_H -#define WAV_H +#ifndef AFILE_H +#define AFILE_H #include #include "dsp.h" @@ -52,4 +52,4 @@ size_t afile_write(struct afile *, void int afile_seek(struct afile *, off_t); void afile_close(struct afile *); -#endif /* !defined(WAV_H) */ +#endif /* !defined(AFILE_H) */
extern already declared
Whenever unistd.h declares getopt(3), it also declares
the extern optind and optarg, so files including unistd.h
don't need to declare those themselves, right?
Jan
Index: games/fortune/strfile/strfile.c
===
RCS file: /cvs/src/games/fortune/strfile/strfile.c,v
retrieving revision 1.29
diff -u -p -r1.29 strfile.c
--- games/fortune/strfile/strfile.c 4 Jun 2017 13:39:25 - 1.29
+++ games/fortune/strfile/strfile.c 9 Feb 2020 16:23:42 -
@@ -252,8 +252,6 @@ main(int ac, char *av[])
void
getargs(int argc, char *argv[])
{
- extern char *optarg;
- extern int optind;
int ch;
while ((ch = getopt(argc, argv, "c:hiorsx")) != -1) {
Index: games/hunt/hunt/hunt.c
===
RCS file: /cvs/src/games/hunt/hunt/hunt.c,v
retrieving revision 1.22
diff -u -p -r1.22 hunt.c
--- games/hunt/hunt/hunt.c 8 Apr 2017 22:50:41 - 1.22
+++ games/hunt/hunt/hunt.c 9 Feb 2020 16:23:42 -
@@ -85,8 +85,6 @@ int
main(int ac, char **av)
{
int c;
- extern int optind;
- extern char *optarg;
longenter_status;
int option;
struct servent *se;
Index: games/hunt/huntd/driver.c
===
RCS file: /cvs/src/games/hunt/huntd/driver.c,v
retrieving revision 1.29
diff -u -p -r1.29 driver.c
--- games/hunt/huntd/driver.c 21 Jan 2017 08:22:57 - 1.29
+++ games/hunt/huntd/driver.c 9 Feb 2020 16:23:42 -
@@ -80,8 +80,6 @@ main(int ac, char **av)
static fd_set read_fds;
static FLAG first = TRUE;
static FLAG server = FALSE;
- extern int optind;
- extern char *optarg;
extern char *__progname;
int c;
static struct timeval linger = { 0, 0 };
Index: games/robots/main.c
===
RCS file: /cvs/src/games/robots/main.c,v
retrieving revision 1.28
diff -u -p -r1.28 main.c
--- games/robots/main.c 28 Jun 2019 13:32:52 - 1.28
+++ games/robots/main.c 9 Feb 2020 16:23:42 -
@@ -56,7 +56,6 @@ main(int ac, char *av[])
int score_err = 0; /* hold errno from score file open */
int ch;
int ret;
- extern int optind;
char*home;
#ifdef FANCY
char*sp;
Index: regress/lib/libc/db/dbtest.c
===
RCS file: /cvs/src/regress/lib/libc/db/dbtest.c,v
retrieving revision 1.16
diff -u -p -r1.16 dbtest.c
--- regress/lib/libc/db/dbtest.c27 Jul 2017 15:08:37 - 1.16
+++ regress/lib/libc/db/dbtest.c9 Feb 2020 16:23:48 -
@@ -76,8 +76,6 @@ int XXlineno; /* Fast breakpoint for
int
main(int argc, char *argv[])
{
- extern int optind;
- extern char *optarg;
enum S command, state;
DB *dbp;
DBT data, key, keydata;
Index: regress/lib/libc/getaddrinfo/gaitest.c
===
RCS file: /cvs/src/regress/lib/libc/getaddrinfo/gaitest.c,v
retrieving revision 1.6
diff -u -p -r1.6 gaitest.c
--- regress/lib/libc/getaddrinfo/gaitest.c 9 Jun 2009 18:15:08 -
1.6
+++ regress/lib/libc/getaddrinfo/gaitest.c 9 Feb 2020 16:23:48 -
@@ -119,8 +119,6 @@ main(argc, argv)
struct addrinfo *res;
int error, i;
char *p, *q;
- extern int optind;
- extern char *optarg;
int c;
char nbuf[10];
Index: regress/lib/libc/regex/main.c
===
RCS file: /cvs/src/regress/lib/libc/regex/main.c,v
retrieving revision 1.10
diff -u -p -r1.10 main.c
--- regress/lib/libc/regex/main.c 13 Jul 2016 06:17:11 - 1.10
+++ regress/lib/libc/regex/main.c 9 Feb 2020 16:23:48 -
@@ -41,8 +41,6 @@ main(int argc, char *argv[])
int c;
int errflg = 0;
register int i;
- extern int optind;
- extern char *optarg;
progname = argv[0];
Index: regress/lib/libutil/fmt_scaled/fmt_test.c
===
RCS file: /cvs/src/regress/lib/libutil/fmt_scaled/fmt_test.c,v
retrieving revision 1.15
diff -u -p -r1.15 fmt_test.c
--- regress/lib/libutil/fmt_scaled/fmt_test.c 16 Mar 2017 02:42:31 -
1.15
+++ regress/lib/libutil/fmt_scaled/fmt_test.c 9 Feb 2020 16:23:49 -
@@ -36,8 +36,6 @@ __dead static void usage(int stat)
int
main(int argc, char **argv)
{
- extern char *optarg;
- extern int optind;
int i, ch;
while ((ch = getopt(argc, argv, "hv")) != -1) {
remove needless #ifdef
Currently, sys/net/pipex_local.h asks #ifdef __OpenBSD__ and if so, defines "Static" to be nothing, to use it later. That can go away, right? Jan Index: sys/net/pipex_local.h === RCS file: /cvs/src/sys/net/pipex_local.h,v retrieving revision 1.30 diff -u -p -r1.30 pipex_local.h --- sys/net/pipex_local.h 31 Jan 2019 18:01:14 - 1.30 +++ sys/net/pipex_local.h 9 Feb 2020 15:26:51 - @@ -26,12 +26,6 @@ * SUCH DAMAGE. */ -#ifdef __OpenBSD__ -#define Static -#else -#define Static static -#endif - #definePIPEX_PPTP 1 #definePIPEX_L2TP 1 #definePIPEX_PPPOE 1 @@ -372,59 +366,56 @@ extern struct pipex_hash_head pipex_id_h #define PIPEX_TCP_OPTLEN 40 #definePIPEX_L2TP_MINLEN 8 -/* - * static function prototypes - */ -Static void pipex_iface_start (struct pipex_iface_context *); -Static void pipex_iface_stop (struct pipex_iface_context *); -Static int pipex_add_session (struct pipex_session_req *, struct pipex_iface_context *); -Static int pipex_close_session (struct pipex_session_close_req *); -Static int pipex_config_session (struct pipex_session_config_req *); -Static int pipex_get_stat (struct pipex_session_stat_req *); -Static int pipex_get_closed (struct pipex_session_list_req *); -Static int pipex_destroy_session (struct pipex_session *); -Static struct pipex_session *pipex_lookup_by_ip_address (struct in_addr); -Static struct pipex_session *pipex_lookup_by_session_id (int, int); -Static void pipex_ip_output (struct mbuf *, struct pipex_session *); -Static void pipex_ppp_output (struct mbuf *, struct pipex_session *, int); -Static int pipex_ppp_proto (struct mbuf *, struct pipex_session *, int, int *); -Static void pipex_ppp_input (struct mbuf *, struct pipex_session *, int); -Static void pipex_ip_input (struct mbuf *, struct pipex_session *); +void pipex_iface_start (struct pipex_iface_context *); +void pipex_iface_stop (struct pipex_iface_context *); +int pipex_add_session (struct pipex_session_req *, struct pipex_iface_context *); +int pipex_close_session (struct pipex_session_close_req *); +int pipex_config_session (struct pipex_session_config_req *); +int pipex_get_stat (struct pipex_session_stat_req *); +int pipex_get_closed (struct pipex_session_list_req *); +int pipex_destroy_session (struct pipex_session *); +struct pipex_session *pipex_lookup_by_ip_address (struct in_addr); +struct pipex_session *pipex_lookup_by_session_id (int, int); +void pipex_ip_output (struct mbuf *, struct pipex_session *); +void pipex_ppp_output (struct mbuf *, struct pipex_session *, int); +int pipex_ppp_proto (struct mbuf *, struct pipex_session *, int, int *); +void pipex_ppp_input (struct mbuf *, struct pipex_session *, int); +void pipex_ip_input (struct mbuf *, struct pipex_session *); #ifdef INET6 -Static void pipex_ip6_input (struct mbuf *, struct pipex_session *); +void pipex_ip6_input (struct mbuf *, struct pipex_session *); #endif -Static struct mbuf *pipex_common_input(struct pipex_session *, struct mbuf *, int, int, int); +struct mbuf *pipex_common_input(struct pipex_session *, struct mbuf *, int, int, int); #ifdef PIPEX_PPPOE -Static void pipex_pppoe_output (struct mbuf *, struct pipex_session *); +void pipex_pppoe_output (struct mbuf *, struct pipex_session *); #endif #ifdef PIPEX_PPTP -Static void pipex_pptp_output (struct mbuf *, struct pipex_session *, int, int); -Static struct pipex_session *pipex_pptp_userland_lookup_session(struct mbuf *, struct sockaddr *); +void pipex_pptp_output (struct mbuf *, struct pipex_session *, int, int); +struct pipex_session *pipex_pptp_userland_lookup_session(struct mbuf *, struct sockaddr *); #endif #ifdef PIPEX_L2TP -Static void pipex_l2tp_output (struct mbuf *, struct pipex_session *); +void pipex_l2tp_output (struct mbuf *, struct pipex_session *); #endif #ifdef PIPEX_MPPE -Static void pipex_mppe_init (struct pipex_mppe *, int, int, u_char *, int); -Static void GetNewKeyFromSHA (u_char *, u_char *, int, u_char *); -Static void pipex_mppe_reduce_key (struct pipex_mppe *); -Static void mppe_key_change (struct pipex_mppe *); -Static void pipex_mppe_input (struct mbuf *, struct
EC_POINT_new.3 glitch
This seems to be a missed newline. Jan Index: EC_POINT_new.3 === RCS file: /cvs/src/lib/libcrypto/man/EC_POINT_new.3,v retrieving revision 1.9 diff -u -p -r1.9 EC_POINT_new.3 --- EC_POINT_new.3 29 Mar 2018 20:56:49 - 1.9 +++ EC_POINT_new.3 18 Mar 2019 07:36:50 - @@ -472,7 +472,8 @@ on error. .Pp .Fn EC_POINT_hex2point returns the pointer to the -.Vt EC_POINT supplied or +.Vt EC_POINT +supplied or .Dv NULL on error. .Sh SEE ALSO
zic(8) unneeded header
zic.c does not need to include Jan Index: zic.c === RCS file: /cvs/src/usr.sbin/zic/zic.c,v retrieving revision 1.22 diff -u -p -r1.22 zic.c --- zic.c 15 Mar 2016 19:50:47 - 1.22 +++ zic.c 11 Jan 2019 21:03:39 - @@ -11,7 +11,6 @@ #include #include #include -#include #include #include #include
locale in locate(1)
Does locate(1) need to setlocale(3)?
Jan
Index: locate/locate.c
===
RCS file: /cvs/src/usr.bin/locate/locate/locate.c,v
retrieving revision 1.31
diff -u -p -r1.31 locate.c
--- locate/locate.c 19 Nov 2015 21:46:05 - 1.31
+++ locate/locate.c 10 Jan 2019 20:34:16 -
@@ -73,7 +73,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -122,7 +121,6 @@ main(int argc, char *argv[])
{
int ch;
char **dbv = NULL;
- (void) setlocale(LC_ALL, "");
if (pledge("stdio rpath", NULL) == -1)
err(1, "pledge");
locale in comm(1)
Does comm(1) need to setlocale(3)?
It uses strcoll(3) by default, which ignores the locale
and does what strcmp(3) does, or strcasecmp(3) with -f,
which ignores the locale too.
So remove the setlocale(3), remove the header,
the LC_ that have been commented out since the initial revision in 1995,
and just use strcmp(3) or strcasecmp(3).
Jan
Index: comm.1
===
RCS file: /cvs/src/usr.bin/comm/comm.1,v
retrieving revision 1.15
diff -u -p -r1.15 comm.1
--- comm.1 3 Sep 2010 11:09:28 - 1.15
+++ comm.1 10 Jan 2019 20:24:35 -
@@ -83,14 +83,6 @@ printed in column number three will have
.Nm
assumes that the files are lexically sorted; all characters
participate in line comparisons.
-.\" .Sh ENVIRONMENT
-.\" .Bl -tag -width indent
-.\" .It Ev LANG
-.\" .It Ev LC_ALL
-.\" .It Ev LC_CTYPE
-.\" .It Ev LC_COLLATE
-.\" .It Ev LC_MESSAGES
-.\" .El
.Sh EXIT STATUS
.Ex -std comm
.Sh SEE ALSO
Index: comm.c
===
RCS file: /cvs/src/usr.bin/comm/comm.c,v
retrieving revision 1.10
diff -u -p -r1.10 comm.c
--- comm.c 9 Oct 2015 01:37:07 - 1.10
+++ comm.c 10 Jan 2019 20:24:35 -
@@ -35,7 +35,6 @@
#include
#include
-#include
#include
#include
#include
@@ -59,13 +58,11 @@ main(int argc, char *argv[])
char **p, line1[MAXLINELEN], line2[MAXLINELEN];
int (*compare)(const char * ,const char *);
- setlocale(LC_ALL, "");
-
if (pledge("stdio rpath", NULL) == -1)
err(1, "pledge");
flag1 = flag2 = flag3 = 1;
- compare = strcoll;
+ compare = strcmp;
while ((ch = getopt(argc, argv, "123f")) != -1)
switch(ch) {
case '1':
LC_TIME in calendar(1)
calendar imho doesn't need to setlocale(LC_TIME, ...) before and after strftime(3), as LC_TIME is ignored. Jan Index: day.c === RCS file: /cvs/src/usr.bin/calendar/day.c,v retrieving revision 1.34 diff -u -p -r1.34 day.c --- day.c 14 Sep 2016 15:09:46 - 1.34 +++ day.c 10 Jan 2019 15:23:45 - @@ -169,11 +169,7 @@ settime(time_t *now) if (f_SetdayAfter) offset = 0; /* Except not when range is set explicitly */ header[5].iov_base = dayname; - - (void) setlocale(LC_TIME, "C"); header[5].iov_len = strftime(dayname, sizeof(dayname), "%A", tp); - (void) setlocale(LC_TIME, ""); - setnnames(); }
Re: LC_NUMERIC in wprintf(3)
On Jan 10 14:43:39, h...@stare.cz wrote: > The wprintf(3) manpage says > > The decimal point character is defined > in the program's locale (category LC_NUMERIC) > > but LC_NUMERIC is ignored in OpenBSD's C library, > as explained in setlocale(3). > > Would it be an improvement to remove that sentence? > (Removing a needless newline while here.) > > Jan > > > Index: wprintf.3 > === > RCS file: /cvs/src/lib/libc/stdio/wprintf.3,v > retrieving revision 1.5 > diff -u -p -r1.5 wprintf.3 > --- wprintf.3 1 Dec 2017 10:56:07 - 1.5 > +++ wprintf.3 10 Jan 2019 13:29:41 - > @@ -578,14 +578,9 @@ is > .Ql %% . > .El > .Pp > -The decimal point > -character is defined in the program's locale (category > -.Dv LC_NUMERIC ) . > -.Pp > In no case does a non-existent or small field width cause truncation of > a numeric field; if the result of a conversion is wider than the field > -width, the > -field is expanded to contain the conversion result. > +width, the field is expanded to contain the conversion result. > .Sh SEE ALSO > .Xr btowc 3 , > .Xr fputws 3 , same for wscanf(3): Index: wscanf.3 === RCS file: /cvs/src/lib/libc/stdio/wscanf.3,v retrieving revision 1.2 diff -u -p -r1.2 wscanf.3 --- wscanf.32 Nov 2011 22:29:07 - 1.2 +++ wscanf.310 Jan 2019 14:14:08 - @@ -389,10 +389,6 @@ a conversion, although it can be suppres flag. .El .Pp -The decimal point -character is defined in the program's locale (category -.Dv LC_NUMERIC ) . -.Pp For backwards compatibility, a .Dq conversion of
LC_NUMERIC in wprintf(3)
The wprintf(3) manpage says The decimal point character is defined in the program's locale (category LC_NUMERIC) but LC_NUMERIC is ignored in OpenBSD's C library, as explained in setlocale(3). Would it be an improvement to remove that sentence? (Removing a needless newline while here.) Jan Index: wprintf.3 === RCS file: /cvs/src/lib/libc/stdio/wprintf.3,v retrieving revision 1.5 diff -u -p -r1.5 wprintf.3 --- wprintf.3 1 Dec 2017 10:56:07 - 1.5 +++ wprintf.3 10 Jan 2019 13:29:41 - @@ -578,14 +578,9 @@ is .Ql %% . .El .Pp -The decimal point -character is defined in the program's locale (category -.Dv LC_NUMERIC ) . -.Pp In no case does a non-existent or small field width cause truncation of a numeric field; if the result of a conversion is wider than the field -width, the -field is expanded to contain the conversion result. +width, the field is expanded to contain the conversion result. .Sh SEE ALSO .Xr btowc 3 , .Xr fputws 3 ,
Re: pcap_dispatch() returning zero
No really, it reads 20 packets and returns zero.
On Dec 08 13:56:09, h...@stare.cz wrote:
> The return value of pcap_dispatch() is described in pcap.3 as follows:
>
> The number of packets read is returned.
> Zero is returned when EOF is reached in a savefile.
> A return of -1 indicates an error in which case ...
>
> It will also return zero on the last short read (as "EOF is reached").
> So if you read the packets in chunks of 100, like
>
> while ((r = pcap_dispatch(src, 100, callback, NULL)) > 0) {
> /* ... */
> }
> if (r == 0) {
> /* EOF */
> } else if (r == -1) {
> /* ERROR */
> }
>
> and the file contains 120 packets, you will have
> r == 100 the first time (reading 100 packets) and
> r == 0 the second time (reading 20 packets).
>
> It seems there is no way for the caller to know
> how many packets were actually there in the last short read
> besides counting the packets himself in the callback().
>
> Is that intended? It seems more natural, and less surprising,
> to have it return the actual number of packets. That would make
> the sequence above 100, then 20, then 0 (like read(2) does).
>
> Anyway, should this be explicitly mentioned in the manpage?
>
> Jan
>
>
> Index: pcap.3
> ===
> RCS file: /cvs/src/lib/libpcap/pcap.3,v
> retrieving revision 1.48
> diff -u -p -r1.48 pcap.3
> --- pcap.33 Jun 2018 10:45:15 - 1.48
> +++ pcap.38 Dec 2018 12:53:59 -
> @@ -345,7 +345,11 @@ and a
> .Fa u_char
> pointer to the packet data.
> The number of packets read is returned.
> -Zero is returned when EOF is reached in a savefile.
> +Zero is returned when EOF is reached in a savefile;
> +this includes a short read near the end of savefile,
> +when less than
> +.Fa cnt
> +packets are available.
> A return of \-1 indicates an error in which case
> .Fn pcap_perror
> or
>
Re: pcap_dispatch() returning zero
ping
On Dec 08 13:56:09, h...@stare.cz wrote:
> The return value of pcap_dispatch() is described in pcap.3 as follows:
>
> The number of packets read is returned.
> Zero is returned when EOF is reached in a savefile.
> A return of -1 indicates an error in which case ...
>
> It will also return zero on the last short read (as "EOF is reached").
> So if you read the packets in chunks of 100, like
>
> while ((r = pcap_dispatch(src, 100, callback, NULL)) > 0) {
> /* ... */
> }
> if (r == 0) {
> /* EOF */
> } else if (r == -1) {
> /* ERROR */
> }
>
> and the file contains 120 packets, you will have
> r == 100 the first time (reading 100 packets) and
> r == 0 the second time (reading 20 packets).
>
> It seems there is no way for the caller to know
> how many packets were actually there in the last short read
> besides counting the packets himself in the callback().
>
> Is that intended? It seems more natural, and less surprising,
> to have it return the actual number of packets. That would make
> the sequence above 100, then 20, then 0 (like read(2) does).
>
> Anyway, should this be explicitly mentioned in the manpage?
>
> Jan
>
>
> Index: pcap.3
> ===
> RCS file: /cvs/src/lib/libpcap/pcap.3,v
> retrieving revision 1.48
> diff -u -p -r1.48 pcap.3
> --- pcap.33 Jun 2018 10:45:15 - 1.48
> +++ pcap.38 Dec 2018 12:53:59 -
> @@ -345,7 +345,11 @@ and a
> .Fa u_char
> pointer to the packet data.
> The number of packets read is returned.
> -Zero is returned when EOF is reached in a savefile.
> +Zero is returned when EOF is reached in a savefile;
> +this includes a short read near the end of savefile,
> +when less than
> +.Fa cnt
> +packets are available.
> A return of \-1 indicates an error in which case
> .Fn pcap_perror
> or
>
[no subject]
Currently, pcap_setdirection() is described in pcap.3 as follows: pcap_setdirection() is used to limit the direction that packets must be flowing in order to be captured. The "direction" is not described, except in pcap.h. Should the constants be mentioned in the manpage? Also, the direction only seems to matter for live captures. Jan Index: pcap.3 === RCS file: /cvs/src/lib/libpcap/pcap.3,v retrieving revision 1.48 diff -u -p -r1.48 pcap.3 --- pcap.3 3 Jun 2018 10:45:15 - 1.48 +++ pcap.3 10 Dec 2018 07:12:53 - @@ -535,6 +535,15 @@ datalink types. .Fn pcap_setdirection is used to limit the direction that packets must be flowing in order to be captured. +The direction is either +.Dv PCAP_D_INOUT , +.Dv PCAP_D_IN +or +.Dv PCAP_D_OUT . +Direction is only relevant to live captures. +When reading from a dump file, +.Fn pcap_setdirection +has no effect . .Pp .Fn pcap_list_datalinks returns an array of the supported datalink types for an opened live capture
pcap_dump() arguments
pcap_dump() is described in pcap.3 as follows: pcap_dump() outputs a packet to the savefile opened with pcap_dump_open(). Note that its calling arguments are suitable for use with pcap_dispatch(). That formulation is imho not entirely clear, as the arguments mention no "savefile". (Looking at the source, it just treats the 'user' argument as a FILE* which is what a pcap_dumper_t* returned by pcap_dump_open() really is, and fwrite()s the header and packet data there.) It would be clearer if the manpage said that the 'user' is the savefile, and that it is to be passed as the last argument to pcap_dispatch() when using pcap_dump() as a callback function. Jan Index: pcap.3 === RCS file: /cvs/src/lib/libpcap/pcap.3,v retrieving revision 1.48 diff -u -p -r1.48 pcap.3 --- pcap.3 3 Jun 2018 10:45:15 - 1.48 +++ pcap.3 10 Dec 2018 07:01:13 - @@ -353,9 +353,17 @@ or may be used to display the error text. .Pp .Fn pcap_dump -outputs a packet to the savefile opened with -.Fn pcap_dump_open . -Note that its calling arguments are suitable for use with +outputs a packet to a previously opened savefile, +if the pointer obtained with +.Fn pcap_dump_open +is passed as the +.Fa user +argument. +This makes +.Fn pcap_dump +a suitable +.Fa callback +to use with .Fn pcap_dispatch . .Pp .Fn pcap_inject
pcap_dispatch() returning zero
The return value of pcap_dispatch() is described in pcap.3 as follows:
The number of packets read is returned.
Zero is returned when EOF is reached in a savefile.
A return of -1 indicates an error in which case ...
It will also return zero on the last short read (as "EOF is reached").
So if you read the packets in chunks of 100, like
while ((r = pcap_dispatch(src, 100, callback, NULL)) > 0) {
/* ... */
}
if (r == 0) {
/* EOF */
} else if (r == -1) {
/* ERROR */
}
and the file contains 120 packets, you will have
r == 100 the first time (reading 100 packets) and
r == 0 the second time (reading 20 packets).
It seems there is no way for the caller to know
how many packets were actually there in the last short read
besides counting the packets himself in the callback().
Is that intended? It seems more natural, and less surprising,
to have it return the actual number of packets. That would make
the sequence above 100, then 20, then 0 (like read(2) does).
Anyway, should this be explicitly mentioned in the manpage?
Jan
Index: pcap.3
===
RCS file: /cvs/src/lib/libpcap/pcap.3,v
retrieving revision 1.48
diff -u -p -r1.48 pcap.3
--- pcap.3 3 Jun 2018 10:45:15 - 1.48
+++ pcap.3 8 Dec 2018 12:53:59 -
@@ -345,7 +345,11 @@ and a
.Fa u_char
pointer to the packet data.
The number of packets read is returned.
-Zero is returned when EOF is reached in a savefile.
+Zero is returned when EOF is reached in a savefile;
+this includes a short read near the end of savefile,
+when less than
+.Fa cnt
+packets are available.
A return of \-1 indicates an error in which case
.Fn pcap_perror
or
ifconfig DIAGNOSTICS
The wording of ifconfig DIAGNOSTICS can possibly baffle a non-native speaker (such as me) with Messages indicating the specified interface does not exist, namely, only after parsing the (non)sentence does one realize that the diagnostics consists of messages indicating THAT the interface does not exist etc. As the paragraph does not list the messages (surely there are many), this really boils down to mentioning that ifconfig does indeed have diagnostic messages. I believe nothing would be lost if this paragraph was deleted. Jan Index: ifconfig.8 === RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v retrieving revision 1.319 diff -u -p -r1.319 ifconfig.8 --- ifconfig.8 8 Sep 2018 15:21:03 - 1.319 +++ ifconfig.8 22 Oct 2018 06:35:01 - @@ -1871,10 +1871,6 @@ Create the gif1 network interface: Put the athn0 wireless interface into monitor mode: .Pp .Dl # ifconfig athn0 mediaopt monitor -.Sh DIAGNOSTICS -Messages indicating the specified interface does not exist, the -requested address is unknown, or the user is not privileged and -tried to alter an interface's configuration. .Sh SEE ALSO .Xr netstat 1 , .Xr ifmedia 4 ,
interpolation -> interpretation
I am not a native speaker, but printf(3) "interprets" the conversion specifiers, it does not "interpolate" them, right? Jan Index: printf.3 === RCS file: /cvs/src/lib/libc/stdio/printf.3,v retrieving revision 1.78 diff -u -p -r1.78 printf.3 --- printf.32 Jan 2018 08:05:03 - 1.78 +++ printf.311 Apr 2018 20:53:05 - @@ -870,7 +870,7 @@ This holds true even if the string has b using a function like .Fn snprintf , as the resulting string may still contain user-supplied conversion specifiers -for later interpolation by +for later interpretation by .Fn printf . .Pp Be sure to use the proper secure idiom:
/usr/local/sbin in default PATH?
Both _PATH_DEFPATH and _PATH_STDPATH, as defined in paths.h, include /usr/local/bin but not /usr/local/sbin, as opposed to /usr/bin:/bin:/usr/sbin:/sbin. Is that intentional? Jan Index: include/paths.h === RCS file: /cvs/src/include/paths.h,v retrieving revision 1.25 diff -u -p -r1.25 paths.h --- include/paths.h 13 Mar 2014 15:24:41 - 1.25 +++ include/paths.h 6 Dec 2017 12:43:29 - @@ -36,9 +36,9 @@ #define_PATHS_H_ /* Default search path. */ -#define_PATH_DEFPATH "/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin" +#define_PATH_DEFPATH "/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin" /* All standard utilities path. */ -#define_PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin" +#define_PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin" #define_PATH_BSHELL"/bin/sh" #define_PATH_CONSOLE "/dev/console" Index: share/man/man7/environ.7 === RCS file: /cvs/src/share/man/man7/environ.7,v retrieving revision 1.19 diff -u -p -r1.19 environ.7 --- share/man/man7/environ.710 Sep 2015 18:47:57 - 1.19 +++ share/man/man7/environ.76 Dec 2017 12:43:29 - @@ -99,8 +99,9 @@ but expanded to include .Pa /usr/sbin , .Pa /sbin , .Pa /usr/X11R6/bin , -and .Pa /usr/local/bin +and +.Pa /usr/local/sbin in .Ox . .It Ev PRINTER
