Re: Grammar and style edits to installation guide
Jason McIntyre wrote:
> On Tue, Jul 09, 2019 at 07:43:50AM +0200, Otto Moerbeek wrote:
> > On Mon, Jul 08, 2019 at 10:26:57AM -0700, Evan Silberman wrote:
> >
> > I don't know our stance on Unix vs Un*x. I'll leave this to some
> > native speaker, like jmc@ who knows all about commas (and much more)
> > :-)
> >
> > -Otto
> >
>
> hi.
>
> i'm fairly sure Un*x is meant to denote the various flavours of unix,
> and is probably pretty widespread in our docs. however i haven;t checked
> that. i don;t really see a reason to change it unless we've somehow
> decided that it doesn;t make sense and we make such changes wholesale.
I think it makes sense to write "Unix-like" instead of "Un*x-like" or
"UN*X-like" wherever it appears in the general case; it is more legible
to lay readers and conveys basically the same information. The homepage
reads "UNIX-like". (I also would propose that the all-caps styling is at
best something of a throwback and "Unix" should be preferred unless the
developers are extremely fond of the caps, but that's neither here nor
there.)
>
> i'll try to comment on the rest of the diff inline..
>
> > I'll leave this to jmc or some other native speaker. S
> > > Otto Moerbeek wrote:
> > > > On Sun, Jul 07, 2019 at 10:44:42PM -0700, Evan Silberman wrote:
> > > >
> > > > > I noticed one thing that bothered me and decided to look for other
> > > > > things that bothered me. Changes were made without reference to the
> > > > > code
> > > > > of the installation program and without checking that the installer
> > > > > behaves as documented. I believe the included changes are harmless in
> > > > > that respect. I'm happy to provide explanations of any given line edit
> > > > > on request, but I hope they are self-explanatory. `make allarchs` ran
> > > > > without issues and I don't seem to have broken any formatting.
> > > > >
> > > > > Regards,
> > > > > Evan Silberman
> > > > >
> > > > >
> > > > > Index: m4.common
> > > > > ===
> > > > > RCS file: /cvs/src/distrib/notes/m4.common,v
> > > > > retrieving revision 1.127
> > > > > diff -u -p -r1.127 m4.common
> > > > > --- m4.common 23 Aug 2017 02:59:45 - 1.127
> > > > > +++ m4.common 8 Jul 2019 05:36:28 -
> > > > > @@ -284,8 +284,8 @@ dnl Describes the boot of the ramdisk.
> > > > > dnl Describes the serial terminal setup.
> > > > > define({:-OpenBSDInstallPart3-:},
> > > > > {:- Once the kernel has loaded, you will be presented with the
> > > > > - OpenBSD kernel boot messages which contain information about
> > > > > - the hardware that was detected and supported by OpenBSD.
> > > > > + OpenBSD kernel boot messages, which contain information about
> > > > > + the supported hardware that was detected by OpenBSD.
> > > >
> > > > This is not true. OpenBSD does print information about hardware
> > > > detected but not supported. e.g.:
> > > >
> > > > "usb3_phy0" at mainbus0 not configured
> > > >
> > > > -Otto
> > >
> > > Below version corrects this as well as changing a few remaining instances
> > > of
> > > 'UN*X' to 'Unix'.
> > >
> > >
> > > Index: INSTALL
> > > ===
> > > RCS file: /cvs/src/distrib/notes/INSTALL,v
> > > retrieving revision 1.53
> > > diff -u -p -r1.53 INSTALL
> > > --- INSTALL 24 Jun 2019 01:21:46 - 1.53
> > > +++ INSTALL 8 Jul 2019 17:24:49 -
> > > @@ -7,7 +7,7 @@ INSTALLATION NOTES for OpenBSD/MACHINE O
> > > What is OpenBSD?
> > >
> > >
> > > -OpenBSD is a fully functional, multi-platform UN*X-like Operating
> > > +OpenBSD is a fully functional, multi-platform Unix-like Operating
> > > System based on Berkeley Networking Release 2 (Net/2) and 4.4BSD-Lite.
> > > There are several operating systems in this family, but OpenBSD
> > > differentiates itself by putting security and correctness first. The
> > > @@ -137,7 +137,7 @@ Using online OpenBSD documentation:
> > > ---
> > >
> > > Documentation is available if you first install the manual pages
> > > -distribution set. Traditionally, the UN*X "man pages" (documentation)
> > > +distribution set. Traditionally, the Unix "man pages" (documentation)
> > > are denoted by 'name(section)'. Some examples of this are
> > >
> > > intro(1),
> > > Index: m4.common
> > > ===
> > > RCS file: /cvs/src/distrib/notes/m4.common,v
> > > retrieving revision 1.127
> > > diff -u -p -r1.127 m4.common
> > > --- m4.common 23 Aug 2017 02:59:45 - 1.127
> > > +++ m4.common 8 Jul 2019 17:24:49 -
> > > @@ -284,8 +284,8 @@ dnl Describes the boot of the ramdisk.
> > > dnl Describes the serial terminal setup.
> > > define({:-OpenBSDInstallPart3-:},
> > > {:- Once the kernel has loaded, you will be presented with the
> > > - OpenBSD kernel bo
Re: Grammar and style edits to installation guide
Isn't Unix a trademark of the Open Group? Hence the usage of Unix-like or Un*x..
Ian McWilliam
From: owner-t...@openbsd.org on behalf of Jason
McIntyre
Sent: Tuesday, 9 July 2019 4:14 PM
To: tech@openbsd.org
Subject: Re: Grammar and style edits to installation guide
On Tue, Jul 09, 2019 at 07:43:50AM +0200, Otto Moerbeek wrote:
> On Mon, Jul 08, 2019 at 10:26:57AM -0700, Evan Silberman wrote:
>
> I don't know our stance on Unix vs Un*x. I'll leave this to some
> native speaker, like jmc@ who knows all about commas (and much more)
> :-)
>
>-Otto
>
hi.
i'm fairly sure Un*x is meant to denote the various flavours of unix,
and is probably pretty widespread in our docs. however i haven;t checked
that. i don;t really see a reason to change it unless we've somehow
decided that it doesn;t make sense and we make such changes wholesale.
i'll try to comment on the rest of the diff inline..
> I'll leave this to jmc or some other native speaker. S
> > Otto Moerbeek wrote:
> > > On Sun, Jul 07, 2019 at 10:44:42PM -0700, Evan Silberman wrote:
> > >
> > > > I noticed one thing that bothered me and decided to look for other
> > > > things that bothered me. Changes were made without reference to the code
> > > > of the installation program and without checking that the installer
> > > > behaves as documented. I believe the included changes are harmless in
> > > > that respect. I'm happy to provide explanations of any given line edit
> > > > on request, but I hope they are self-explanatory. `make allarchs` ran
> > > > without issues and I don't seem to have broken any formatting.
> > > >
> > > > Regards,
> > > > Evan Silberman
> > > >
> > > >
> > > > Index: m4.common
> > > > ===
> > > > RCS file: /cvs/src/distrib/notes/m4.common,v
> > > > retrieving revision 1.127
> > > > diff -u -p -r1.127 m4.common
> > > > --- m4.common 23 Aug 2017 02:59:45 - 1.127
> > > > +++ m4.common 8 Jul 2019 05:36:28 -
> > > > @@ -284,8 +284,8 @@ dnl Describes the boot of the ramdisk.
> > > > dnl Describes the serial terminal setup.
> > > > define({:-OpenBSDInstallPart3-:},
> > > > {:-Once the kernel has loaded, you will be presented with the
> > > > - OpenBSD kernel boot messages which contain information about
> > > > - the hardware that was detected and supported by OpenBSD.
> > > > + OpenBSD kernel boot messages, which contain information about
> > > > + the supported hardware that was detected by OpenBSD.
> > >
> > > This is not true. OpenBSD does print information about hardware
> > > detected but not supported. e.g.:
> > >
> > > "usb3_phy0" at mainbus0 not configured
> > >
> > >-Otto
> >
> > Below version corrects this as well as changing a few remaining instances of
> > 'UN*X' to 'Unix'.
> >
> >
> > Index: INSTALL
> > ===
> > RCS file: /cvs/src/distrib/notes/INSTALL,v
> > retrieving revision 1.53
> > diff -u -p -r1.53 INSTALL
> > --- INSTALL 24 Jun 2019 01:21:46 - 1.53
> > +++ INSTALL 8 Jul 2019 17:24:49 -
> > @@ -7,7 +7,7 @@ INSTALLATION NOTES for OpenBSD/MACHINE O
> > What is OpenBSD?
> >
> >
> > -OpenBSD is a fully functional, multi-platform UN*X-like Operating
> > +OpenBSD is a fully functional, multi-platform Unix-like Operating
> > System based on Berkeley Networking Release 2 (Net/2) and 4.4BSD-Lite.
> > There are several operating systems in this family, but OpenBSD
> > differentiates itself by putting security and correctness first. The
> > @@ -137,7 +137,7 @@ Using online OpenBSD documentation:
> > ---
> >
> > Documentation is available if you first install the manual pages
> > -distribution set. Traditionally, the UN*X "man pages" (documentation)
> > +distribution set. Traditionally, the Unix "man pages" (documentation)
> > are denoted by 'name(section)'. Some examples of this are
> >
> > intro(1),
> > Index: m4.common
> > ===
> > RCS file: /cvs/src/distrib/notes/m4.common,v
> > retrieving revision 1.127
> > diff -u -p -r1.127 m4.common
> > --- m4.common 23 Aug 2017 02:59:45 - 1.127
> > +++ m4.common 8 Jul 2019 17:24:49 -
> > @@ -284,8 +284,8 @@ dnl Describes the boot of the ramdisk.
> > dnl Describes the serial terminal setup.
> > define({:-OpenBSDInstallPart3-:},
> > {:-Once the kernel has loaded, you will be presented with the
> > - OpenBSD kernel boot messages which contain information about
> > - the hardware that was detected and supported by OpenBSD.
> > + OpenBSD kernel boot messages, which contain information about
> > + detected and supported hardware.
> >
well this is just saying one thing another way, isn;t it? i don;t see
the point. oh, but the comma before "which" is correct.
> > dnl dot.profile
> >
Re: Grammar and style edits to installation guide
On Tue, Jul 09, 2019 at 07:43:50AM +0200, Otto Moerbeek wrote:
> On Mon, Jul 08, 2019 at 10:26:57AM -0700, Evan Silberman wrote:
>
> I don't know our stance on Unix vs Un*x. I'll leave this to some
> native speaker, like jmc@ who knows all about commas (and much more)
> :-)
>
> -Otto
>
hi.
i'm fairly sure Un*x is meant to denote the various flavours of unix,
and is probably pretty widespread in our docs. however i haven;t checked
that. i don;t really see a reason to change it unless we've somehow
decided that it doesn;t make sense and we make such changes wholesale.
i'll try to comment on the rest of the diff inline..
> I'll leave this to jmc or some other native speaker. S
> > Otto Moerbeek wrote:
> > > On Sun, Jul 07, 2019 at 10:44:42PM -0700, Evan Silberman wrote:
> > >
> > > > I noticed one thing that bothered me and decided to look for other
> > > > things that bothered me. Changes were made without reference to the code
> > > > of the installation program and without checking that the installer
> > > > behaves as documented. I believe the included changes are harmless in
> > > > that respect. I'm happy to provide explanations of any given line edit
> > > > on request, but I hope they are self-explanatory. `make allarchs` ran
> > > > without issues and I don't seem to have broken any formatting.
> > > >
> > > > Regards,
> > > > Evan Silberman
> > > >
> > > >
> > > > Index: m4.common
> > > > ===
> > > > RCS file: /cvs/src/distrib/notes/m4.common,v
> > > > retrieving revision 1.127
> > > > diff -u -p -r1.127 m4.common
> > > > --- m4.common 23 Aug 2017 02:59:45 - 1.127
> > > > +++ m4.common 8 Jul 2019 05:36:28 -
> > > > @@ -284,8 +284,8 @@ dnl Describes the boot of the ramdisk.
> > > > dnl Describes the serial terminal setup.
> > > > define({:-OpenBSDInstallPart3-:},
> > > > {:-Once the kernel has loaded, you will be presented with the
> > > > - OpenBSD kernel boot messages which contain information about
> > > > - the hardware that was detected and supported by OpenBSD.
> > > > + OpenBSD kernel boot messages, which contain information about
> > > > + the supported hardware that was detected by OpenBSD.
> > >
> > > This is not true. OpenBSD does print information about hardware
> > > detected but not supported. e.g.:
> > >
> > > "usb3_phy0" at mainbus0 not configured
> > >
> > > -Otto
> >
> > Below version corrects this as well as changing a few remaining instances of
> > 'UN*X' to 'Unix'.
> >
> >
> > Index: INSTALL
> > ===
> > RCS file: /cvs/src/distrib/notes/INSTALL,v
> > retrieving revision 1.53
> > diff -u -p -r1.53 INSTALL
> > --- INSTALL 24 Jun 2019 01:21:46 - 1.53
> > +++ INSTALL 8 Jul 2019 17:24:49 -
> > @@ -7,7 +7,7 @@ INSTALLATION NOTES for OpenBSD/MACHINE O
> > What is OpenBSD?
> >
> >
> > -OpenBSD is a fully functional, multi-platform UN*X-like Operating
> > +OpenBSD is a fully functional, multi-platform Unix-like Operating
> > System based on Berkeley Networking Release 2 (Net/2) and 4.4BSD-Lite.
> > There are several operating systems in this family, but OpenBSD
> > differentiates itself by putting security and correctness first. The
> > @@ -137,7 +137,7 @@ Using online OpenBSD documentation:
> > ---
> >
> > Documentation is available if you first install the manual pages
> > -distribution set. Traditionally, the UN*X "man pages" (documentation)
> > +distribution set. Traditionally, the Unix "man pages" (documentation)
> > are denoted by 'name(section)'. Some examples of this are
> >
> > intro(1),
> > Index: m4.common
> > ===
> > RCS file: /cvs/src/distrib/notes/m4.common,v
> > retrieving revision 1.127
> > diff -u -p -r1.127 m4.common
> > --- m4.common 23 Aug 2017 02:59:45 - 1.127
> > +++ m4.common 8 Jul 2019 17:24:49 -
> > @@ -284,8 +284,8 @@ dnl Describes the boot of the ramdisk.
> > dnl Describes the serial terminal setup.
> > define({:-OpenBSDInstallPart3-:},
> > {:-Once the kernel has loaded, you will be presented with the
> > - OpenBSD kernel boot messages which contain information about
> > - the hardware that was detected and supported by OpenBSD.
> > + OpenBSD kernel boot messages, which contain information about
> > + detected and supported hardware.
> >
well this is just saying one thing another way, isn;t it? i don;t see
the point. oh, but the comma before "which" is correct.
> > dnl dot.profile
> > After the kernel is done initializing, you will be asked whether
> > @@ -327,9 +327,9 @@ dnl install.sub (install) hostname
> > dnl install.sub (install) donetconfig
> > You will now be given an opportunity to configure the network.
> > The network configuration you enter (if an
Re: Grammar and style edits to installation guide
On Mon, Jul 08, 2019 at 10:26:57AM -0700, Evan Silberman wrote:
I don't know our stance on Unix vs Un*x. I'll leave this to some
native speaker, like jmc@ who knows all about commas (and much more)
:-)
-Otto
I'll leave this to jmc or some other native speaker. S
> Otto Moerbeek wrote:
> > On Sun, Jul 07, 2019 at 10:44:42PM -0700, Evan Silberman wrote:
> >
> > > I noticed one thing that bothered me and decided to look for other
> > > things that bothered me. Changes were made without reference to the code
> > > of the installation program and without checking that the installer
> > > behaves as documented. I believe the included changes are harmless in
> > > that respect. I'm happy to provide explanations of any given line edit
> > > on request, but I hope they are self-explanatory. `make allarchs` ran
> > > without issues and I don't seem to have broken any formatting.
> > >
> > > Regards,
> > > Evan Silberman
> > >
> > >
> > > Index: m4.common
> > > ===
> > > RCS file: /cvs/src/distrib/notes/m4.common,v
> > > retrieving revision 1.127
> > > diff -u -p -r1.127 m4.common
> > > --- m4.common 23 Aug 2017 02:59:45 - 1.127
> > > +++ m4.common 8 Jul 2019 05:36:28 -
> > > @@ -284,8 +284,8 @@ dnl Describes the boot of the ramdisk.
> > > dnl Describes the serial terminal setup.
> > > define({:-OpenBSDInstallPart3-:},
> > > {:- Once the kernel has loaded, you will be presented with the
> > > - OpenBSD kernel boot messages which contain information about
> > > - the hardware that was detected and supported by OpenBSD.
> > > + OpenBSD kernel boot messages, which contain information about
> > > + the supported hardware that was detected by OpenBSD.
> >
> > This is not true. OpenBSD does print information about hardware
> > detected but not supported. e.g.:
> >
> > "usb3_phy0" at mainbus0 not configured
> >
> > -Otto
>
> Below version corrects this as well as changing a few remaining instances of
> 'UN*X' to 'Unix'.
>
>
> Index: INSTALL
> ===
> RCS file: /cvs/src/distrib/notes/INSTALL,v
> retrieving revision 1.53
> diff -u -p -r1.53 INSTALL
> --- INSTALL 24 Jun 2019 01:21:46 - 1.53
> +++ INSTALL 8 Jul 2019 17:24:49 -
> @@ -7,7 +7,7 @@ INSTALLATION NOTES for OpenBSD/MACHINE O
> What is OpenBSD?
>
>
> -OpenBSD is a fully functional, multi-platform UN*X-like Operating
> +OpenBSD is a fully functional, multi-platform Unix-like Operating
> System based on Berkeley Networking Release 2 (Net/2) and 4.4BSD-Lite.
> There are several operating systems in this family, but OpenBSD
> differentiates itself by putting security and correctness first. The
> @@ -137,7 +137,7 @@ Using online OpenBSD documentation:
> ---
>
> Documentation is available if you first install the manual pages
> -distribution set. Traditionally, the UN*X "man pages" (documentation)
> +distribution set. Traditionally, the Unix "man pages" (documentation)
> are denoted by 'name(section)'. Some examples of this are
>
> intro(1),
> Index: m4.common
> ===
> RCS file: /cvs/src/distrib/notes/m4.common,v
> retrieving revision 1.127
> diff -u -p -r1.127 m4.common
> --- m4.common 23 Aug 2017 02:59:45 - 1.127
> +++ m4.common 8 Jul 2019 17:24:49 -
> @@ -284,8 +284,8 @@ dnl Describes the boot of the ramdisk.
> dnl Describes the serial terminal setup.
> define({:-OpenBSDInstallPart3-:},
> {:- Once the kernel has loaded, you will be presented with the
> - OpenBSD kernel boot messages which contain information about
> - the hardware that was detected and supported by OpenBSD.
> + OpenBSD kernel boot messages, which contain information about
> + detected and supported hardware.
>
> dnl dot.profile
> After the kernel is done initializing, you will be asked whether
> @@ -327,9 +327,9 @@ dnl install.sub (install) hostname
> dnl install.sub (install) donetconfig
> You will now be given an opportunity to configure the network.
> The network configuration you enter (if any) can then be used to
> - do the install from another system using HTTP, and will also be
> - the configuration used by the system after the installation is
> - complete.
> + obtain installation sets from another system using HTTP, and
> + will also be the configuration used by the system after the
> + installation is complete.
>
> dnl XXX add a MDVLAN feature and document vlan setup
> The install program will give you a list of network interfaces you
> @@ -409,10 +409,10 @@ dnl install.sub (install) user_setup()
> with a lowercase letter. If the login name matches this
> criteria, and doesn't conflict with any of the administrative
> user accounts (such as `root', `daemon' or `ft
ure and url need ifmedia attribute
ok? Index: sys/dev/usb/files.usb === RCS file: /cvs/src/sys/dev/usb/files.usb,v retrieving revision 1.139 diff -u -p -u -p -r1.139 files.usb --- sys/dev/usb/files.usb 7 Jun 2019 16:06:59 - 1.139 +++ sys/dev/usb/files.usb 9 Jul 2019 01:31:35 - @@ -276,12 +276,12 @@ attachugl at uhub file dev/usb/if_ugl.cugl # Realtek RTL8150L(M) -device url: ether, ifnet, mii +device url: ether, ifnet, mii, ifmedia attach url at uhub file dev/usb/if_url.curl # Realtek RTL8152 -device ure: ether, ifnet, mii +device ure: ether, ifnet, mii, ifmedia attach ure at uhub file dev/usb/if_ure.cure
Stop using PUSER in tsleep(9)
PUSER has been used since the import of ___thrsleep(2) / librthread.
This value has been then copied to futex(2). No other tsleep(9) call
use this value. I'd like to stop using it to be able to differentiate
sleeping priorities that will be always < PUSER, to running priorities.
The only running priorities that could be < PUSER are the one of niced
programs like sndiod(9).
Ok?
Index: kern/kern_sig.c
===
RCS file: /cvs/src/sys/kern/kern_sig.c,v
retrieving revision 1.231
diff -u -p -r1.231 kern_sig.c
--- kern/kern_sig.c 21 Jun 2019 09:39:48 - 1.231
+++ kern/kern_sig.c 21 Jun 2019 20:15:12 -
@@ -2049,7 +2049,7 @@ single_thread_wait(struct process *pr)
{
/* wait until they're all suspended */
while (pr->ps_singlecount > 0)
- tsleep(&pr->ps_singlecount, PUSER, "suspend", 0);
+ tsleep(&pr->ps_singlecount, PWAIT, "suspend", 0);
}
void
Index: kern/kern_synch.c
===
RCS file: /cvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.150
diff -u -p -r1.150 kern_synch.c
--- kern/kern_synch.c 3 Jul 2019 22:39:33 - 1.150
+++ kern/kern_synch.c 8 Jul 2019 16:36:40 -
@@ -644,7 +644,7 @@ thrsleep(struct proc *p, struct sys___th
void *sleepaddr = &p->p_thrslpid;
if (ident == -1)
sleepaddr = &globalsleepaddr;
- error = tsleep(sleepaddr, PUSER | PCATCH, "thrsleep",
+ error = tsleep(sleepaddr, PWAIT|PCATCH, "thrsleep",
(int)to_ticks);
}
Index: kern/sys_futex.c
===
RCS file: /cvs/src/sys/kern/sys_futex.c,v
retrieving revision 1.12
diff -u -p -r1.12 sys_futex.c
--- kern/sys_futex.c6 Feb 2019 15:11:20 - 1.12
+++ kern/sys_futex.c21 Jun 2019 20:15:57 -
@@ -254,7 +254,7 @@ futex_wait(uint32_t *uaddr, uint32_t val
TAILQ_INSERT_TAIL(&f->ft_threads, p, p_fut_link);
p->p_futex = f;
- error = rwsleep(p, &ftlock, PUSER|PCATCH, "fsleep", (int)to_ticks);
+ error = rwsleep(p, &ftlock, PWAIT|PCATCH, "fsleep", (int)to_ticks);
if (error == ERESTART)
error = ECANCELED;
else if (error == EWOULDBLOCK) {
Re: uuid.3: typo
On Mon, Jul 08, 2019 at 02:16:03PM -0700, Evan Silberman wrote: > request cor fomments committed, thanks
uuid.3: typo
request cor fomments Index: uuid.3 === RCS file: /cvs/src/lib/libc/uuid/uuid.3,v retrieving revision 1.6 diff -u -p -r1.6 uuid.3 --- uuid.3 2 Oct 2018 10:55:39 - 1.6 +++ uuid.3 8 Jul 2019 21:15:27 - @@ -207,4 +207,4 @@ functions are compatible with the DCE 1. .Pp .Fn uuid_create generates version 4 UUIDs, -specified by section 4.4 of RCF 4122. +specified by section 4.4 of RFC 4122.
Re: uvideo(4): *ALL*
Hi Patrick,
I tested all you patches with my integrated uvideo(4) device.
...
uvideo0 at uhub0 port 8 configuration 1 interface 0 "SunplusIT Inc Integrated
Camera" rev 2.01/54.20 addr 9
video0 at uvideo0
...
addr 09: 5986:2115 SunplusIT Inc, Integrated Camera
high speed, power 500 mA, config 1, rev 54.20
driver: uvideo0
My device don't need your patches to work, but at least they doesn't
break it :) Your diffs looks ok for me, but I'm not a USB expert.
Just a nitpick:
There is a spacing mistake in the definition of the new macro
UVIDEO_FORMAT_GUID_KSMEDIA_L8_IR and in the two above. We may fix them
while here?!
Bye,
Jan
Index: uvideo.h
===
RCS file: /cvs/src/sys/dev/usb/uvideo.h,v
retrieving revision 1.57
diff -u -p -r1.57 uvideo.h
--- uvideo.h9 Jul 2015 14:58:32 - 1.57
+++ uvideo.h8 Jul 2019 20:08:07 -
@@ -302,11 +302,15 @@ struct usb_video_probe_commit {
#defineUVIDEO_FORMAT_GUID_NV12 { \
0x4e, 0x56, 0x31, 0x32, 0x00, 0x00, 0x10, 0x00,\
-0x80, 0x00, 0x00, 0xaa, 0x00, 0x38,0x9b, 0x71 }
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71 }
#defineUVIDEO_FORMAT_GUID_UYVY { \
0x55, 0x59, 0x56, 0x59, 0x00, 0x00, 0x10, 0x00,\
-0x80, 0x00, 0x00, 0xaa, 0x00, 0x38,0x9b, 0x71 }
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71 }
+
+#defineUVIDEO_FORMAT_GUID_KSMEDIA_L8_IR{ \
+0x32, 0x00, 0x00, 0x00, 0x02, 0x00, 0x10, 0x00,\
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71 }
/*
* USB Video Payload MJPEG
tty: use timeout_add_msec(9)
This is read(2)ing form a tty(4) device. More specifically,
only non-canonical mode. From X/Open 4.2:
MIN represents the minimum number of bytes that should be
received when the read() function returns successfully. TIME is
a timer of 0.1 second granularity that is used to time out
bursty and short-term data transmissions.
So TIME is `cc[VTIME] / 10' and this diff changes the timeout from
(TIME * hz) [ticks] to (TIME * 1000) [ms].
With stty(1) one can set mode and values, see the "[-]icanon", "min" and
"time" options: Staying in the shell prompt won't exercise all
differences and the shell's mode mattters, but typing into cat(1) after
changing mode and values show immediate effects.
Besides running with this diff on X230 as daily driver, this is also how
I played around and tested.
Wondering why `t' is of type long even though it gets demoted to int
as timeout_add(9) expects it and given `cc[VTIME]' is of type u_char
(where U_CHAR_MAX = 0xff = 255), it follows that `cc[VTIME] * 1000'
never exceeds 255000 (much smaller than INT_MAX), so use int directly.
With this and `hz' gone, the comment seems obsolete, so remove it.
Am I missing something?
Feedback? OK?
Index: kern/tty.c
===
RCS file: /cvs/src/sys/kern/tty.c,v
retrieving revision 1.146
diff -u -p -r1.146 tty.c
--- kern/tty.c 1 Jun 2019 14:11:17 - 1.146
+++ kern/tty.c 8 Jul 2019 19:05:16 -
@@ -1498,14 +1498,7 @@ loop:lflag = tp->t_lflag;
s = spltty();
if (!ISSET(lflag, ICANON)) {
int m = cc[VMIN];
- long t;
-
- /*
-* Note - since cc[VTIME] is a u_char, this won't overflow
-* until we have 32-bit longs and a hz > 8388608.
-* Hopefully this code and 32-bit longs are obsolete by then.
-*/
- t = cc[VTIME] * hz / 10;
+ int t = cc[VTIME] * 1000 / 10; /* milliseconds */
qp = &tp->t_rawq;
/*
@@ -1528,10 +1521,10 @@ loop: lflag = tp->t_lflag;
alloc_timer:
stime = malloc(sizeof(*stime), M_TEMP,
M_WAITOK);
timeout_set(stime, ttvtimeout, tp);
- timeout_add(stime, t);
+ timeout_add_msec(stime, t);
} else if (qp->c_cc > last_cc) {
/* got a character, restart timer */
- timeout_add(stime, t);
+ timeout_add_msec(stime, t);
}
} else {/* m == 0 */
if (qp->c_cc > 0)
Re: pf: use proper interface for route-to when it is used with sticky-address
Hello Yasuoka, > Previous diff made src-node have a reference for the kif. My > colleague pointed out that incrementing the reference count of the kif > is required. > > ok? > very good catch, indeed. Thanks for taking care of it. diff looks good to me. OK sashan
Re: Nuke db_is_active in favor of db_active
On 26/06/19(Wed) 19:13, Christian Ludwig wrote:
> We have two variables with the same meaning. db_active is used in way
> more places, so let's nuke db_is_active.
Thanks for the cleanup!
> Now that db_active is in for a while already and not
> guarded by DDB anymore, take the opportunity to clean up some places
> that use it.
At least m88k and powerpc do not set db_active before calling db_trap().
This needs to be fixed first :)
> ---
> sys/arch/macppc/dev/zs.c | 8 ++--
> sys/arch/sparc64/sparc64/ipifuncs.c| 2 --
> sys/ddb/db_trap.c | 2 --
> sys/ddb/db_var.h | 1 -
> sys/dev/pci/drm/include/linux/kernel.h | 4 +---
> sys/dev/pci/drm/include/linux/kgdb.h | 4 ++--
> sys/kern/subr_prf.c| 14 ++
> sys/kern/subr_witness.c| 2 +-
> 8 files changed, 8 insertions(+), 29 deletions(-)
>
> diff --git a/sys/arch/macppc/dev/zs.c b/sys/arch/macppc/dev/zs.c
> index ba4453683ca..f6f1901a3e1 100644
> --- a/sys/arch/macppc/dev/zs.c
> +++ b/sys/arch/macppc/dev/zs.c
> @@ -1091,12 +1091,8 @@ zs_abort(struct zs_chanstate *channel)
> } while (rr0 & ZSRR0_BREAK);
>
> #if defined(DDB)
> - {
> - extern int db_active;
> -
> - if (!db_active)
> - db_enter();
> - }
> + if (!db_active)
> + db_enter();
> #endif
> }
>
> diff --git a/sys/arch/sparc64/sparc64/ipifuncs.c
> b/sys/arch/sparc64/sparc64/ipifuncs.c
> index 1ffeb666bf4..54603319a1e 100644
> --- a/sys/arch/sparc64/sparc64/ipifuncs.c
> +++ b/sys/arch/sparc64/sparc64/ipifuncs.c
> @@ -39,8 +39,6 @@
> #include
> #include
>
> -extern int db_active;
> -
> #define SPARC64_IPI_RETRIES 1
>
> #define sparc64_ipi_sleep() delay(1000)
> diff --git a/sys/ddb/db_trap.c b/sys/ddb/db_trap.c
> index 85467256e61..f1c6317a715 100644
> --- a/sys/ddb/db_trap.c
> +++ b/sys/ddb/db_trap.c
> @@ -52,7 +52,6 @@ db_trap(int type, int code)
> boolean_t bkpt;
> boolean_t watchpt;
>
> - db_is_active = 1;
> bkpt = IS_BREAKPOINT_TRAP(type, code);
> watchpt = IS_WATCHPOINT_TRAP(type, code);
>
> @@ -94,5 +93,4 @@ db_trap(int type, int code)
> }
>
> db_restart_at_pc(&ddb_regs, watchpt);
> - db_is_active = 0;
> }
> diff --git a/sys/ddb/db_var.h b/sys/ddb/db_var.h
> index 3bb02b5d34d..f264aaa6c7f 100644
> --- a/sys/ddb/db_var.h
> +++ b/sys/ddb/db_var.h
> @@ -67,7 +67,6 @@ extern int db_max_line;
> extern int db_panic;
> extern int db_console;
> extern int db_log;
> -extern int db_is_active;
> extern int db_profile;
>
> int ddb_sysctl(int *, u_int, void *, size_t *, void *, size_t,
> diff --git a/sys/dev/pci/drm/include/linux/kernel.h
> b/sys/dev/pci/drm/include/linux/kernel.h
> index 188efad2f4f..d0b274c88c8 100644
> --- a/sys/dev/pci/drm/include/linux/kernel.h
> +++ b/sys/dev/pci/drm/include/linux/kernel.h
> @@ -9,8 +9,6 @@
> #include
> #include
>
> -#include
> -
> #include
> #include
> #include
> @@ -119,7 +117,7 @@ static inline int
> _in_dbg_master(void)
> {
> #ifdef DDB
> - return (db_is_active);
> + return (db_active);
> #endif
> return (0);
> }
> diff --git a/sys/dev/pci/drm/include/linux/kgdb.h
> b/sys/dev/pci/drm/include/linux/kgdb.h
> index 73759b3be75..874a0ebe0be 100644
> --- a/sys/dev/pci/drm/include/linux/kgdb.h
> +++ b/sys/dev/pci/drm/include/linux/kgdb.h
> @@ -3,13 +3,13 @@
> #ifndef _LINUX_KGDB_H
> #define _LINUX_KGDB_H
>
> -#include
> +#include
>
> static inline int
> in_dbg_master(void)
> {
> #ifdef DDB
> - return (db_is_active);
> + return (db_active);
> #endif
> return (0);
> }
> diff --git a/sys/kern/subr_prf.c b/sys/kern/subr_prf.c
> index 6abac53452a..87bb23d1ded 100644
> --- a/sys/kern/subr_prf.c
> +++ b/sys/kern/subr_prf.c
> @@ -118,11 +118,6 @@ int db_console = 1;
> #else
> int db_console = 0;
> #endif
> -
> -/*
> - * flag to indicate if we are currently in ddb (on some processor)
> - */
> -int db_is_active;
> #endif
>
> /*
> @@ -330,16 +325,11 @@ void
> kputchar(int c, int flags, struct tty *tp)
> {
> extern int msgbufmapped;
> - int ddb_active = 0;
> -
> -#ifdef DDB
> - ddb_active = db_is_active;
> -#endif
>
> if (panicstr)
> constty = NULL;
>
> - if ((flags & TOCONS) && tp == NULL && constty && !ddb_active) {
> + if ((flags & TOCONS) && tp == NULL && constty && !db_active) {
> tp = constty;
> flags |= TOTTY;
> }
> @@ -349,7 +339,7 @@ kputchar(int c, int flags, struct tty *tp)
> if ((flags & TOLOG) &&
> c != '\0' && c != '\r' && c != 0177 && msgbufmapped)
> msgbuf_putchar(msgbufp, c);
> - if ((flags & TOCONS) && (constty == NULL || ddb_active) && c != '\0')
> + if ((flags & TOCONS) && (constty == NULL || db_active) && c != '\0')
> (*v_putc)(c);
> #ifdef DDB
> if
Re: Grammar and style edits to installation guide
Otto Moerbeek wrote:
> On Sun, Jul 07, 2019 at 10:44:42PM -0700, Evan Silberman wrote:
>
> > I noticed one thing that bothered me and decided to look for other
> > things that bothered me. Changes were made without reference to the code
> > of the installation program and without checking that the installer
> > behaves as documented. I believe the included changes are harmless in
> > that respect. I'm happy to provide explanations of any given line edit
> > on request, but I hope they are self-explanatory. `make allarchs` ran
> > without issues and I don't seem to have broken any formatting.
> >
> > Regards,
> > Evan Silberman
> >
> >
> > Index: m4.common
> > ===
> > RCS file: /cvs/src/distrib/notes/m4.common,v
> > retrieving revision 1.127
> > diff -u -p -r1.127 m4.common
> > --- m4.common 23 Aug 2017 02:59:45 - 1.127
> > +++ m4.common 8 Jul 2019 05:36:28 -
> > @@ -284,8 +284,8 @@ dnl Describes the boot of the ramdisk.
> > dnl Describes the serial terminal setup.
> > define({:-OpenBSDInstallPart3-:},
> > {:-Once the kernel has loaded, you will be presented with the
> > - OpenBSD kernel boot messages which contain information about
> > - the hardware that was detected and supported by OpenBSD.
> > + OpenBSD kernel boot messages, which contain information about
> > + the supported hardware that was detected by OpenBSD.
>
> This is not true. OpenBSD does print information about hardware
> detected but not supported. e.g.:
>
> "usb3_phy0" at mainbus0 not configured
>
> -Otto
Below version corrects this as well as changing a few remaining instances of
'UN*X' to 'Unix'.
Index: INSTALL
===
RCS file: /cvs/src/distrib/notes/INSTALL,v
retrieving revision 1.53
diff -u -p -r1.53 INSTALL
--- INSTALL 24 Jun 2019 01:21:46 - 1.53
+++ INSTALL 8 Jul 2019 17:24:49 -
@@ -7,7 +7,7 @@ INSTALLATION NOTES for OpenBSD/MACHINE O
What is OpenBSD?
-OpenBSD is a fully functional, multi-platform UN*X-like Operating
+OpenBSD is a fully functional, multi-platform Unix-like Operating
System based on Berkeley Networking Release 2 (Net/2) and 4.4BSD-Lite.
There are several operating systems in this family, but OpenBSD
differentiates itself by putting security and correctness first. The
@@ -137,7 +137,7 @@ Using online OpenBSD documentation:
---
Documentation is available if you first install the manual pages
-distribution set. Traditionally, the UN*X "man pages" (documentation)
+distribution set. Traditionally, the Unix "man pages" (documentation)
are denoted by 'name(section)'. Some examples of this are
intro(1),
Index: m4.common
===
RCS file: /cvs/src/distrib/notes/m4.common,v
retrieving revision 1.127
diff -u -p -r1.127 m4.common
--- m4.common 23 Aug 2017 02:59:45 - 1.127
+++ m4.common 8 Jul 2019 17:24:49 -
@@ -284,8 +284,8 @@ dnl Describes the boot of the ramdisk.
dnl Describes the serial terminal setup.
define({:-OpenBSDInstallPart3-:},
{:-Once the kernel has loaded, you will be presented with the
- OpenBSD kernel boot messages which contain information about
- the hardware that was detected and supported by OpenBSD.
+ OpenBSD kernel boot messages, which contain information about
+ detected and supported hardware.
dnl dot.profile
After the kernel is done initializing, you will be asked whether
@@ -327,9 +327,9 @@ dnl install.sub (install) hostname
dnl install.sub (install) donetconfig
You will now be given an opportunity to configure the network.
The network configuration you enter (if any) can then be used to
- do the install from another system using HTTP, and will also be
- the configuration used by the system after the installation is
- complete.
+ obtain installation sets from another system using HTTP, and
+ will also be the configuration used by the system after the
+ installation is complete.
dnl XXX add a MDVLAN feature and document vlan setup
The install program will give you a list of network interfaces you
@@ -409,10 +409,10 @@ dnl install.sub (install) user_setup()
with a lowercase letter. If the login name matches this
criteria, and doesn't conflict with any of the administrative
user accounts (such as `root', `daemon' or `ftp'), you
- will be prompted with the users descriptive name, as well
- as its password, twice.
+ will be prompted for the user's descriptive name, then twice
+ for its password.
- As for the root password earlier, the install program will only
+ As with the root password earlier, the install program will only
check that the two passwords match, but you should make sur
Re: getgroups(2) with negative values
On Mon, 08 Jul 2019 16:36:05 +0200, Moritz Buhl wrote: > while porting some NetBSD syscall tests to OpenBSD I noticed that the > getgroups test is failing. Simply put: > > gid_t gidset[NGROUPS_MAX]; > getgroups(-1, gidset); > > This was fixed on NetBSD 8 years ago: > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/kern_prot.c > > if (SCARG(uap, gidsetsize) < (int)*retval) > > return EINVAL; > > While here, also remove the u_int in setgroups. POSIX does't say a lot > about setgroups and therefore return EINVAL. > https://pubs.opengroup.org/onlinepubs/9699919799/ That all makes sense to me. Checking for ngrp<0 in setgroups() makes things easier to understand compared to the implicit cast to uint and relying on the result to be >NGROUPS_MAX. - todd
getgroups(2) with negative values
Hi,
while porting some NetBSD syscall tests to OpenBSD I noticed that the
getgroups test is failing. Simply put:
gid_t gidset[NGROUPS_MAX];
getgroups(-1, gidset);
This was fixed on NetBSD 8 years ago:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/kern_prot.c
> if (SCARG(uap, gidsetsize) < (int)*retval)
> return EINVAL;
While here, also remove the u_int in setgroups. POSIX does't say a lot
about setgroups and therefore return EINVAL.
https://pubs.opengroup.org/onlinepubs/9699919799/
Index: sys/kern/kern_prot.c
===
RCS file: /cvs/src/sys/kern/kern_prot.c,v
retrieving revision 1.75
diff -u -p -r1.75 kern_prot.c
--- sys/kern/kern_prot.c22 Jun 2018 13:33:30 - 1.75
+++ sys/kern/kern_prot.c8 Jul 2019 12:13:04 -
@@ -196,7 +196,7 @@ sys_getgroups(struct proc *p, void *v, r
syscallarg(gid_t *) gidset;
} */ *uap = v;
struct ucred *uc = p->p_ucred;
- u_int ngrp;
+ int ngrp;
int error;
if ((ngrp = SCARG(uap, gidsetsize)) == 0) {
@@ -870,13 +870,13 @@ sys_setgroups(struct proc *p, void *v, r
struct process *pr = p->p_p;
struct ucred *pruc, *newcred;
gid_t groups[NGROUPS_MAX];
- u_int ngrp;
+ int ngrp;
int error;
if ((error = suser(p)) != 0)
return (error);
ngrp = SCARG(uap, gidsetsize);
- if (ngrp > NGROUPS_MAX)
+ if (ngrp > NGROUPS_MAX || ngrp < 0)
return (EINVAL);
error = copyin(SCARG(uap, gidset), groups, ngrp * sizeof(gid_t));
if (error == 0) {
