Re: TIMESPEC_TO_NSEC(), futex(2) & __thrsleep(2)
> On Dec 31, 2019, at 9:35 AM, Martin Pieuchot wrote:
>
> I'd like to stop converting the given timespec to ticks and instead use
> nanoseconds. This is part of the ongoing effort to reduce the use of
> `hz' through the kernel.
>
> Since I don't know C I'd appreciate any pointer about the checks that
> should be added to TIMESPEC_TO_NSEC().
>
> Then the conversions to {t,rw}sleep_nsec(9) become trivial, diff below.
We can't do this until timeouts have a tickless interface. Otherwise
your timeouts will return early. That's why I was saving the sys/kern
conversions until after resolving that issue.
You could convert the conversion code to use tstohz(9) to minimize
copy-paste in the kernel, but that's about all you can do until
timeouts have a tickless interface.
Re: Add pcidev for Ryzen 3x ccp
On Wed, Jan 01, 2020 at 09:25:16PM -0500, Todd Mortimer wrote: > On Thu, Jan 02, 2020 at 09:33:59AM +1000, Jonathan Matthew wrote: > > On Thu, Jan 02, 2020 at 10:20:52AM +1100, Jonathan Gray wrote: > > > On Wed, Jan 01, 2020 at 11:21:45AM -0500, Todd Mortimer wrote: > > > > On Thu, Jan 02, 2020 at 02:41:11AM +1100, Jonathan Gray wrote: > > > > > On Wed, Jan 01, 2020 at 09:53:39AM -0500, Todd Mortimer wrote: > > > > > > My CPU has a CCP that isn't in the known list, so add it and tell > > > > > > ccp > > > > > > about it. > > > > > > > > > > > > Tested on Ryzen 3900x. > > > > > > > > > > > > ok? > > > > > > > > > > > > Will commit a pcidevs regen immediately after. > > > > > > > > > > Are your cpu lines in dmesg 17-3* or 17-7*? > > > > > Ryzen 3900x should be model 7X. > > > > > > > > 17-71-00. > > > > > > > > cpu0: AMD Ryzen 9 3900X 12-Core Processor, 3792.88 MHz, 17-71-00 > > > > > > > > I assume then change the constant bits to 17_7X and 17h/7xh ? > > > > > > Yes, unless that device id is also known to appear on earlier > > > models as well, in which case the first appearance is used. > > > > Also found here: > > > > cpu3: AMD EPYC 7502P 32-Core Processor, 2495.32 MHz, 17-31-00 > > > > vendor "AMD", unknown product 0x1486 (class crypto subclass miscellaneous, > > rev 0x00) at pci8 dev 0 function 1 not configured > > > > In that case, the original 17/3x labelling would be correct, which also > agrees with some of the other pcidev ids in the same numeric range. > > I have to admit, I would be just as happy to just label everything 17h > and drop the /[123..]x parts, but I don't really mind one way or the > other. > > ok for the original diff then? yes I also agree that it would be cleaner to just have something like product AMD CCP_1 0x1456 Crypto product AMD CCP_2 0x1468 Crypto product AMD CCP_3 0x1486 Crypto product AMD CCP_4 0x1537 Crypto product AMD CCP_5 0x15df Crypto And in other devices we could drop the "AMD64" as well.
Re: Add -R alias to -r for scp(1)
On Wed, Jan 01, 2020 at 09:31:29PM -0500, Kurt Mosiejczuk wrote: > On Wed, Jan 01, 2020 at 09:15:14PM -0500, Ted Unangst wrote: > > Kurt Mosiejczuk wrote: > > > cp(1) uses -R for recursive copy. scp(1) uses -r. This diff adds -R as an > > > alias for -r to scp(1) for those assuming consistency with cp(1). > > But it doesn't implement cp -R semantics. It does the copy the way cp -r > > does. > > (For symlinks, etc.) > According to cp(1), there *isn't* a -r. That's the whole reason I found it > odd we use the opposite flag for scp(1). I see, I had to be grubbing around in the STANDARDS section of the man page to know it exists. It also says I shouldn't use it. --Kurt
Re: Add -R alias to -r for scp(1)
On Wed, Jan 01, 2020 at 09:15:14PM -0500, Ted Unangst wrote: > Kurt Mosiejczuk wrote: > > cp(1) uses -R for recursive copy. scp(1) uses -r. This diff adds -R as an > > alias for -r to scp(1) for those assuming consistency with cp(1). > But it doesn't implement cp -R semantics. It does the copy the way cp -r does. > (For symlinks, etc.) According to cp(1), there *isn't* a -r. That's the whole reason I found it odd we use the opposite flag for scp(1). --Kurt
Re: Add pcidev for Ryzen 3x ccp
On Thu, Jan 02, 2020 at 09:33:59AM +1000, Jonathan Matthew wrote: > On Thu, Jan 02, 2020 at 10:20:52AM +1100, Jonathan Gray wrote: > > On Wed, Jan 01, 2020 at 11:21:45AM -0500, Todd Mortimer wrote: > > > On Thu, Jan 02, 2020 at 02:41:11AM +1100, Jonathan Gray wrote: > > > > On Wed, Jan 01, 2020 at 09:53:39AM -0500, Todd Mortimer wrote: > > > > > My CPU has a CCP that isn't in the known list, so add it and tell ccp > > > > > about it. > > > > > > > > > > Tested on Ryzen 3900x. > > > > > > > > > > ok? > > > > > > > > > > Will commit a pcidevs regen immediately after. > > > > > > > > Are your cpu lines in dmesg 17-3* or 17-7*? > > > > Ryzen 3900x should be model 7X. > > > > > > 17-71-00. > > > > > > cpu0: AMD Ryzen 9 3900X 12-Core Processor, 3792.88 MHz, 17-71-00 > > > > > > I assume then change the constant bits to 17_7X and 17h/7xh ? > > > > Yes, unless that device id is also known to appear on earlier > > models as well, in which case the first appearance is used. > > Also found here: > > cpu3: AMD EPYC 7502P 32-Core Processor, 2495.32 MHz, 17-31-00 > > vendor "AMD", unknown product 0x1486 (class crypto subclass miscellaneous, > rev 0x00) at pci8 dev 0 function 1 not configured > In that case, the original 17/3x labelling would be correct, which also agrees with some of the other pcidev ids in the same numeric range. I have to admit, I would be just as happy to just label everything 17h and drop the /[123..]x parts, but I don't really mind one way or the other. ok for the original diff then?
Re: Add -R alias to -r for scp(1)
Kurt Mosiejczuk wrote: > cp(1) uses -R for recursive copy. scp(1) uses -r. This diff adds -R as an > alias for -r to scp(1) for those assuming consistency with cp(1). But it doesn't implement cp -R semantics. It does the copy the way cp -r does. (For symlinks, etc.)
Add -R alias to -r for scp(1)
cp(1) uses -R for recursive copy. scp(1) uses -r. This diff adds -R as an
alias for -r to scp(1) for those assuming consistency with cp(1).
--Kurt
Index: scp.1
===
RCS file: /cvs/src/usr.bin/ssh/scp.1,v
retrieving revision 1.87
diff -u -p -r1.87 scp.1
--- scp.1 30 Nov 2019 07:07:59 - 1.87
+++ scp.1 2 Jan 2020 01:08:01 -
@@ -215,6 +215,12 @@ Recursively copy entire directories.
Note that
.Nm
follows symbolic links encountered in the tree traversal.
+.It Fl R
+A synonym for
+.Fl r .
+(To mimic the
+.Xr cp 1
+flag for recursive copy).
.It Fl S Ar program
Name of
.Ar program
Index: scp.c
===
RCS file: /cvs/src/usr.bin/ssh/scp.c,v
retrieving revision 1.206
diff -u -p -r1.206 scp.c
--- scp.c 9 Sep 2019 02:31:19 - 1.206
+++ scp.c 2 Jan 2020 01:08:01 -
@@ -404,7 +404,7 @@ main(int argc, char **argv)
fflag = Tflag = tflag = 0;
while ((ch = getopt(argc, argv,
- "dfl:prtTvBCc:i:P:q12346S:o:F:J:")) != -1) {
+ "dfl:pRrtTvBCc:i:P:q12346S:o:F:J:")) != -1) {
switch (ch) {
/* User-visible flags. */
case '1':
@@ -452,6 +452,7 @@ main(int argc, char **argv)
case 'p':
pflag = 1;
break;
+ case 'R':
case 'r':
iamrecursive = 1;
break;
Re: Add pcidev for Ryzen 3x ccp
On Thu, Jan 02, 2020 at 10:20:52AM +1100, Jonathan Gray wrote: > On Wed, Jan 01, 2020 at 11:21:45AM -0500, Todd Mortimer wrote: > > On Thu, Jan 02, 2020 at 02:41:11AM +1100, Jonathan Gray wrote: > > > On Wed, Jan 01, 2020 at 09:53:39AM -0500, Todd Mortimer wrote: > > > > My CPU has a CCP that isn't in the known list, so add it and tell ccp > > > > about it. > > > > > > > > Tested on Ryzen 3900x. > > > > > > > > ok? > > > > > > > > Will commit a pcidevs regen immediately after. > > > > > > Are your cpu lines in dmesg 17-3* or 17-7*? > > > Ryzen 3900x should be model 7X. > > > > 17-71-00. > > > > cpu0: AMD Ryzen 9 3900X 12-Core Processor, 3792.88 MHz, 17-71-00 > > > > I assume then change the constant bits to 17_7X and 17h/7xh ? > > Yes, unless that device id is also known to appear on earlier > models as well, in which case the first appearance is used. Also found here: cpu3: AMD EPYC 7502P 32-Core Processor, 2495.32 MHz, 17-31-00 vendor "AMD", unknown product 0x1486 (class crypto subclass miscellaneous, rev 0x00) at pci8 dev 0 function 1 not configured
Re: Add pcidev for Ryzen 3x ccp
On Wed, Jan 01, 2020 at 11:21:45AM -0500, Todd Mortimer wrote:
> On Thu, Jan 02, 2020 at 02:41:11AM +1100, Jonathan Gray wrote:
> > On Wed, Jan 01, 2020 at 09:53:39AM -0500, Todd Mortimer wrote:
> > > My CPU has a CCP that isn't in the known list, so add it and tell ccp
> > > about it.
> > >
> > > Tested on Ryzen 3900x.
> > >
> > > ok?
> > >
> > > Will commit a pcidevs regen immediately after.
> >
> > Are your cpu lines in dmesg 17-3* or 17-7*?
> > Ryzen 3900x should be model 7X.
>
> 17-71-00.
>
> cpu0: AMD Ryzen 9 3900X 12-Core Processor, 3792.88 MHz, 17-71-00
>
> I assume then change the constant bits to 17_7X and 17h/7xh ?
Yes, unless that device id is also known to appear on earlier
models as well, in which case the first appearance is used.
>
> >
> > >
> > >
> > > diff --git a/sys/dev/pci/ccp_pci.c b/sys/dev/pci/ccp_pci.c
> > > index 2259594644b..c8dcc8750fc 100644
> > > --- a/sys/dev/pci/ccp_pci.c
> > > +++ b/sys/dev/pci/ccp_pci.c
> > > @@ -47,6 +47,7 @@ static const struct pci_matchid ccp_pci_devices[] = {
> > > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_CCP_1 },
> > > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_CCP_2 },
> > > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_1X_CCP },
> > > + { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_3X_CCP },
> > > };
> > >
> > > int
> > > diff --git a/sys/dev/pci/pcidevs b/sys/dev/pci/pcidevs
> > > index d0a021b89bc..fb918e8de5d 100644
> > > --- a/sys/dev/pci/pcidevs
> > > +++ b/sys/dev/pci/pcidevs
> > > @@ -754,6 +754,7 @@ product AMD AMD64_17_CCP_20x1468 AMD64 17h Crypto
> > > product AMD AMD64_17_PCIE_4 0x1470 AMD64 17h PCIE
> > > product AMD AMD64_17_PCIE_5 0x1471 AMD64 17h PCIE
> > > product AMD AMD64_17_3X_RC 0x1480 AMD64 17h/3xh Root Complex
> > > +product AMD AMD64_17_3X_CCP 0x1486 AMD64 17h/3xh Crypto
> > > product AMD AMD64_14_HB 0x1510 AMD64 14h Host
> > > product AMD AMD64_14_PCIE_1 0x1512 AMD64 14h PCIE
> > > product AMD AMD64_14_PCIE_2 0x1513 AMD64 14h PCIE
> > >
> > >
>
>
Re: Add pcidev for Ryzen 3x ccp
On Thu, Jan 02, 2020 at 02:41:11AM +1100, Jonathan Gray wrote:
> On Wed, Jan 01, 2020 at 09:53:39AM -0500, Todd Mortimer wrote:
> > My CPU has a CCP that isn't in the known list, so add it and tell ccp
> > about it.
> >
> > Tested on Ryzen 3900x.
> >
> > ok?
> >
> > Will commit a pcidevs regen immediately after.
>
> Are your cpu lines in dmesg 17-3* or 17-7*?
> Ryzen 3900x should be model 7X.
17-71-00.
cpu0: AMD Ryzen 9 3900X 12-Core Processor, 3792.88 MHz, 17-71-00
I assume then change the constant bits to 17_7X and 17h/7xh ?
>
> >
> >
> > diff --git a/sys/dev/pci/ccp_pci.c b/sys/dev/pci/ccp_pci.c
> > index 2259594644b..c8dcc8750fc 100644
> > --- a/sys/dev/pci/ccp_pci.c
> > +++ b/sys/dev/pci/ccp_pci.c
> > @@ -47,6 +47,7 @@ static const struct pci_matchid ccp_pci_devices[] = {
> > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_CCP_1 },
> > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_CCP_2 },
> > { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_1X_CCP },
> > + { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_3X_CCP },
> > };
> >
> > int
> > diff --git a/sys/dev/pci/pcidevs b/sys/dev/pci/pcidevs
> > index d0a021b89bc..fb918e8de5d 100644
> > --- a/sys/dev/pci/pcidevs
> > +++ b/sys/dev/pci/pcidevs
> > @@ -754,6 +754,7 @@ product AMD AMD64_17_CCP_2 0x1468 AMD64 17h Crypto
> > product AMD AMD64_17_PCIE_40x1470 AMD64 17h PCIE
> > product AMD AMD64_17_PCIE_50x1471 AMD64 17h PCIE
> > product AMD AMD64_17_3X_RC 0x1480 AMD64 17h/3xh Root Complex
> > +product AMD AMD64_17_3X_CCP0x1486 AMD64 17h/3xh Crypto
> > product AMD AMD64_14_HB0x1510 AMD64 14h Host
> > product AMD AMD64_14_PCIE_10x1512 AMD64 14h PCIE
> > product AMD AMD64_14_PCIE_20x1513 AMD64 14h PCIE
> >
> >
Re: Add pcidev for Ryzen 3x ccp
On Wed, Jan 01, 2020 at 09:53:39AM -0500, Todd Mortimer wrote:
> My CPU has a CCP that isn't in the known list, so add it and tell ccp
> about it.
>
> Tested on Ryzen 3900x.
>
> ok?
>
> Will commit a pcidevs regen immediately after.
Are your cpu lines in dmesg 17-3* or 17-7*?
Ryzen 3900x should be model 7X.
>
>
> diff --git a/sys/dev/pci/ccp_pci.c b/sys/dev/pci/ccp_pci.c
> index 2259594644b..c8dcc8750fc 100644
> --- a/sys/dev/pci/ccp_pci.c
> +++ b/sys/dev/pci/ccp_pci.c
> @@ -47,6 +47,7 @@ static const struct pci_matchid ccp_pci_devices[] = {
> { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_CCP_1 },
> { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_CCP_2 },
> { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_1X_CCP },
> + { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_3X_CCP },
> };
>
> int
> diff --git a/sys/dev/pci/pcidevs b/sys/dev/pci/pcidevs
> index d0a021b89bc..fb918e8de5d 100644
> --- a/sys/dev/pci/pcidevs
> +++ b/sys/dev/pci/pcidevs
> @@ -754,6 +754,7 @@ product AMD AMD64_17_CCP_20x1468 AMD64 17h Crypto
> product AMD AMD64_17_PCIE_4 0x1470 AMD64 17h PCIE
> product AMD AMD64_17_PCIE_5 0x1471 AMD64 17h PCIE
> product AMD AMD64_17_3X_RC 0x1480 AMD64 17h/3xh Root Complex
> +product AMD AMD64_17_3X_CCP 0x1486 AMD64 17h/3xh Crypto
> product AMD AMD64_14_HB 0x1510 AMD64 14h Host
> product AMD AMD64_14_PCIE_1 0x1512 AMD64 14h PCIE
> product AMD AMD64_14_PCIE_2 0x1513 AMD64 14h PCIE
>
>
Re: uow(4) & tsleep
On Wed, Jan 01, 2020 at 03:32:09PM +0100, Martin Pieuchot wrote:
> UOW_TIMEOUT is expressed in msec, so use MSEC_TO_NSEC() and tsleep_nsec(9)
> instead of dereferencing `hz'.
>
> Ok?
OK bluhm@
> Index: uow.c
> ===
> RCS file: /cvs/src/sys/dev/usb/uow.c,v
> retrieving revision 1.35
> diff -u -p -r1.35 uow.c
> --- uow.c 6 Nov 2016 12:58:01 - 1.35
> +++ uow.c 1 Jan 2020 14:23:19 -
> @@ -424,8 +424,8 @@ uow_cmd(struct uow_softc *sc, int type,
> }
>
> again:
> - if (tsleep(sc->sc_regs, PRIBIO, "uowcmd",
> - (UOW_TIMEOUT * hz) / 1000) != 0) {
> + if (tsleep_nsec(sc->sc_regs, PRIBIO, "uowcmd",
> + MSEC_TO_NSEC(UOW_TIMEOUT)) != 0) {
> printf("%s: cmd timeout, type 0x%02x, cmd 0x%04x, "
> "param 0x%04x\n", sc->sc_dev.dv_xname, type, cmd,
> param);
Re: ugen(4) and tsleep_nsec(9)
On Wed, Jan 01, 2020 at 03:22:30PM +0100, Martin Pieuchot wrote:
> `sce' timeouts, like most of the USB timeouts are expressed in ms. So
> use MSEC_TO_NSEC() and tsleep_nsec(9) accordingly.
>
> Ok?
OK bluhm@
I prefer unique sleeping strings for easier debugging.
Can we change that to "ugenrint" and "ugenriso"?
> Index: ugen.c
> ===
> RCS file: /cvs/src/sys/dev/usb/ugen.c,v
> retrieving revision 1.100
> diff -u -p -r1.100 ugen.c
> --- ugen.c31 Dec 2019 13:48:31 - 1.100
> +++ ugen.c1 Jan 2020 14:20:14 -
> @@ -510,8 +510,8 @@ ugen_do_read(struct ugen_softc *sc, int
> }
> sce->state |= UGEN_ASLP;
> DPRINTFN(5, ("ugenread: sleep on %p\n", sce));
> - error = tsleep(sce, PZERO | PCATCH, "ugenri",
> - (sce->timeout * hz) / 1000);
> + error = tsleep_nsec(sce, PZERO | PCATCH, "ugenri",
> + MSEC_TO_NSEC(sce->timeout));
> sce->state &= ~UGEN_ASLP;
> DPRINTFN(5, ("ugenread: woke, error=%d\n", error));
> if (usbd_is_dying(sc->sc_udev))
> @@ -582,8 +582,8 @@ ugen_do_read(struct ugen_softc *sc, int
> }
> sce->state |= UGEN_ASLP;
> DPRINTFN(5, ("ugenread: sleep on %p\n", sce));
> - error = tsleep(sce, PZERO | PCATCH, "ugenri",
> - (sce->timeout * hz) / 1000);
> + error = tsleep_nsec(sce, PZERO | PCATCH, "ugenri",
> + MSEC_TO_NSEC(sce->timeout));
> sce->state &= ~UGEN_ASLP;
> DPRINTFN(5, ("ugenread: woke, error=%d\n", error));
> if (usbd_is_dying(sc->sc_udev))
Add pcidev for Ryzen 3x ccp
My CPU has a CCP that isn't in the known list, so add it and tell ccp
about it.
Tested on Ryzen 3900x.
ok?
Will commit a pcidevs regen immediately after.
diff --git a/sys/dev/pci/ccp_pci.c b/sys/dev/pci/ccp_pci.c
index 2259594644b..c8dcc8750fc 100644
--- a/sys/dev/pci/ccp_pci.c
+++ b/sys/dev/pci/ccp_pci.c
@@ -47,6 +47,7 @@ static const struct pci_matchid ccp_pci_devices[] = {
{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_CCP_1 },
{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_CCP_2 },
{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_1X_CCP },
+ { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_17_3X_CCP },
};
int
diff --git a/sys/dev/pci/pcidevs b/sys/dev/pci/pcidevs
index d0a021b89bc..fb918e8de5d 100644
--- a/sys/dev/pci/pcidevs
+++ b/sys/dev/pci/pcidevs
@@ -754,6 +754,7 @@ product AMD AMD64_17_CCP_2 0x1468 AMD64 17h Crypto
product AMD AMD64_17_PCIE_40x1470 AMD64 17h PCIE
product AMD AMD64_17_PCIE_50x1471 AMD64 17h PCIE
product AMD AMD64_17_3X_RC 0x1480 AMD64 17h/3xh Root Complex
+product AMD AMD64_17_3X_CCP0x1486 AMD64 17h/3xh Crypto
product AMD AMD64_14_HB0x1510 AMD64 14h Host
product AMD AMD64_14_PCIE_10x1512 AMD64 14h PCIE
product AMD AMD64_14_PCIE_20x1513 AMD64 14h PCIE
uow(4) & tsleep
UOW_TIMEOUT is expressed in msec, so use MSEC_TO_NSEC() and tsleep_nsec(9)
instead of dereferencing `hz'.
Ok?
Index: uow.c
===
RCS file: /cvs/src/sys/dev/usb/uow.c,v
retrieving revision 1.35
diff -u -p -r1.35 uow.c
--- uow.c 6 Nov 2016 12:58:01 - 1.35
+++ uow.c 1 Jan 2020 14:23:19 -
@@ -424,8 +424,8 @@ uow_cmd(struct uow_softc *sc, int type,
}
again:
- if (tsleep(sc->sc_regs, PRIBIO, "uowcmd",
- (UOW_TIMEOUT * hz) / 1000) != 0) {
+ if (tsleep_nsec(sc->sc_regs, PRIBIO, "uowcmd",
+ MSEC_TO_NSEC(UOW_TIMEOUT)) != 0) {
printf("%s: cmd timeout, type 0x%02x, cmd 0x%04x, "
"param 0x%04x\n", sc->sc_dev.dv_xname, type, cmd,
param);
ugen(4) and tsleep_nsec(9)
`sce' timeouts, like most of the USB timeouts are expressed in ms. So
use MSEC_TO_NSEC() and tsleep_nsec(9) accordingly.
Ok?
Index: ugen.c
===
RCS file: /cvs/src/sys/dev/usb/ugen.c,v
retrieving revision 1.100
diff -u -p -r1.100 ugen.c
--- ugen.c 31 Dec 2019 13:48:31 - 1.100
+++ ugen.c 1 Jan 2020 14:20:14 -
@@ -510,8 +510,8 @@ ugen_do_read(struct ugen_softc *sc, int
}
sce->state |= UGEN_ASLP;
DPRINTFN(5, ("ugenread: sleep on %p\n", sce));
- error = tsleep(sce, PZERO | PCATCH, "ugenri",
- (sce->timeout * hz) / 1000);
+ error = tsleep_nsec(sce, PZERO | PCATCH, "ugenri",
+ MSEC_TO_NSEC(sce->timeout));
sce->state &= ~UGEN_ASLP;
DPRINTFN(5, ("ugenread: woke, error=%d\n", error));
if (usbd_is_dying(sc->sc_udev))
@@ -582,8 +582,8 @@ ugen_do_read(struct ugen_softc *sc, int
}
sce->state |= UGEN_ASLP;
DPRINTFN(5, ("ugenread: sleep on %p\n", sce));
- error = tsleep(sce, PZERO | PCATCH, "ugenri",
- (sce->timeout * hz) / 1000);
+ error = tsleep_nsec(sce, PZERO | PCATCH, "ugenri",
+ MSEC_TO_NSEC(sce->timeout));
sce->state &= ~UGEN_ASLP;
DPRINTFN(5, ("ugenread: woke, error=%d\n", error));
if (usbd_is_dying(sc->sc_udev))
Re: TIMESPEC_TO_NSEC(), futex(2) & __thrsleep(2)
On 31/12/19(Tue) 15:00, Todd C. Miller wrote: > On Tue, 31 Dec 2019 16:35:59 +0100, Martin Pieuchot wrote: > > > I'd like to stop converting the given timespec to ticks and instead use > > nanoseconds. This is part of the ongoing effort to reduce the use of > > `hz' through the kernel. > > > > Since I don't know C I'd appreciate any pointer about the checks that > > should be added to TIMESPEC_TO_NSEC(). > > Is it possible for tv_sec or tv_nsec to be negative? Not in those two syscalls.
Re: TIMESPEC_TO_NSEC(), futex(2) & __thrsleep(2)
On 31/12/19(Tue) 17:44, Alexander Bluhm wrote:
> On Tue, Dec 31, 2019 at 04:35:59PM +0100, Martin Pieuchot wrote:
> > Since I don't know C I'd appreciate any pointer about the checks that
> > should be added to TIMESPEC_TO_NSEC().
>
> Perhaps this way?
Thanks.
> static inline uint64_t
> TIMESPEC_TO_NSEC(const struct timespec *ts)
> {
> if (ts->tv_sec > (UINT64_MAX - ts->tv_nsec) / 10ULL)
> return UINT64_MAX;
> return ts->tv_sec * 10ULL + ts->tv_nsec;
> }
>
> Should we use inline instead of __inline for new code?
ok mpi@
> Index: sys/time.h
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/sys/time.h,v
> retrieving revision 1.47
> diff -u -p -r1.47 time.h
> --- sys/time.h22 Oct 2019 20:19:41 - 1.47
> +++ sys/time.h31 Dec 2019 16:38:20 -
> @@ -177,7 +177,7 @@ struct bintime {
> (btp)->frac cmp (ctp)->frac : \
> (btp)->sec cmp (ctp)->sec)
>
> -static __inline void
> +static inline void
> bintimeaddfrac(const struct bintime *bt, uint64_t x, struct bintime *ct)
> {
> ct->sec = bt->sec;
> @@ -186,7 +186,7 @@ bintimeaddfrac(const struct bintime *bt,
> ct->frac = bt->frac + x;
> }
>
> -static __inline void
> +static inline void
> bintimeadd(const struct bintime *bt, const struct bintime *ct,
> struct bintime *dt)
> {
> @@ -196,7 +196,7 @@ bintimeadd(const struct bintime *bt, con
> dt->frac = bt->frac + ct->frac;
> }
>
> -static __inline void
> +static inline void
> bintimesub(const struct bintime *bt, const struct bintime *ct,
> struct bintime *dt)
> {
> @@ -220,14 +220,14 @@ bintimesub(const struct bintime *bt, con
> * time_second ticks after N.9 not after N.49
> */
>
> -static __inline void
> +static inline void
> BINTIME_TO_TIMESPEC(const struct bintime *bt, struct timespec *ts)
> {
> ts->tv_sec = bt->sec;
> ts->tv_nsec = (long)(((uint64_t)10 * (uint32_t)(bt->frac >>
> 32)) >> 32);
> }
>
> -static __inline void
> +static inline void
> TIMESPEC_TO_BINTIME(const struct timespec *ts, struct bintime *bt)
> {
> bt->sec = ts->tv_sec;
> @@ -235,14 +235,14 @@ TIMESPEC_TO_BINTIME(const struct timespe
> bt->frac = (uint64_t)ts->tv_nsec * (uint64_t)18446744073ULL;
> }
>
> -static __inline void
> +static inline void
> BINTIME_TO_TIMEVAL(const struct bintime *bt, struct timeval *tv)
> {
> tv->tv_sec = bt->sec;
> tv->tv_usec = (long)(((uint64_t)100 * (uint32_t)(bt->frac >> 32))
> >> 32);
> }
>
> -static __inline void
> +static inline void
> TIMEVAL_TO_BINTIME(const struct timeval *tv, struct bintime *bt)
> {
> bt->sec = (time_t)tv->tv_sec;
> @@ -332,14 +332,14 @@ void clock_secs_to_ymdhms(time_t, struct
> /* Traditional POSIX base year */
> #define POSIX_BASE_YEAR 1970
>
> -static __inline void
> +static inline void
> NSEC_TO_TIMEVAL(uint64_t ns, struct timeval *tv)
> {
> tv->tv_sec = ns / 10L;
> tv->tv_usec = (ns % 10L) / 1000;
> }
>
> -static __inline void
> +static inline void
> NSEC_TO_TIMESPEC(uint64_t ns, struct timespec *ts)
> {
> ts->tv_sec = ns / 10L;
> @@ -348,7 +348,7 @@ NSEC_TO_TIMESPEC(uint64_t ns, struct tim
>
> #include
>
> -static __inline uint64_t
> +static inline uint64_t
> SEC_TO_NSEC(uint64_t seconds)
> {
> if (seconds > UINT64_MAX / 10ULL)
> @@ -356,7 +356,7 @@ SEC_TO_NSEC(uint64_t seconds)
> return seconds * 10ULL;
> }
>
> -static __inline uint64_t
> +static inline uint64_t
> MSEC_TO_NSEC(uint64_t milliseconds)
> {
> if (milliseconds > UINT64_MAX / 100ULL)
> @@ -364,7 +364,7 @@ MSEC_TO_NSEC(uint64_t milliseconds)
> return milliseconds * 100ULL;
> }
>
> -static __inline uint64_t
> +static inline uint64_t
> USEC_TO_NSEC(uint64_t microseconds)
> {
> if (microseconds > UINT64_MAX / 1000ULL)
>
