Re: svn commit: r334054 - in head: sys/kern sys/netipsec tools/tools/crypto usr.bin/netstat

[Ravi Pokala]

-Original Message-
From:  on behalf of Fabien Thomas 

Date: 2018-05-22, Tuesday at 08:54
To: , , 

Subject: svn commit: r334054 - in head: sys/kern sys/netipsec 
tools/tools/crypto usr.bin/netstat

> Author: fabient
> Date: Tue May 22 15:54:25 2018
> New Revision: 334054
> URL: https://svnweb.freebsd.org/changeset/base/334054
> 
> Log:
>   Add a SPD cache to speed up lookups.

What does "SPD" expand to in this context? I usually hack on platform stuff, 
and "Serial Presence Detect" doesn't seem applicable to this change. :-)

Thanks,

Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r334054 - in head: sys/kern sys/netipsec tools/tools/crypto usr.bin/netstat

[Ravi Pokala]

-Original Message-
From: Fabien Thomas 
Date: 2018-05-22, Tuesday at 09:00
To: Fabien Thomas , , Ravi Pokala 
, , 
Subject: Re: svn commit: r334054 - in head: sys/kern sys/netipsec 
tools/tools/crypto usr.bin/netstat
  
> Le 22 mai 2018 à 17:58:10, Ravi Pokala (rpok...@freebsd.org) a écrit:
> 
>> -Original Message- 
>> From:  on behalf of Fabien Thomas 
>>  
>> Date: 2018-05-22, Tuesday at 08:54 
>> To: , , 
>>  
>> Subject: svn commit: r334054 - in head: sys/kern sys/netipsec 
>> tools/tools/crypto usr.bin/netstat 
>> 
>>> Author: fabient 
>>> Date: Tue May 22 15:54:25 2018 
>>> New Revision: 334054 
>>> URL: https://svnweb.freebsd.org/changeset/base/334054 
>>> 
>>> Log: 
>>> Add a SPD cache to speed up lookups. 
>> 
>> What does "SPD" expand to in this context? I usually hack on platform stuff, 
>> and "Serial Presence Detect" doesn't seem applicable to this change. :-) 
> 
> Yes, that was not obvious after reading the comment again. :)
> SPD is related to IPsec so Security Policy Database.

Thank you!

Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r334115 - in head: share/man/man4 sys/dev/usb/template

[Ravi Pokala]

Hi Traz,

You're referring to power consumption in terms of (milli)Amps. That's not 
right; power is measured in Watts. What you're actually talking about is 
*current*. And it looks like in some situations USB devices can draw more than 
500mA.

https://en.wikipedia.org/wiki/USB_(Physical)#POWER

Thanks,

Ravi (rpokala@) 

-Original Message-
From:  on behalf of Edward Tomasz Napierala 

Date: 2018-05-23, Wednesday at 13:06
To: , , 

Subject: svn commit: r334115 - in head: share/man/man4 sys/dev/usb/template

Author: trasz
Date: Wed May 23 20:06:04 2018
New Revision: 334115
URL: https://svnweb.freebsd.org/changeset/base/334115

Log:
  Centralize USB device mode bus power reporting, and add
  hw.usb.template_power sysctl to control it.
  
  Reviewed by:  hselasky@ (earlier version)
  MFC after:2 weeks
  Sponsored by: The FreeBSD Foundation

Modified:
  head/share/man/man4/usb_template.4
  head/sys/dev/usb/template/usb_template.c
  head/sys/dev/usb/template/usb_template_audio.c
  head/sys/dev/usb/template/usb_template_cdce.c
  head/sys/dev/usb/template/usb_template_kbd.c
  head/sys/dev/usb/template/usb_template_midi.c
  head/sys/dev/usb/template/usb_template_modem.c
  head/sys/dev/usb/template/usb_template_mouse.c
  head/sys/dev/usb/template/usb_template_msc.c
  head/sys/dev/usb/template/usb_template_mtp.c
  head/sys/dev/usb/template/usb_template_multi.c
  head/sys/dev/usb/template/usb_template_phone.c
  head/sys/dev/usb/template/usb_template_serialnet.c

Modified: head/share/man/man4/usb_template.4
==
--- head/share/man/man4/usb_template.4  Wed May 23 19:55:47 2018
(r334114)
+++ head/share/man/man4/usb_template.4  Wed May 23 20:06:04 2018
(r334115)
@@ -23,7 +23,7 @@
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
-.Dd May 17, 2018
+.Dd May 23, 2018
 .Dt USB_TEMPLATE 4
 .Os
 .
@@ -100,6 +100,11 @@ tunables:
 .It Va hw.usb.template
 Currently selected template.
 Set to -1 to make the device disappear from the USB host point of view.
+.It Va hw.usb.template_power
+USB bus power consumption in mA.
+Must be between 0 and 500.
+Setting to 0 marks the device as self-powered.
+Defaults to 500mA.
 .It Va hw.usb.templates.N
 Configuration for template number
 .Va N .

Modified: head/sys/dev/usb/template/usb_template.c
==
--- head/sys/dev/usb/template/usb_template.cWed May 23 19:55:47 2018
(r334114)
+++ head/sys/dev/usb/template/usb_template.cWed May 23 20:06:04 2018
(r334115)
@@ -76,14 +76,12 @@
 #include 
 #endif /* USB_GLOBAL_INCLUDE_FILE */
 
-SYSCTL_NODE(_hw_usb, OID_AUTO, templates, CTLFLAG_RW, 0,
-"USB device side templates");
-
 MODULE_DEPEND(usb_template, usb, 1, 1, 1);
 MODULE_VERSION(usb_template, 1);
 
 /* function prototypes */
 
+static int sysctl_hw_usb_template_power(SYSCTL_HANDLER_ARGS);
 static voidusb_make_raw_desc(struct usb_temp_setup *, const uint8_t *);
 static voidusb_make_endpoint_desc(struct usb_temp_setup *,
const struct usb_temp_endpoint_desc *);
@@ -117,6 +115,33 @@ static usb_error_t usb_temp_setup_by_index(struct usb_
uint16_t index);
 static voidusb_temp_init(void *);
 
+SYSCTL_NODE(_hw_usb, OID_AUTO, templates, CTLFLAG_RW, 0,
+"USB device side templates");
+SYSCTL_PROC(_hw_usb, OID_AUTO, template_power,
+CTLTYPE_INT | CTLFLAG_RWTUN | CTLFLAG_MPSAFE,
+NULL, 0, sysctl_hw_usb_template_power,
+"I", "USB bus power consumption in mA");
+
+static int usb_template_power = 500;   /* 500mA */
+
+static int
+sysctl_hw_usb_template_power(SYSCTL_HANDLER_ARGS)
+{
+   int error, val;
+
+   val = usb_template_power;
+   error = sysctl_handle_int(oidp, &val, 0, req);
+   if (error != 0 || req->newptr == NULL)
+   return (error);
+
+   if (val < 0 || val > 500)
+   return (EINVAL);
+
+   usb_template_power = val;
+
+   return (0);
+}
+
 /**
  * usb_decode_str_desc
  *
@@ -426,6 +451,7 @@ usb_make_config_desc(struct usb_temp_setup *temp,
struct usb_config_descriptor *cd;
const struct usb_temp_interface_desc **tid;
uint16_t old_size;
+   int power;
 
/* Reserve memory */
 
@@ -463,13 +489,16 @@ usb_make_config_desc(struct usb_temp_setup *temp,
cd->bConfigurationValue = temp->bConfigurationValue;
cd->iConfiguration = tcd->iConfiguration;
cd->bmAttributes = tcd->bmAttributes;
-   cd->bMaxPower = tcd->bMaxPower;
-   cd->bmAttributes |= (UC_REMOTE_WAKEUP | UC_BUS_POWERED);
 
-   if (temp->self_powered) {
-   cd->bmAttributes |= UC_SELF_POWERED;
-   } else {
+   power = usb_

Re: svn commit: r334129 - head/sys/amd64/conf

[Ravi Pokala]

-Original Message-
From:  on behalf of Matt Macy 

Date: 2018-05-23, Wednesday at 21:31
To: , , 

Subject: svn commit: r334129 - head/sys/amd64/conf

> Author: mmacy
> Date: Thu May 24 04:31:53 2018
> New Revision: 334129
> URL: https://svnweb.freebsd.org/changeset/base/334129
> 
> Log:
>   take NUMA out
> 
> Modified:
>   head/sys/amd64/conf/GENERIC-NODEBUG
> 
> Modified: head/sys/amd64/conf/GENERIC-NODEBUG
> ==
> --- head/sys/amd64/conf/GENERIC-NODEBUG   Thu May 24 04:30:06 2018
> (r334128)
> +++ head/sys/amd64/conf/GENERIC-NODEBUG   Thu May 24 04:31:53 2018
> (r334129)
> @@ -38,4 +38,3 @@ nooptions   BUF_TRACKING
>  nooptions   DEADLKRES
>  nooptions   FULL_BUF_TRACKING
>  
> -options  NUMA

Why?

-Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r334364 - head/sys/conf

[Ravi Pokala]

Author: rpokala
Date: Wed May 30 02:26:36 2018
New Revision: 334364
URL: https://svnweb.freebsd.org/changeset/base/334364

Log:
  Remove the mlx5 driver from LINT kernel config for 32-bit PPC
  
  The mlx5 driver requires 64-bit atomics, which are not supported on 32-bit
  PPC. Exclude that driver from the LINT kernel config.
  
  Submitted by: hps (but I re-worded the comment)
  Reported by:  rpokala
  Reviewed by:  jhibbits
  Differential Revision:https://reviews.freebsd.org/D15611

Modified:
  head/sys/conf/makeLINT.mk

Modified: head/sys/conf/makeLINT.mk
==
--- head/sys/conf/makeLINT.mk   Wed May 30 01:16:50 2018(r334363)
+++ head/sys/conf/makeLINT.mk   Wed May 30 02:26:36 2018(r334364)
@@ -55,4 +55,8 @@ LINT: ${NOTES} ${MAKELINT_SED}
cat ${.TARGET} > ${.TARGET}64
echo "machine   ${TARGET} powerpc" >> ${.TARGET}
echo "machine   ${TARGET} powerpc64" >> ${.TARGET}64
+# mlx5 needs 64-bit atomics, so exclude from 32-bit PPC
+   echo "nodevice mlx5" >> ${.TARGET}
+   echo "nodevice mlx5en" >> ${.TARGET}
+   echo "nodevice mlx5ib" >> ${.TARGET}
 .endif
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r334702 - head/sys/sys

[Ravi Pokala]

Hi Mateusz,

-Original Message-
From:  on behalf of Mateusz Guzik 

Date: 2018-06-06, Wednesday at 01:08
To: , , 

Subject: svn commit: r334702 - head/sys/sys

> Author: mjg
> Date: Wed Jun  6 05:08:05 2018
> New Revision: 334702
> URL: https://svnweb.freebsd.org/changeset/base/334702
> 
> Log:
>   malloc: elaborate on r334545 due to frequent questions

I was one of the questioners. :-) Thank you for explaining the conditional 
logic.

> ...
> + * Passing the flag down requires malloc to blindly zero the entire object.
> + * In practice a lot of the zeroing can be avoided if most of the object
> + * gets explicitly initialized after the allocation. Letting the compiler
> + * zero in place gives it the opportunity to take advantage of this state.

This part, I still don't understand. :-(

The call to bzero() is still for the full length passed in, so how does this 
help?

> ...
> + *   _malloc_item = malloc(_size, type, (flags) &~ M_ZERO);
> + *   if (((flags) & M_WAITOK) != 0 || _malloc_item != NULL)
> + *   bzero(_malloc_item, _size);
> + *
> + * If the flag is set, the compiler knows the left side is always true,
> + * therefore the entire statement is true and the callsite is:

I think you mean "... the *right* side is always true ...", since the left side 
is the check for the flag being set. "If the flag is set, compiler knows (the 
check for the flag being set) is always true" is tautological.

> ...
> + * If the flag is not set, the compiler knows the left size is always false
> + * and the NULL check is needed, therefore the callsite is:

Same issue here.

> ...
>  #ifdef _KERNEL
>  #define  malloc(size, type, flags) ({
> \

Now that I'm taking another look at this, I'm confused as to why the entire 
macro expansion is inside parentheses? (The braces make sense, since this is a 
block with local variables which need to be contained.)

>   void *_malloc_item; \
> @@ -193,7 +228,8 @@ void  *malloc(size_t size, struct malloc_type *type, 
> in
>   if (__builtin_constant_p(size) && __builtin_constant_p(flags) &&\
>   ((flags) & M_ZERO) != 0) {  \
>   _malloc_item = malloc(_size, type, (flags) &~ M_ZERO);  \
> - if (((flags) & M_WAITOK) != 0 || _malloc_item != NULL)  \
> + if (((flags) & M_WAITOK) != 0 ||\
> + __predict_true(_malloc_item != NULL))   \
>   bzero(_malloc_item, _size); \
>   } else {\
>   _malloc_item = malloc(_size, type, flags);  \

This confuses me too. If the constant-size/constant-flags/M_ZERO-is-set test 
fails, then it falls down to calling malloc(). Which we are in the middle of 
defining. So what does that expand to?

Thanks,

Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r334702 - head/sys/sys

[Ravi Pokala]

-Original Message-
From:  on behalf of Benjamin Kaduk 

Date: 2018-06-06, Wednesday at 07:40
To: Ravi Pokala 
Cc: Mateusz Guzik , src-committers 
, , 

Subject: Re: svn commit: r334702 - head/sys/sys

> On Wed, Jun 6, 2018 at 6:35 AM, Ravi Pokala  wrote:
>> 
>> Hi Mateusz,
>> 
>> -Original Message-
>> From:  on behalf of Mateusz Guzik 
>> 
>> Date: 2018-06-06, Wednesday at 01:08
>> To: , , 
>> 
>> Subject: svn commit: r334702 - head/sys/sys
>> 
>>> ...
>>>  #ifdef _KERNEL
>>>  #define  malloc(size, type, flags) ({  
>>>   \
>> 
>> Now that I'm taking another look at this, I'm confused as to why the entire 
>> macro expansion is inside parentheses? (The braces make sense, since this is 
>> a block with local variables which need to be contained.)
> 
> This is a gcc (and clang) extension to allow the macro body to be a code 
> block -- standard C gets unhappy with just the curly braces.  
> https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html is a maybe-relevant 
> page that google found me.

"Neat." Thanks Ben.

-Ravi

> -Ben 





___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r334702 - head/sys/sys

[Ravi Pokala]

-Original Message-
From:  on behalf of Mateusz Guzik 

Date: 2018-06-06, Wednesday at 09:01
To: Ravi Pokala 
Cc: Mateusz Guzik , src-committers 
, , 

Subject: Re: svn commit: r334702 - head/sys/sys

> On Wed, Jun 6, 2018 at 1:35 PM, Ravi Pokala  wrote:
> 
>>> + * Passing the flag down requires malloc to blindly zero the entire object.
>>> + * In practice a lot of the zeroing can be avoided if most of the object
>>> + * gets explicitly initialized after the allocation. Letting the compiler
>>> + * zero in place gives it the opportunity to take advantage of this state.
>>
>> This part, I still don't understand. :-(
> 
> The call to bzero() is still for the full length passed in, so how does this 
> help?
> 
> bzero is:
> #define bzero(buf, len) __builtin_memset((buf), 0, (len))

I'm afraid that doesn't answer my question; you're passing the full length to 
__builtin_memset() too.

>>> ...
>>> + *   _malloc_item = malloc(_size, type, (flags) &~ M_ZERO);
>>> + *   if (((flags) & M_WAITOK) != 0 || _malloc_item != NULL)
>>> + *   bzero(_malloc_item, _size);
>>> + *
>>> + * If the flag is set, the compiler knows the left side is always true,
>>> + * therefore the entire statement is true and the callsite is:
>> 
>> I think you mean "... the *right* side is always true ...", since the left 
>> side is the check for the flag being set. "If the flag is set, compiler 
>> knows (the check for the flag being set) is always true" is tautological.
> 
> It explains how __builtin_constant_p(flags) being true allows the compiler
> to optimize out the flags-based check.

The __builtin_constant_p()s are in the conditional *before* the one I'm asking 
about. The test for M_WAITOK on the left being true, will cause the NULL-check 
on the right to be skipped because of the short-circuit semantics of binary ||. 
But because M_WAITOK is set, the NULL-check will pass anyway... Ah, and that's 
what you meant by "therefore the entire statement is true".

I think the wording was throwing me; it might be clearer English to say 
something like "If the flag is set -- and we only get here if that can be 
determined at compile-time, because of __builtin_constant_p() -- then the 
entire statement is true. This skips the NULL-check, but it will always pass if 
the flag is set anyway."

> I don't understand why this particular use runs into so much confusion.
> Just above it there is a M_ZERO check relying on the same property and
> receiving no attention.

In that context, it's clearer what's the condition is:
- "size" must be constant at compile-time
- "flags" must be constant at compile-time
- "flags" must have M_ZERO set

>>> ...
>>> + * If the flag is not set, the compiler knows the left size is always false
>>> + * and the NULL check is needed, therefore the callsite is:
>> 
>> Same issue here.

And same answer here too.

>>> ...
>>>  #ifdef _KERNEL
>>>  #define  malloc(size, type, flags) ({  
>>>   \
>> 
>> Now that I'm taking another look at this, I'm confused as to why the entire 
>> macro expansion is inside parentheses? (The braces make sense, since this is 
>> a block with local variables which need to be contained.)
> 
> It is to return the value (the last expression).

Yeah, Ben / Bruce / Conrad clarified that.

>>>   void *_malloc_item; \
>>> @@ -193,7 +228,8 @@ void  *malloc(size_t size, struct malloc_type 
>>> *type, in
>>>   if (__builtin_constant_p(size) && __builtin_constant_p(flags) &&\
>>>   ((flags) & M_ZERO) != 0) {  \
>>>   _malloc_item = malloc(_size, type, (flags) &~ M_ZERO);  \
>>> - if (((flags) & M_WAITOK) != 0 || _malloc_item != NULL)  \
>>> + if (((flags) & M_WAITOK) != 0 ||\
>>> + __predict_true(_malloc_item != NULL))   \
>>>   bzero(_malloc_item, _size); \
>>>   } else {\
>>>   _malloc_item = malloc(_size, type, flags);  \
>> 
>> This confuses me too. If the constant-size/constant-flags/M_ZERO-is-set test 
>> fails, then it falls down to calling malloc(). Which we are in the middle of 
>> defining. So what does that expand to?
> 
> Expansion is not recursive, so this is an actual call to malloc. 

Ah, right. I swear I knew that at some point. :-)

> -- 
> Mateusz Guzik http://gmail.com>>

Thanks Mateusz,

-Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r334702 - head/sys/sys

[Ravi Pokala]

> I believe the theory is that the compiler (remember, this is 
> __builtin_memset) can optimize away portions of the zeroing, or can optimize 
> zeroing for small sizes.

Ahhh! I didn't consider that the compiler would be doing analysis of the larger 
context, and potentially skipping zeroing parts that are set immediately after 
the call.

Thanks!

-Ravi (rpokala@)

-Original Message-
From: "Jonathan T. Looney" 
Date: 2018-06-06, Wednesday at 22:58
To: Ravi Pokala 
Cc: Mateusz Guzik , Mateusz Guzik , 
src-committers , , 

Subject: Re: svn commit: r334702 - head/sys/sys

> On Wed, Jun 6, 2018 at 10:14 PM, Ravi Pokala  wrote:
>>
>> -Original Message-
>> From:  on behalf of Mateusz Guzik 
>> 
>> Date: 2018-06-06, Wednesday at 09:01
>> To: Ravi Pokala 
>> Cc: Mateusz Guzik , src-committers 
>> , , 
>> 
>> Subject: Re: svn commit: r334702 - head/sys/sys
>>
>>> On Wed, Jun 6, 2018 at 1:35 PM, Ravi Pokala  wrote:
>>>
>>>>> + * Passing the flag down requires malloc to blindly zero the entire 
>>>>> object.
>>>>> + * In practice a lot of the zeroing can be avoided if most of the object
>>>>> + * gets explicitly initialized after the allocation. Letting the compiler
>>>>> + * zero in place gives it the opportunity to take advantage of this 
>>>>> state.
>>>>
>>>> This part, I still don't understand. :-(
>>>
>>> The call to bzero() is still for the full length passed in, so how does 
>>> this help?
>>>
>>> bzero is:
>>> #define bzero(buf, len) __builtin_memset((buf), 0, (len))
>> 
>> I'm afraid that doesn't answer my question; you're passing the full length 
>> to __builtin_memset() too.
> 
> I believe the theory is that the compiler (remember, this is 
> __builtin_memset) can optimize away portions of the zeroing, or can optimize 
> zeroing for small sizes.
> 
> For example, imagine you do this:
> 
> struct foo {
> uint32_t a;
> uint32_t b;
> };
> 
> struct foo *
> alloc_foo(void)
> {
> struct foo *rv;
> 
> rv = malloc(sizeof(*rv), M_TMP, M_WAITOK|M_ZERO);
> rv->a = 1;
> rv->b = 2;
> return (rv);
> }
> 
> In theory, the compiler can be smart enough to know that the entire structure 
> is initialized, so it is not necessary to zero it.
> 
> (I personally have not tested how well this works in practice. However, this 
> change theoretically lets the compiler be smarter and optimize away unneeded 
> work.)
> 
> At minimum, it should let the compiler replace calls to memset() (and the 
> loops there) with optimal instructions to zero the exact amount of memory 
> that needs to be initialized. (Again, I haven't personally tested how smart 
> the compilers we use are about producing optimal code in this situation.)
> 
> Jonathan


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r334702 - head/sys/sys

[Ravi Pokala]

-Original Message-
From: Brooks Davis 
Date: 2018-06-07, Thursday at 09:27
To: Ravi Pokala 
Cc: "Jonathan T. Looney" , Mateusz Guzik , 
Mateusz Guzik , src-committers , 
, 
Subject: Re: svn commit: r334702 - head/sys/sys

> On Thu, Jun 07, 2018 at 12:01:00AM -0400, Ravi Pokala wrote:
>>> I believe the theory is that the compiler (remember, this is 
>>> __builtin_memset) can optimize away portions of the zeroing, or can 
>>> optimize zeroing for small sizes.
>> 
>> Ahhh! I didn't consider that the compiler would be doing analysis of the 
>> larger context, and potentially skipping zeroing parts that are set 
>> immediately after the call.
> 
> Clang does this.  It does make for some quite interesting object code,
> but the result is that zeroing with __builtin_memset() is basically free
> for mostly-initialized structures.
> 
> -- Brooks

Yeah, it's a subtle but obvious optimization in hindsight. Thanks for the info.

-Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r335066 - in head/sys: kern sys

[Ravi Pokala]

Hi Warner,

I have many questions...

"Car limit"? I'm not sure what you mean by that?

This change starts tracking the total number of BIOs on the queue, but doesn't 
actually do anything with that value.

When there are more requests batched than the limit, your comment say you 
"start over", and the code says you bioq_insert_tail(). Why does the latter 
imply "start(ing) over"?

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Warner Losh 

Date: 2018-06-13, Wednesday at 12:48
To: , , 

Subject: svn commit: r335066 - in head/sys: kern sys

Author: imp
Date: Wed Jun 13 16:48:07 2018
New Revision: 335066
URL: https://svnweb.freebsd.org/changeset/base/335066

Log:
  Implement a 'car limit' for bioq.
  
  Allow one to implement a 'car limit' for
  bioq_disksort. debug.bioq_batchsize sets the size of car limit. Every
  time we queue that many requests, we start over so that we limit the
  latency for requests when the software queue depths are large. A value
  of '0', the default, means to revert to the old behavior.
  
  Sponsored by: Netflix

Modified:
  head/sys/kern/subr_disk.c
  head/sys/sys/bio.h

Modified: head/sys/kern/subr_disk.c
==
--- head/sys/kern/subr_disk.c   Wed Jun 13 15:58:33 2018(r335065)
+++ head/sys/kern/subr_disk.c   Wed Jun 13 16:48:07 2018(r335066)
@@ -23,8 +23,13 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 
+static int bioq_batchsize = 0;
+SYSCTL_INT(_debug, OID_AUTO, bioq_batchsize, CTLFLAG_RW,
+&bioq_batchsize, 0, "BIOQ batch size");
+
 /*-
  * Disk error is the preface to plaintive error messages
  * about failing disk transfers.  It prints messages of the form
@@ -152,6 +157,8 @@ bioq_init(struct bio_queue_head *head)
TAILQ_INIT(&head->queue);
head->last_offset = 0;
head->insert_point = NULL;
+   head->total = 0;
+   head->batched = 0;
 }
 
 void
@@ -165,6 +172,7 @@ bioq_remove(struct bio_queue_head *head, struct bio *b
head->insert_point = NULL;
 
TAILQ_REMOVE(&head->queue, bp, bio_queue);
+   head->total--;
 }
 
 void
@@ -183,6 +191,8 @@ bioq_insert_head(struct bio_queue_head *head, struct b
if (head->insert_point == NULL)
head->last_offset = bp->bio_offset;
TAILQ_INSERT_HEAD(&head->queue, bp, bio_queue);
+   head->total++;
+   head->batched = 0;
 }
 
 void
@@ -190,6 +200,7 @@ bioq_insert_tail(struct bio_queue_head *head, struct b
 {
 
TAILQ_INSERT_TAIL(&head->queue, bp, bio_queue);
+   head->total++;
head->insert_point = bp;
head->last_offset = bp->bio_offset;
 }
@@ -248,6 +259,11 @@ bioq_disksort(struct bio_queue_head *head, struct bio 
return;
}
 
+   if (bioq_batchsize > 0 && head->batched > bioq_batchsize) {
+   bioq_insert_tail(head, bp);
+   return;
+   }
+
prev = NULL;
key = bioq_bio_key(head, bp);
cur = TAILQ_FIRST(&head->queue);
@@ -266,4 +282,6 @@ bioq_disksort(struct bio_queue_head *head, struct bio 
TAILQ_INSERT_HEAD(&head->queue, bp, bio_queue);
else
TAILQ_INSERT_AFTER(&head->queue, prev, bp, bio_queue);
+   head->total++;
+   head->batched++;
 }

Modified: head/sys/sys/bio.h
==
--- head/sys/sys/bio.h  Wed Jun 13 15:58:33 2018(r335065)
+++ head/sys/sys/bio.h  Wed Jun 13 16:48:07 2018(r335066)
@@ -138,6 +138,8 @@ struct bio_queue_head {
TAILQ_HEAD(bio_queue, bio) queue;
off_t last_offset;
struct  bio *insert_point;
+   int total;
+   int batched;
 };
 
 extern struct vm_map *bio_transient_map;



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326624 - head/sys/cam/ata

[Ravi Pokala]

> ... disks of >=1TiB that still use CHS addressing.

Out of morbid curiosity, are there any such monstrosities? 

-Ravi (rpokala@)

-Original Message-
From:  on behalf of Alan Somers 

Date: 2017-12-06, Wednesday at 09:01
To: , , 

Subject: svn commit: r326624 - head/sys/cam/ata

Author: asomers
Date: Wed Dec  6 17:01:25 2017
New Revision: 326624
URL: https://svnweb.freebsd.org/changeset/base/326624

Log:
  cam: fix sign-extension error in adagetparams
  
  adagetparams contains a sign-extension error that will cause the sector
  count to be incorrectly calculated for ATA disks of >=1TiB that still use
  CHS addressing. Disks using LBA48 addressing are unaffected.
  
  Reported by:  Coverity
  CID:  1007296
  Reviewed by:  ken
  MFC after:3 weeks
  Sponsored by: Spectra Logic Corp
  Differential Revision:https://reviews.freebsd.org/D13198

Modified:
  head/sys/cam/ata/ata_da.c

Modified: head/sys/cam/ata/ata_da.c
==
--- head/sys/cam/ata/ata_da.c   Wed Dec  6 14:53:53 2017(r326623)
+++ head/sys/cam/ata/ata_da.c   Wed Dec  6 17:01:25 2017(r326624)
@@ -3377,7 +3377,8 @@ adagetparams(struct cam_periph *periph, struct ccb_get
dp->heads = cgd->ident_data.heads;
dp->secs_per_track = cgd->ident_data.sectors;
dp->cylinders = cgd->ident_data.cylinders;
-   dp->sectors = cgd->ident_data.cylinders * dp->heads * 
dp->secs_per_track;  
+   dp->sectors = cgd->ident_data.cylinders *
+ (u_int32_t)(dp->heads * dp->secs_per_track);  
}
lbasize = (u_int32_t)cgd->ident_data.lba_size_1 |
  ((u_int32_t)cgd->ident_data.lba_size_2 << 16);




___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r326624 - head/sys/cam/ata

[Ravi Pokala]

Oh good, I'll be able to sleep tonight after all. :-)

-Ravi

-Original Message-
From:  on behalf of Alan Somers 

Date: 2017-12-06, Wednesday at 10:15
To: Ravi Pokala 
Cc: "src-committ...@freebsd.org" , 
"svn-src-...@freebsd.org" , "svn-src-head@freebsd.org" 

Subject: Re: svn commit: r326624 - head/sys/cam/ata

Nope.  The ATA spec prohibited them, and nobody ever manufactured any.  But you 
might be able to fake one with CTL or QEMU or something similar.

On Wed, Dec 6, 2017 at 10:11 AM, Ravi Pokala  wrote:

> ... disks of >=1TiB that still use CHS addressing.

Out of morbid curiosity, are there any such monstrosities? 

-Ravi (rpokala@)

-Original Message-
From:  on behalf of Alan Somers 

Date: 2017-12-06, Wednesday at 09:01
To: , , 

Subject: svn commit: r326624 - head/sys/cam/ata

Author: asomers
Date: Wed Dec  6 17:01:25 2017
New Revision: 326624
URL: https://svnweb.freebsd.org/changeset/base/326624

Log:
  cam: fix sign-extension error in adagetparams

  adagetparams contains a sign-extension error that will cause the sector
  count to be incorrectly calculated for ATA disks of >=1TiB that still use
  CHS addressing. Disks using LBA48 addressing are unaffected.

  Reported by:  Coverity
  CID:  1007296
  Reviewed by:  ken
  MFC after:3 weeks
  Sponsored by: Spectra Logic Corp
  Differential Revision:https://reviews.freebsd.org/D13198

Modified:
  head/sys/cam/ata/ata_da.c

Modified: head/sys/cam/ata/ata_da.c
==
--- head/sys/cam/ata/ata_da.c   Wed Dec  6 14:53:53 2017(r326623)
+++ head/sys/cam/ata/ata_da.c   Wed Dec  6 17:01:25 2017(r326624)
@@ -3377,7 +3377,8 @@ adagetparams(struct cam_periph *periph, struct ccb_get
dp->heads = cgd->ident_data.heads;
dp->secs_per_track = cgd->ident_data.sectors;
dp->cylinders = cgd->ident_data.cylinders;
-   dp->sectors = cgd->ident_data.cylinders * dp->heads * 
dp->secs_per_track;
+   dp->sectors = cgd->ident_data.cylinders *
+ (u_int32_t)(dp->heads * dp->secs_per_track);
}
lbasize = (u_int32_t)cgd->ident_data.lba_size_1 |
  ((u_int32_t)cgd->ident_data.lba_size_2 << 16);
















___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r327055 - head/share/man/man4

[Ravi Pokala]

Also updates the date on pci.4, in light of r327036 earlier today.

-Ravi (rpokala@)

-Original Message-
From:  on behalf of Warner Losh 

Date: 2017-12-20, Wednesday at 20:23
To: , , 

Subject: svn commit: r327055 - head/share/man/man4

Author: imp
Date: Thu Dec 21 04:23:00 2017
New Revision: 327055
URL: https://svnweb.freebsd.org/changeset/base/327055

Log:
  Provide a nda man page. Add cross referneces. Bump dates.
  Also, CAM is a storage subsystem, not a SCSI/ATA one these days.
  
  Sponsored by: Netflix

Added:
  head/share/man/man4/nda.4   (contents, props changed)
Modified:
  head/share/man/man4/Makefile
  head/share/man/man4/ada.4
  head/share/man/man4/da.4
  head/share/man/man4/pci.4
  head/share/man/man4/scsi.4

Modified: head/share/man/man4/Makefile
==
--- head/share/man/man4/MakefileThu Dec 21 04:21:59 2017
(r327054)
+++ head/share/man/man4/MakefileThu Dec 21 04:23:00 2017
(r327055)
@@ -382,6 +382,7 @@ MAN=aac.4 \
${_ntb_hw_intel.4} \
${_ntb_hw_plx.4} \
${_ntb_transport.4} \
+   ${_nda.4} \
${_if_ntb.4} \
null.4 \
numa.4 \
@@ -808,6 +809,7 @@ _if_wpi.4=  if_wpi.4
 _ipmi.4=   ipmi.4
 _io.4= io.4
 _linux.4=  linux.4
+_nda.4=nda.4
 _ndis.4=   ndis.4
 _nfe.4=nfe.4
 _nfsmb.4=  nfsmb.4

Modified: head/share/man/man4/ada.4
==
--- head/share/man/man4/ada.4   Thu Dec 21 04:21:59 2017(r327054)
+++ head/share/man/man4/ada.4   Thu Dec 21 04:23:00 2017(r327055)
@@ -25,7 +25,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd June 19, 2015
+.Dd December 20, 2017
 .Dt ADA 4
 .Os
 .Sh NAME
@@ -157,6 +157,7 @@ ATA device nodes
 .Xr cam 4 ,
 .Xr da 4 ,
 .Xr mvs 4 ,
+.Xr nda 4 ,
 .Xr siis 4
 .Sh HISTORY
 The

Modified: head/share/man/man4/da.4
==
--- head/share/man/man4/da.4Thu Dec 21 04:21:59 2017(r327054)
+++ head/share/man/man4/da.4Thu Dec 21 04:23:00 2017(r327055)
@@ -25,7 +25,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd October 11, 2015
+.Dd December 20, 2017
 .Dt DA 4
 .Os
 .Sh NAME
@@ -214,6 +214,7 @@ None.
 .Xr ada 4 ,
 .Xr cam 4 ,
 .Xr geom 4 ,
+.Xr nda 4 ,
 .Xr gpart 8
 .Sh HISTORY
 The

Added: head/share/man/man4/nda.4
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/share/man/man4/nda.4   Thu Dec 21 04:23:00 2017(r327055)
@@ -0,0 +1,87 @@
+.\" Copyright (c) 2017 Netflix, Inc
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\"
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\" $FreeBSD$
+.\"
+.Dd December 20, 2017
+.Dt NDA 4
+.Os
+.Sh NAME
+.Nm nda
+.Nd NVMe Direct Access device driver
+.Sh SYNOPSIS
+.Cd device nvme
+.Cd device scbus
+.Sh DESCRIPTION
+The
+.Nm
+driver provides support for direct access devices, implementing the
+.Tn NVMe
+command protocol, that are attached to the system through a host adapter
+supported by the CAM subsystem.
+.Sh SYSCTL VARIABLES
+The following variables are available as both
+.Xr sysctl 8
+variables and
+.Xr loader 8
+tunables:
+.Bl -tag -width 12
+.It Va kern.cam.nda.sort_io_queue
+.Pp
+This variable determines whether the software queued entries are
+sorted in LBA order or not.
+Sorting is almost always a waste of time.
+The default is to not sort.
+.El
+.Pp
+The following report per-device settings, and are read-only unless
+otherwise indicated. Replace
+.Va N
+with the device unit number.
+.Bl -tag -width 12
+.It Va

Re: svn commit: r327763 - in head/sys: conf contrib/zstd/lib/freebsd

[Ravi Pokala]

Hi Conrad,

Alas, this still doesn't look right on RISC-V:

zstd_kfreebsd.o: In function `__ctzdi2':

/usr/home/rpokala/freebsd/clean/base/head/sys/contrib/zstd/lib/freebsd/zstd_kfreebsd.c:58:
 undefined reference to `ffsll'

I got substantively the same error both before and after `pkg upgrade' brought 
in updated RISC-V stuff:

riscv64-binutils (2.29.51.20170726 -> 2.29_20180105,1)
riscv64-gcc (7.1.1 -> 7.2.0)

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Conrad Meyer 

Date: 2018-01-09, Tuesday at 22:30
To: , , 

Subject: svn commit: r327763 - in head/sys: conf contrib/zstd/lib/freebsd

Author: cem
Date: Wed Jan 10 06:30:59 2018
New Revision: 327763
URL: https://svnweb.freebsd.org/changeset/base/327763

Log:
  Finally, fix Zstd kernel build on MIPS and RISC-V
  
  Add an implementation of the intrinsics invoked by __builtin_ctz{,ll} and
  __builtin_clz{,ll}, and include this compilation unit on platforms that lack
  assembly intrinsics for those builtins (MIPS and RISC-V).
  
  Future cleanup work might involve bringing these into a mini libcompiler-rt
  for the standalone kernel environment.  Or cleaning up the approach upstream
  takes for builtins in standalone environments (or just FreeBSD).  For now,
  at least this builds, and doesn't require modifying the vendor code.
  
  Reported by:  jeff, markj, mizhka
  Reviewed by:  jhb (earlier version), rpokala (comment text earlier version)
  Sponsored by: Dell EMC Isilon

Added:
  head/sys/contrib/zstd/lib/freebsd/zstd_kfreebsd.c   (contents, props changed)
Modified:
  head/sys/conf/files.mips
  head/sys/conf/files.riscv

Modified: head/sys/conf/files.mips
==
--- head/sys/conf/files.mipsWed Jan 10 05:52:24 2018(r327762)
+++ head/sys/conf/files.mipsWed Jan 10 06:30:59 2018(r327763)
@@ -112,3 +112,6 @@ cddl/compat/opensolaris/kern/opensolaris_atomic.c   opti
 cddl/dev/dtrace/mips/dtrace_asm.S  optional dtrace 
compile-with "${DTRACE_S}"
 cddl/dev/dtrace/mips/dtrace_subr.c optional dtrace 
compile-with "${DTRACE_C}"
 cddl/dev/fbt/mips/fbt_isa.coptional dtrace_fbt | 
dtraceall compile-with "${FBT_C}"
+
+# Zstd
+contrib/zstd/lib/freebsd/zstd_kfreebsd.c   standard compile-with 
${ZSTD_C}

Modified: head/sys/conf/files.riscv
==
--- head/sys/conf/files.riscv   Wed Jan 10 05:52:24 2018(r327762)
+++ head/sys/conf/files.riscv   Wed Jan 10 06:30:59 2018(r327763)
@@ -56,3 +56,6 @@ riscv/riscv/uio_machdep.c standard
 riscv/riscv/uma_machdep.c  standard
 riscv/riscv/unwind.c   optionalddb | kdtrace_hooks | stack
 riscv/riscv/vm_machdep.c   standard
+
+# Zstd
+contrib/zstd/lib/freebsd/zstd_kfreebsd.c   standard compile-with 
${ZSTD_C}

Added: head/sys/contrib/zstd/lib/freebsd/zstd_kfreebsd.c
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/sys/contrib/zstd/lib/freebsd/zstd_kfreebsd.c   Wed Jan 10 06:30:59 
2018(r327763)
@@ -0,0 +1,75 @@
+/*-
+ * Copyright (c) 2018 Conrad Meyer 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * $FreeBSD$
+ */
+
+#include "zstd_kfreebsd.h"
+
+/*
+ * The kernel as a standalone target does not link against libgcc or
+ * libcompiler-rt. On platforms (e.g., MIPS and RISCV) that do not have a
+ * direct assembly implementation of the relevant builtin functions that zstd
+ * references, the compiler converts them into call

Re: svn commit: r327763 - in head/sys: conf contrib/zstd/lib/freebsd

[Ravi Pokala]

Ah, it looks like r327776 fixed this. Thanks John!

-Ravi (rpokala@)


-Original Message-
From:  on behalf of Ravi Pokala 

Date: 2018-01-10, Wednesday at 08:51
To: Conrad Meyer , , 
, 
Subject: Re: svn commit: r327763 - in head/sys: conf contrib/zstd/lib/freebsd

Hi Conrad,

Alas, this still doesn't look right on RISC-V:

zstd_kfreebsd.o: In function `__ctzdi2':

/usr/home/rpokala/freebsd/clean/base/head/sys/contrib/zstd/lib/freebsd/zstd_kfreebsd.c:58:
 undefined reference to `ffsll'

I got substantively the same error both before and after `pkg upgrade' brought 
in updated RISC-V stuff:

riscv64-binutils (2.29.51.20170726 -> 2.29_20180105,1)
riscv64-gcc (7.1.1 -> 7.2.0)

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Conrad Meyer 

Date: 2018-01-09, Tuesday at 22:30
To: , , 

Subject: svn commit: r327763 - in head/sys: conf contrib/zstd/lib/freebsd

Author: cem
Date: Wed Jan 10 06:30:59 2018
New Revision: 327763
URL: https://svnweb.freebsd.org/changeset/base/327763

Log:
  Finally, fix Zstd kernel build on MIPS and RISC-V
  
  Add an implementation of the intrinsics invoked by __builtin_ctz{,ll} and
  __builtin_clz{,ll}, and include this compilation unit on platforms that lack
  assembly intrinsics for those builtins (MIPS and RISC-V).
  
  Future cleanup work might involve bringing these into a mini libcompiler-rt
  for the standalone kernel environment.  Or cleaning up the approach upstream
  takes for builtins in standalone environments (or just FreeBSD).  For now,
  at least this builds, and doesn't require modifying the vendor code.
  
  Reported by:  jeff, markj, mizhka
  Reviewed by:  jhb (earlier version), rpokala (comment text earlier version)
  Sponsored by: Dell EMC Isilon

Added:
  head/sys/contrib/zstd/lib/freebsd/zstd_kfreebsd.c   (contents, props changed)
Modified:
  head/sys/conf/files.mips
  head/sys/conf/files.riscv

Modified: head/sys/conf/files.mips
==
--- head/sys/conf/files.mipsWed Jan 10 05:52:24 2018(r327762)
+++ head/sys/conf/files.mipsWed Jan 10 06:30:59 2018(r327763)
@@ -112,3 +112,6 @@ cddl/compat/opensolaris/kern/opensolaris_atomic.c   opti
 cddl/dev/dtrace/mips/dtrace_asm.S  optional dtrace 
compile-with "${DTRACE_S}"
 cddl/dev/dtrace/mips/dtrace_subr.c optional dtrace 
compile-with "${DTRACE_C}"
 cddl/dev/fbt/mips/fbt_isa.coptional dtrace_fbt | 
dtraceall compile-with "${FBT_C}"
+
+# Zstd
+contrib/zstd/lib/freebsd/zstd_kfreebsd.c   standard compile-with 
${ZSTD_C}

Modified: head/sys/conf/files.riscv
==
--- head/sys/conf/files.riscv   Wed Jan 10 05:52:24 2018(r327762)
+++ head/sys/conf/files.riscv   Wed Jan 10 06:30:59 2018(r327763)
@@ -56,3 +56,6 @@ riscv/riscv/uio_machdep.c standard
 riscv/riscv/uma_machdep.c  standard
 riscv/riscv/unwind.c   optionalddb | kdtrace_hooks | stack
 riscv/riscv/vm_machdep.c   standard
+
+# Zstd
+contrib/zstd/lib/freebsd/zstd_kfreebsd.c   standard compile-with 
${ZSTD_C}

Added: head/sys/contrib/zstd/lib/freebsd/zstd_kfreebsd.c
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/sys/contrib/zstd/lib/freebsd/zstd_kfreebsd.c   Wed Jan 10 06:30:59 
2018(r327763)
@@ -0,0 +1,75 @@
+/*-
+ * Copyright (c) 2018 Conrad Meyer 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY 

Re: svn commit: r327763 - in head/sys: conf contrib/zstd/lib/freebsd

[Ravi Pokala]

Yup, that did the trick. Thank you sir!

-Ravi (rpokala@)

-Original Message-
From:  on behalf of John Baldwin 

Date: 2018-01-10, Wednesday at 09:37
To: Ravi Pokala 
Cc: Conrad Meyer , , 
, 
Subject: Re: svn commit: r327763 - in head/sys: conf contrib/zstd/lib/freebsd

On Wednesday, January 10, 2018 08:51:27 AM Ravi Pokala wrote:
> Hi Conrad,
> 
> Alas, this still doesn't look right on RISC-V:
> 
> zstd_kfreebsd.o: In function `__ctzdi2':
> 
> /usr/home/rpokala/freebsd/clean/base/head/sys/contrib/zstd/lib/freebsd/zstd_kfreebsd.c:58:
>  undefined reference to `ffsll'
> 
> I got substantively the same error both before and after `pkg upgrade' 
> brought in updated RISC-V stuff:
> 
> riscv64-binutils (2.29.51.20170726 -> 2.29_20180105,1)
> riscv64-gcc (7.1.1 -> 7.2.0)
> 
> Thanks,

Try r327776.

-- 
John Baldwin




___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r328020 - in head/sys/mips: mips nlm/dev/sec

[Ravi Pokala]

Hi Pedro,

This change breaks many (most? all?) MIPS kernels (universe, no special config, 
-DNO_CLEAN):

--- busdma_machdep.o ---
cc1: warnings being treated as errors
/usr/home/rpokala/freebsd/clean/base/head/sys/mips/mips/busdma_machdep.c: In 
function 'bus_dmamap_create':
/usr/home/rpokala/freebsd/clean/base/head/sys/mips/mips/busdma_machdep.c:539: 
warning: passing argument 2 of 'malloc' makes pointer from integer without a 
cast
/usr/home/rpokala/freebsd/clean/base/head/sys/mips/mips/busdma_machdep.c:539: 
warning: passing argument 3 of 'malloc' makes integer from pointer without a 
cast
/usr/home/rpokala/freebsd/clean/base/head/sys/mips/mips/busdma_machdep.c:539: 
error: too many arguments to function 'malloc'
/usr/home/rpokala/freebsd/clean/base/head/sys/mips/mips/busdma_machdep.c: In 
function 'bus_dmamem_alloc':
/usr/home/rpokala/freebsd/clean/base/head/sys/mips/mips/busdma_machdep.c:651: 
warning: passing argument 2 of 'malloc' makes pointer from integer without a 
cast
/usr/home/rpokala/freebsd/clean/base/head/sys/mips/mips/busdma_machdep.c:651: 
warning: passing argument 3 of 'malloc' makes integer from pointer without a 
cast
/usr/home/rpokala/freebsd/clean/base/head/sys/mips/mips/busdma_machdep.c:651: 
error: too many arguments to function 'malloc'

Thanks,

Ravi (rpokala@)


-Original Message-
From:  on behalf of "Pedro F. Giffuni" 

Date: 2018-01-15, Monday at 13:13
To: , , 

Subject: svn commit: r328020 - in head/sys/mips: mips nlm/dev/sec

Author: pfg
Date: Mon Jan 15 21:13:30 2018
New Revision: 328020
URL: https://svnweb.freebsd.org/changeset/base/328020

Log:
  mips: make some use of mallocarray(9).
  
  Focus on code where we are doing multiplications within malloc(9). None of
  these ire likely to overflow, however the change is still useful as some
  static checkers can benefit from the allocation attributes we use for
  mallocarray.
  
  This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
  reason but I started doing the changes before r327796 and at that time it
  was convenient to make sure the sorrounding code could handle NULL values.
  
  X-Differential revision: https://reviews.freebsd.org/D13837

Modified:
  head/sys/mips/mips/busdma_machdep.c
  head/sys/mips/nlm/dev/sec/nlmrsa.c

Modified: head/sys/mips/mips/busdma_machdep.c
==
--- head/sys/mips/mips/busdma_machdep.c Mon Jan 15 21:11:38 2018
(r328019)
+++ head/sys/mips/mips/busdma_machdep.c Mon Jan 15 21:13:30 2018
(r328020)
@@ -345,7 +345,8 @@ _busdma_alloc_dmamap(bus_dma_tag_t dmat)
struct sync_list *slist;
bus_dmamap_t map;
 
-   slist = malloc(sizeof(*slist) * dmat->nsegments, M_BUSDMA, M_NOWAIT);
+   slist = mallocarray(dmat->nsegments, sizeof(*slist), M_BUSDMA,
+   M_NOWAIT);
if (slist == NULL)
return (NULL);
map = uma_zalloc_arg(dmamap_zone, dmat, M_NOWAIT);
@@ -534,9 +535,8 @@ bus_dmamap_create(bus_dma_tag_t dmat, int flags, bus_d
int error = 0;
 
if (dmat->segments == NULL) {
-   dmat->segments = (bus_dma_segment_t *)malloc(
-   sizeof(bus_dma_segment_t) * dmat->nsegments, M_BUSDMA,
-   M_NOWAIT);
+   dmat->segments = (bus_dma_segment_t *)malloc(dmat->nsegments,
+   sizeof(bus_dma_segment_t), M_BUSDMA, M_NOWAIT);
if (dmat->segments == NULL) {
CTR3(KTR_BUSDMA, "%s: tag %p error %d",
__func__, dmat, ENOMEM);
@@ -647,9 +647,8 @@ bus_dmamem_alloc(bus_dma_tag_t dmat, void** vaddrp, in
else
mflags = M_WAITOK;
if (dmat->segments == NULL) {
-   dmat->segments = (bus_dma_segment_t *)malloc(
-   sizeof(bus_dma_segment_t) * dmat->nsegments, M_BUSDMA,
-   mflags);
+   dmat->segments = (bus_dma_segment_t *)malloc(dmat->nsegments,
+   sizeof(bus_dma_segment_t), M_BUSDMA, mflags);
if (dmat->segments == NULL) {
CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x error %d",
__func__, dmat, dmat->flags, ENOMEM);

Modified: head/sys/mips/nlm/dev/sec/nlmrsa.c
==
--- head/sys/mips/nlm/dev/sec/nlmrsa.c  Mon Jan 15 21:11:38 2018
(r328019)
+++ head/sys/mips/nlm/dev/sec/nlmrsa.c  Mon Jan 15 21:13:30 2018
(r328020)
@@ -346,7 +346,7 @@ xlp_rsa_newsession(device_t dev, u_int32_t *sidp, stru
 
if (ses == NULL) {
sesn = sc->sc_nsessions;
-   ses = malloc((sesn + 1) * sizeof(*ses),
+   ses = mallocarray(sesn + 1, sizeof(*ses),
M_DEVBUF, M_NOWAIT);
if (ses == NULL)
return (ENOMEM);
@@ -528,8 +528,9 @@ x

Re: svn commit: r328020 - in head/sys/mips: mips nlm/dev/sec

[Ravi Pokala]

Thanks!

-Ravi (rpokala@)

-Original Message-
From:  on behalf of Pedro Giffuni 

Date: 2018-01-15, Monday at 22:06
To: Ravi Pokala , , 
, 
Subject: Re: svn commit: r328020 - in head/sys/mips: mips nlm/dev/sec

Thanks for the report;


On 01/16/18 00:23, Ravi Pokala wrote:
> Hi Pedro,
>
> This change breaks many (most? all?) MIPS kernels (universe, no special 
> config, -DNO_CLEAN):
Ugh, yes .. the build was broken by another change so I didn't notice  
this in my builds.

Sorry .. should be fixed as r328041.

Pedro.
> --- busdma_machdep.o ---
> cc1: warnings being treated as errors
> /usr/home/rpokala/freebsd/clean/base/head/sys/mips/mips/busdma_machdep.c: In 
> function 'bus_dmamap_create':
> /usr/home/rpokala/freebsd/clean/base/head/sys/mips/mips/busdma_machdep.c:539: 
> warning: passing argument 2 of 'malloc' makes pointer from integer without a 
> cast
> /usr/home/rpokala/freebsd/clean/base/head/sys/mips/mips/busdma_machdep.c:539: 
> warning: passing argument 3 of 'malloc' makes integer from pointer without a 
> cast
> /usr/home/rpokala/freebsd/clean/base/head/sys/mips/mips/busdma_machdep.c:539: 
> error: too many arguments to function 'malloc'
> /usr/home/rpokala/freebsd/clean/base/head/sys/mips/mips/busdma_machdep.c: In 
> function 'bus_dmamem_alloc':
> /usr/home/rpokala/freebsd/clean/base/head/sys/mips/mips/busdma_machdep.c:651: 
> warning: passing argument 2 of 'malloc' makes pointer from integer without a 
> cast
> /usr/home/rpokala/freebsd/clean/base/head/sys/mips/mips/busdma_machdep.c:651: 
> warning: passing argument 3 of 'malloc' makes integer from pointer without a 
> cast
> /usr/home/rpokala/freebsd/clean/base/head/sys/mips/mips/busdma_machdep.c:651: 
> error: too many arguments to function 'malloc'
>
> Thanks,
>
> Ravi (rpokala@)
>
>
> -Original Message-
> From:  on behalf of "Pedro F. Giffuni" 
> 
> Date: 2018-01-15, Monday at 13:13
> To: , , 
> 
> Subject: svn commit: r328020 - in head/sys/mips: mips nlm/dev/sec
>
> Author: pfg
> Date: Mon Jan 15 21:13:30 2018
> New Revision: 328020
> URL: https://svnweb.freebsd.org/changeset/base/328020
>
> Log:
>mips: make some use of mallocarray(9).
>
>Focus on code where we are doing multiplications within malloc(9). None of
>these ire likely to overflow, however the change is still useful as some
>static checkers can benefit from the allocation attributes we use for
>mallocarray.
>
>This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
>reason but I started doing the changes before r327796 and at that time it
>was convenient to make sure the sorrounding code could handle NULL values.
>
>X-Differential revision: https://reviews.freebsd.org/D13837
>
> Modified:
>head/sys/mips/mips/busdma_machdep.c
>head/sys/mips/nlm/dev/sec/nlmrsa.c
>
> Modified: head/sys/mips/mips/busdma_machdep.c
> ==
> --- head/sys/mips/mips/busdma_machdep.c   Mon Jan 15 21:11:38 2018
> (r328019)
> +++ head/sys/mips/mips/busdma_machdep.c   Mon Jan 15 21:13:30 2018
> (r328020)
> @@ -345,7 +345,8 @@ _busdma_alloc_dmamap(bus_dma_tag_t dmat)
>   struct sync_list *slist;
>   bus_dmamap_t map;
>   
> - slist = malloc(sizeof(*slist) * dmat->nsegments, M_BUSDMA, M_NOWAIT);
> + slist = mallocarray(dmat->nsegments, sizeof(*slist), M_BUSDMA,
> + M_NOWAIT);
>   if (slist == NULL)
>   return (NULL);
>   map = uma_zalloc_arg(dmamap_zone, dmat, M_NOWAIT);
> @@ -534,9 +535,8 @@ bus_dmamap_create(bus_dma_tag_t dmat, int flags, bus_d
>   int error = 0;
>   
>   if (dmat->segments == NULL) {
> - dmat->segments = (bus_dma_segment_t *)malloc(
> - sizeof(bus_dma_segment_t) * dmat->nsegments, M_BUSDMA,
> - M_NOWAIT);
> + dmat->segments = (bus_dma_segment_t *)malloc(dmat->nsegments,
> + sizeof(bus_dma_segment_t), M_BUSDMA, M_NOWAIT);
>   if (dmat->segments == NULL) {
>   CTR3(KTR_BUSDMA, "%s: tag %p error %d",
>   __func__, dmat, ENOMEM);
> @@ -647,9 +647,8 @@ bus_dmamem_alloc(bus_dma_tag_t dmat, void** vaddrp, in
>   else
>   mflags = M_WAITOK;
>   if (dmat->segments == NULL) {
> - dmat->segments = (bus_dma_segment_t *)malloc(
> - sizeof(bus_dma_segment_t) * dmat->nsegments, M_BUSDMA,
> - mflags);
> + dmat->segments = (bus_dma_segment_

Re: svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm modules

[Ravi Pokala]

>> I wonder if it would be too noisy if we allowed ->probe() to run on disabled 
>> devices and reported something like:
>> 
>>   "foobar0: Matched disabled device <...>"
>> 
>> (without calling ->attach())
>> 
>> That way you would know you loaded the right driver, rather than have to 
>> guess
> 
> I suspect that would be too noisy. It would be better to just run probe, but 
> then have newbus report it's disabled so we never go onto attach.

I think a "Matched disabled device" message under bootverbose would be 
reasonable.

-Ravi (rpokala@)

-Original Message-
From:  on behalf of Warner Losh 

Date: 2018-01-22, Monday at 11:29
To: Poul-Henning Kamp 
Cc: John Baldwin , Emmanuel Vadot , 
src-committers , , 

Subject: Re: svn commit: r328257 - in head/sys: arm/broadcom/bcm2835 dts/arm 
modules



On Mon, Jan 22, 2018 at 12:24 PM, Poul-Henning Kamp  wrote:


In message <52374125.ogxafgl...@ralph.baldwin.cx>, John Baldwin writes:

>Create the corresponding device_t but device_disable() it when there
>is a disabled property.

That also removes a couple of boilerplate lines from all FDT device
drivers.


That would be useful, but the status bit is so much more than on/off. 


>A user can then use 'devctl enable ' to enable
>it before (or even after) loading a device driver.

That would work for me.

I wonder if it would be too noisy if we allowed ->probe() to run
on disabled devices and reported something like:

"foobar0: Matched disabled device <...>"

(without calling ->attach())

That way you would know you loaded the right driver, rather
than have to guess.


I suspect that would be too noisy. It would be better to just run probe, but 
then have newbus report it's disabled so we never go onto attach.

Though, there's more fundamental issues at play since FDT is tricky and a lot 
more interrelated than other enumeration platforms.

Warner






___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r331345 - head/sys/dev/jedec_dimm

[Ravi Pokala]

Author: rpokala
Date: Thu Mar 22 06:31:05 2018
New Revision: 331345
URL: https://svnweb.freebsd.org/changeset/base/331345

Log:
  jedec_dimm: Use correct string length when populating sc->slotid_str
  
  Don't limit the copy to the size of the target string *pointer* (always
  4 on 32-bit / 8 on 64-bit). Instead, just use strdup().
  
  Reported by:  Coverity
  CID:  1386912
  Reviewed by:  cem, imp
  MFC after:1 week

Modified:
  head/sys/dev/jedec_dimm/jedec_dimm.c

Modified: head/sys/dev/jedec_dimm/jedec_dimm.c
==
--- head/sys/dev/jedec_dimm/jedec_dimm.cThu Mar 22 05:26:27 2018
(r331344)
+++ head/sys/dev/jedec_dimm/jedec_dimm.cThu Mar 22 06:31:05 2018
(r331345)
@@ -341,10 +341,7 @@ jedec_dimm_attach(device_t dev)
if (resource_string_value(device_get_name(dev), device_get_unit(dev),
"slotid", &slotid_str) == 0) {
if (slotid_str != NULL) {
-   sc->slotid_str = malloc(strlen(slotid_str) + 1,
-   M_DEVBUF, (M_WAITOK | M_ZERO));
-   strlcpy(sc->slotid_str, slotid_str,
-   sizeof(sc->slotid_str));
+   sc->slotid_str = strdup(slotid_str, M_DEVBUF);
SYSCTL_ADD_STRING(ctx, children, OID_AUTO, "slotid",
CTLFLAG_RD | CTLFLAG_MPSAFE, sc->slotid_str, 0,
"DIMM Slot Identifier");
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r318688 - head/sys/sys

[Ravi Pokala]

Author: rpokala
Date: Mon May 22 23:31:28 2017
New Revision: 318688
URL: https://svnweb.freebsd.org/changeset/base/318688

Log:
  "struct ata_params" field "reserved206[2]" actually starts at offset 20*7*.
  
  MFC after:1 week
  Sponsored by: Panasas

Modified:
  head/sys/sys/ata.h

Modified: head/sys/sys/ata.h
==
--- head/sys/sys/ata.h  Mon May 22 23:21:24 2017(r318687)
+++ head/sys/sys/ata.h  Mon May 22 23:31:28 2017(r318688)
@@ -263,7 +263,7 @@ struct ata_params {
u_int16_t   reserved170[6];
 /*176*/ u_int8_tmedia_serial[60];
 /*206*/ u_int16_t   sct;
-   u_int16_t   reserved206[2];
+   u_int16_t   reserved207[2];
 /*209*/ u_int16_t   lsalign;
 /*210*/ u_int16_t   wrv_sectors_m3_1;
u_int16_t   wrv_sectors_m3_2;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm

[Ravi Pokala]

-Original Message-
> From:  on behalf of Ed Maste 
> 
> Date: 2017-05-23, Tuesday at 07:00
> To: Konstantin Belousov 
> Cc: "src-committ...@freebsd.org" , 
> "svn-src-...@freebsd.org" , 
> "svn-src-head@freebsd.org" 
> Subject: Re: svn commit: r318736 - in head: cddl/lib/libzfs 
> contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include 
> lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm 
> lib/libmi...
> 
> On 23 May 2017 at 05:29, Konstantin Belousov  wrote:
>> Author: kib
>> Date: Tue May 23 09:29:05 2017
>> New Revision: 318736
>> URL: https://svnweb.freebsd.org/changeset/base/318736
>>
>>   Update note: strictly follow the instructions in UPDATING.  Build
>>   and install the new kernel with COMPAT_FREEBSD11 option enabled,
>>   then reboot, and only then install new world.
> 
> There's been some confusion over this point, so let me clarify: this
> note refers to the regular upgrade procedure documented in UPDATING
> under the heading "To rebuild everything and install it on the current
> system". Following the regular, documented procedure is both necessary
> and sufficient for the ino64 change.
> 
> It's mentioned explicitly here because folks often take shortcuts with
> updating (e.g. not rebooting), and such a shortcut will fail with the
>ino64 change.

So then `tools/build/beinstall.sh' won't DTRT for this upgrade?

-Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r318736 - in head: cddl/lib/libzfs contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm lib/libm

[Ravi Pokala]

-Original Message-
> From:  on behalf of Ed Maste 
> 
> Date: 2017-05-23, Tuesday at 07:16
> To: Ravi Pokala 
> Cc: Konstantin Belousov , "src-committ...@freebsd.org" 
> , "svn-src-...@freebsd.org" 
> , "svn-src-head@freebsd.org" 
> 
> Subject: Re: svn commit: r318736 - in head: cddl/lib/libzfs 
> contrib/compiler-rt/lib/sanitizer_common contrib/openbsm/libbsm include 
> lib/libarchive lib/libc/gen lib/libc/include lib/libc/sys lib/libkvm 
> lib/libmi...
> 
> On 23 May 2017 at 10:10, Ravi Pokala  wrote:
>>
>> So then `tools/build/beinstall.sh' won't DTRT for this upgrade?
> 
> This should be fine, because the new kernel and world get installed
> into a new boot environment, not over top of the existing system. The
> problem only occurs when installing a new userland while the older
> kernel is still running.

That's right, I'd forgotten how `beinstall.sh' did it's magic. Thanks for 
clarifying.

-Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r319664 - in head: . contrib/groff etc etc/mtree gnu/usr.bin gnu/usr.bin/groff release share share/me share/mk tools/build/mk tools/build/options usr.bin usr.bin/checknr usr.bin/colcrt

[Ravi Pokala]

Hi Bapt,

Please note that this causes `make clean' to complain about usr.bin/chknr and 
usr.bin/colcrt not existing:

===> usr.bin/checknr (clean)
cd: /usr/home/rpokala/freebsd/clean/base/head/usr.bin/checknr: No such file or 
directory
*** [clean_subdir_usr.bin/checknr] Error code 2

===> usr.bin/colcrt (clean)
cd: /usr/home/rpokala/freebsd/clean/base/head/usr.bin/colcrt: No such file or 
directory
*** [clean_subdir_usr.bin/colcrt] Error code 2


Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Baptiste Daroussin 

Date: 2017-06-07, Wednesday at 16:00
To: , , 

Subject: svn commit: r319664 - in head: . contrib/groff etc etc/mtree 
gnu/usr.bin gnu/usr.bin/groff release share share/me share/mk tools/build/mk 
tools/build/options usr.bin usr.bin/checknr usr.bin/colcrt

Author: bapt
Date: Wed Jun  7 23:00:34 2017
New Revision: 319664
URL: https://svnweb.freebsd.org/changeset/base/319664

Log:
  Remove groff from base
  
  All manpages in base are now compatible with mandoc(1), all roff documentation
  will be relocated in the doc tree. man(1) can now use groff from the ports 
tree
  if it needs.
  
  Also remove checknr(1) and colcrt(1) which are only useful with groff.
  
  Approved by:  (no objections on the mailing lists)

Deleted:
  head/contrib/groff/
  head/etc/mtree/BSD.groff.dist
  head/gnu/usr.bin/groff/
  head/share/me/
  head/tools/build/options/WITHOUT_GROFF
  head/usr.bin/checknr/
  head/usr.bin/colcrt/
Modified:
  head/ObsoleteFiles.inc
  head/UPDATING
  head/etc/Makefile
  head/etc/mtree/Makefile
  head/gnu/usr.bin/Makefile
  head/release/Makefile
  head/share/Makefile
  head/share/mk/src.opts.mk
  head/tools/build/mk/OptionalObsoleteFiles.inc
  head/usr.bin/Makefile

Modified: head/ObsoleteFiles.inc
==
--- head/ObsoleteFiles.inc  Wed Jun  7 21:21:14 2017(r319663)
+++ head/ObsoleteFiles.inc  Wed Jun  7 23:00:34 2017(r319664)
@@ -38,6 +38,488 @@
 #   xargs -n1 | sort | uniq -d;
 # done
 
+# 20170531: removal of groff
+OLD_FILES+=usr/bin/addftinfo
+OLD_FILES+=usr/bin/afmtodit
+OLD_FILES+=usr/bin/checknr
+OLD_FILES+=usr/bin/colcrt
+OLD_FILES+=usr/bin/eqn
+OLD_FILES+=usr/bin/grn
+OLD_FILES+=usr/bin/grodvi
+OLD_FILES+=usr/bin/groff
+OLD_FILES+=usr/bin/grog
+OLD_FILES+=usr/bin/grolbp
+OLD_FILES+=usr/bin/grolj4
+OLD_FILES+=usr/bin/grops
+OLD_FILES+=usr/bin/grotty
+OLD_FILES+=usr/bin/hpftodit
+OLD_FILES+=usr/bin/indxbib
+OLD_FILES+=usr/bin/lkbib
+OLD_FILES+=usr/bin/lookbib
+OLD_FILES+=usr/bin/mmroff
+OLD_FILES+=usr/bin/neqn
+OLD_FILES+=usr/bin/nroff
+OLD_FILES+=usr/bin/pfbtops
+OLD_FILES+=usr/bin/pic
+OLD_FILES+=usr/bin/post-grohtml
+OLD_FILES+=usr/bin/pre-grohtml
+OLD_FILES+=usr/bin/psroff
+OLD_FILES+=usr/bin/refer
+OLD_FILES+=usr/bin/tbl
+OLD_FILES+=usr/bin/tfmtodit
+OLD_FILES+=usr/bin/troff
+OLD_FILES+=usr/bin/vgrind
+OLD_FILES+=usr/libexec/vfontedpr
+OLD_FILES+=usr/share/dict/eign
+OLD_FILES+=usr/share/groff_font/devX100-12/CB
+OLD_FILES+=usr/share/groff_font/devX100-12/CBI
+OLD_FILES+=usr/share/groff_font/devX100-12/CI
+OLD_FILES+=usr/share/groff_font/devX100-12/CR
+OLD_FILES+=usr/share/groff_font/devX100-12/DESC
+OLD_FILES+=usr/share/groff_font/devX100-12/HB
+OLD_FILES+=usr/share/groff_font/devX100-12/HBI
+OLD_FILES+=usr/share/groff_font/devX100-12/HI
+OLD_FILES+=usr/share/groff_font/devX100-12/HR
+OLD_FILES+=usr/share/groff_font/devX100-12/NB
+OLD_FILES+=usr/share/groff_font/devX100-12/NBI
+OLD_FILES+=usr/share/groff_font/devX100-12/NI
+OLD_FILES+=usr/share/groff_font/devX100-12/NR
+OLD_FILES+=usr/share/groff_font/devX100-12/S
+OLD_FILES+=usr/share/groff_font/devX100-12/TB
+OLD_FILES+=usr/share/groff_font/devX100-12/TBI
+OLD_FILES+=usr/share/groff_font/devX100-12/TI
+OLD_FILES+=usr/share/groff_font/devX100-12/TR
+OLD_DIRS+=usr/share/groff_font/devX100-12
+OLD_FILES+=usr/share/groff_font/devX100/CB
+OLD_FILES+=usr/share/groff_font/devX100/CBI
+OLD_FILES+=usr/share/groff_font/devX100/CI
+OLD_FILES+=usr/share/groff_font/devX100/CR
+OLD_FILES+=usr/share/groff_font/devX100/DESC
+OLD_FILES+=usr/share/groff_font/devX100/HB
+OLD_FILES+=usr/share/groff_font/devX100/HBI
+OLD_FILES+=usr/share/groff_font/devX100/HI
+OLD_FILES+=usr/share/groff_font/devX100/HR
+OLD_FILES+=usr/share/groff_font/devX100/NB
+OLD_FILES+=usr/share/groff_font/devX100/NBI
+OLD_FILES+=usr/share/groff_font/devX100/NI
+OLD_FILES+=usr/share/groff_font/devX100/NR
+OLD_FILES+=usr/share/groff_font/devX100/S
+OLD_FILES+=usr/share/groff_font/devX100/TB
+OLD_FILES+=usr/share/groff_font/devX100/TBI
+OLD_FILES+=usr/share/groff_font/devX100/TI
+OLD_FILES+=usr/share/groff_font/devX100/TR
+OLD_DIRS+=usr/share/groff_font/devX100
+OLD_FILES+=usr/share/groff_font/devX75-12/CB
+OLD_FILES+=usr/share/groff_font/devX75-12/CBI
+OLD_FILES+=usr/share/groff_font/devX75-12/CI
+OLD_FILES+=usr/share/groff_font/devX75-12/CR
+OLD_FILES+=usr/share/groff_font/devX75-12/DESC
+OLD_FILES+=usr/share/groff_font/devX75-12/HB
+OLD_FILES+=usr/share/gr

Re: svn commit: r319664 - in head: . contrib/groff etc etc/mtree gnu/usr.bin gnu/usr.bin/groff release share share/me share/mk tools/build/mk tools/build/options usr.bin usr.bin/checknr usr.bin/colcrt

[Ravi Pokala]

Weird, lag; I found Bapt on IRC and told him this, and he fixed it w/ r319666, 
and this email came through almost an hour later...

In any case, all good now.

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Ravi Pokala 

Date: 2017-06-07, Wednesday at 16:29
To: Baptiste Daroussin , , 
, 
Subject: Re: svn commit: r319664 - in head: . contrib/groff etc etc/mtree 
gnu/usr.bin gnu/usr.bin/groff release share share/me share/mk tools/build/mk 
tools/build/options usr.bin usr.bin/checknr usr.bin/colcrt

Hi Bapt,

Please note that this causes `make clean' to complain about usr.bin/chknr and 
usr.bin/colcrt not existing:

===> usr.bin/checknr (clean)
cd: /usr/home/rpokala/freebsd/clean/base/head/usr.bin/checknr: No such file or 
directory
*** [clean_subdir_usr.bin/checknr] Error code 2

===> usr.bin/colcrt (clean)
cd: /usr/home/rpokala/freebsd/clean/base/head/usr.bin/colcrt: No such file or 
directory
*** [clean_subdir_usr.bin/colcrt] Error code 2


Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Baptiste Daroussin 

Date: 2017-06-07, Wednesday at 16:00
To: , , 

Subject: svn commit: r319664 - in head: . contrib/groff etc etc/mtree 
gnu/usr.bin gnu/usr.bin/groff release share share/me share/mk tools/build/mk 
tools/build/options usr.bin usr.bin/checknr usr.bin/colcrt

Author: bapt
Date: Wed Jun  7 23:00:34 2017
New Revision: 319664
URL: https://svnweb.freebsd.org/changeset/base/319664

Log:
  Remove groff from base
  
  All manpages in base are now compatible with mandoc(1), all roff documentation
  will be relocated in the doc tree. man(1) can now use groff from the ports 
tree
  if it needs.
  
  Also remove checknr(1) and colcrt(1) which are only useful with groff.
  
  Approved by:  (no objections on the mailing lists)

Deleted:
  head/contrib/groff/
  head/etc/mtree/BSD.groff.dist
  head/gnu/usr.bin/groff/
  head/share/me/
  head/tools/build/options/WITHOUT_GROFF
  head/usr.bin/checknr/
  head/usr.bin/colcrt/
Modified:
  head/ObsoleteFiles.inc
  head/UPDATING
  head/etc/Makefile
  head/etc/mtree/Makefile
  head/gnu/usr.bin/Makefile
  head/release/Makefile
  head/share/Makefile
  head/share/mk/src.opts.mk
  head/tools/build/mk/OptionalObsoleteFiles.inc
  head/usr.bin/Makefile

Modified: head/ObsoleteFiles.inc
==
--- head/ObsoleteFiles.inc  Wed Jun  7 21:21:14 2017(r319663)
+++ head/ObsoleteFiles.inc  Wed Jun  7 23:00:34 2017(r319664)
@@ -38,6 +38,488 @@
 #   xargs -n1 | sort | uniq -d;
 # done
 
+# 20170531: removal of groff
+OLD_FILES+=usr/bin/addftinfo
+OLD_FILES+=usr/bin/afmtodit
+OLD_FILES+=usr/bin/checknr
+OLD_FILES+=usr/bin/colcrt
+OLD_FILES+=usr/bin/eqn
+OLD_FILES+=usr/bin/grn
+OLD_FILES+=usr/bin/grodvi
+OLD_FILES+=usr/bin/groff
+OLD_FILES+=usr/bin/grog
+OLD_FILES+=usr/bin/grolbp
+OLD_FILES+=usr/bin/grolj4
+OLD_FILES+=usr/bin/grops
+OLD_FILES+=usr/bin/grotty
+OLD_FILES+=usr/bin/hpftodit
+OLD_FILES+=usr/bin/indxbib
+OLD_FILES+=usr/bin/lkbib
+OLD_FILES+=usr/bin/lookbib
+OLD_FILES+=usr/bin/mmroff
+OLD_FILES+=usr/bin/neqn
+OLD_FILES+=usr/bin/nroff
+OLD_FILES+=usr/bin/pfbtops
+OLD_FILES+=usr/bin/pic
+OLD_FILES+=usr/bin/post-grohtml
+OLD_FILES+=usr/bin/pre-grohtml
+OLD_FILES+=usr/bin/psroff
+OLD_FILES+=usr/bin/refer
+OLD_FILES+=usr/bin/tbl
+OLD_FILES+=usr/bin/tfmtodit
+OLD_FILES+=usr/bin/troff
+OLD_FILES+=usr/bin/vgrind
+OLD_FILES+=usr/libexec/vfontedpr
+OLD_FILES+=usr/share/dict/eign
+OLD_FILES+=usr/share/groff_font/devX100-12/CB
+OLD_FILES+=usr/share/groff_font/devX100-12/CBI
+OLD_FILES+=usr/share/groff_font/devX100-12/CI
+OLD_FILES+=usr/share/groff_font/devX100-12/CR
+OLD_FILES+=usr/share/groff_font/devX100-12/DESC
+OLD_FILES+=usr/share/groff_font/devX100-12/HB
+OLD_FILES+=usr/share/groff_font/devX100-12/HBI
+OLD_FILES+=usr/share/groff_font/devX100-12/HI
+OLD_FILES+=usr/share/groff_font/devX100-12/HR
+OLD_FILES+=usr/share/groff_font/devX100-12/NB
+OLD_FILES+=usr/share/groff_font/devX100-12/NBI
+OLD_FILES+=usr/share/groff_font/devX100-12/NI
+OLD_FILES+=usr/share/groff_font/devX100-12/NR
+OLD_FILES+=usr/share/groff_font/devX100-12/S
+OLD_FILES+=usr/share/groff_font/devX100-12/TB
+OLD_FILES+=usr/share/groff_font/devX100-12/TBI
+OLD_FILES+=usr/share/groff_font/devX100-12/TI
+OLD_FILES+=usr/share/groff_font/devX100-12/TR
+OLD_DIRS+=usr/share/groff_font/devX100-12
+OLD_FILES+=usr/share/groff_font/devX100/CB
+OLD_FILES+=usr/share/groff_font/devX100/CBI
+OLD_FILES+=usr/share/groff_font/devX100/CI
+OLD_FILES+=usr/share/groff_font/devX100/CR
+OLD_FILES+=usr/share/groff_font/devX100/DESC
+OLD_FILES+=usr/share/groff_font/devX100/HB
+OLD_FILES+=usr/share/groff_font/devX100/HBI
+OLD_FILES+=usr/share/groff_font/devX100/HI
+OLD_FILES+=usr/share/groff_font/devX100/HR
+OLD_FILES+=usr/share/groff_font/devX100/NB
+OLD_FILES+=usr/share/groff_font/devX100/NBI
+OLD_FILES+=usr/share/groff_font/devX100/NI
+OLD_FILES+=usr/share/groff_font/devX100/NR
+OLD_FILES+=usr/share

Re: svn commit: r320892 - head/etc/defaults

[Ravi Pokala]

I appreciate the spirit of this change; thanks Trasz!

A question though: you're telling the generic `fsck' to pass "-R" to either 
`fsck_ffs' or `fsck_ufs', as needed. But those are both names for the same 
executable. Won't the generic `fsck' always end up invoking (per 
sbin/fsck/fsck.c::ptype_map[]) `fsck_ffs'? In which case, is the `fsck_ufs' 
case needed here?

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Edward Tomasz Napierala 

Date: 2017-07-11, Tuesday at 05:32
To: , , 

Subject: svn commit: r320892 - head/etc/defaults

Author: trasz
Date: Tue Jul 11 12:32:40 2017
New Revision: 320892
URL: https://svnweb.freebsd.org/changeset/base/320892

Log:
  Make fsck_y_enable default to passing pass -R to fsck_ffs(8) in addition
  to -y.  To me, fsck_y_enable means "try as hard as possible", and without
  -R, it... well, doesn't.
  
  Reviewed by:  mckusick
  Obtained from:CheriBSD
  MFC after:2 weeks
  Sponsored by: DARPA, AFRL
  Differential Revision:https://reviews.freebsd.org/D11490

Modified:
  head/etc/defaults/rc.conf

Modified: head/etc/defaults/rc.conf
==
--- head/etc/defaults/rc.conf   Tue Jul 11 06:39:12 2017(r320891)
+++ head/etc/defaults/rc.conf   Tue Jul 11 12:32:40 2017(r320892)
@@ -92,7 +92,7 @@ geli_autodetach="YES" # Automatically detach on last c
 root_rw_mount="YES"# Set to NO to inhibit remounting root read-write.
 root_hold_delay="30"   # Time to wait for root mount hold release.
 fsck_y_enable="NO" # Set to YES to do fsck -y if the initial preen fails.
-fsck_y_flags=""# Additional flags for fsck -y
+fsck_y_flags="-T ffs:-R -T ufs:-R" # Additional flags for fsck -y
 background_fsck="YES"  # Attempt to run fsck in the background where possible.
 background_fsck_delay="60" # Time to wait (seconds) before starting the fsck.
 netfs_types="nfs:NFS smbfs:SMB" # Net filesystems.




___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r320892 - head/etc/defaults

[Ravi Pokala]

So the answer is "magic!" ;-)

Fair enough; I'll RTFSource if I'm still sufficiently curious tomorrow. :-)

Thanks again,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Edward Napierala 

Date: 2017-07-11, Tuesday at 11:46
To: Ravi Pokala 
Cc: "src-committ...@freebsd.org" , 
"svn-src-...@freebsd.org" , "svn-src-head@freebsd.org" 

Subject: Re: svn commit: r320892 - head/etc/defaults

Well, fsck(8) is a bit weird.
Assuming you don't have /dev/md0 in your fstab(5):

[trasz@v2:~]% fsck -d -t ffs -T ufs:-R /dev/md0
start (null) wait fsck_ffs /dev/md0
[trasz@v2:~]% fsck -d -t ufs -T ufs:-R /dev/md0

start (null) wait fsck_ufs -R /dev/md0

However (/ is defined as ufs in my fstab(5)):

[trasz@v2:~]% fsck -d -t ffs -T ufs:-R /   
start / wait fsck_ufs -R /dev/ada0s1a
[trasz@v2:~]% fsck -d -t ufs -T ufs:-R /
start / wait fsck_ufs -R /dev/ada0s1a




2017-07-11 16:21 GMT+01:00 Ravi Pokala :

I appreciate the spirit of this change; thanks Trasz!

A question though: you're telling the generic `fsck' to pass "-R" to either 
`fsck_ffs' or `fsck_ufs', as needed. But those are both names for the same 
executable. Won't the generic `fsck' always end up invoking (per 
sbin/fsck/fsck.c::ptype_map[]) `fsck_ffs'? In which case, is the `fsck_ufs' 
case needed here?

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Edward Tomasz Napierala 

Date: 2017-07-11, Tuesday at 05:32
To: , , 

Subject: svn commit: r320892 - head/etc/defaults

Author: trasz
Date: Tue Jul 11 12:32:40 2017
New Revision: 320892
URL: https://svnweb.freebsd.org/changeset/base/320892

Log:
  Make fsck_y_enable default to passing pass -R to fsck_ffs(8) in addition
  to -y.  To me, fsck_y_enable means "try as hard as possible", and without
  -R, it... well, doesn't.

  Reviewed by:  mckusick
  Obtained from:CheriBSD
  MFC after:2 weeks
  Sponsored by: DARPA, AFRL
  Differential Revision:https://reviews.freebsd.org/D11490

Modified:
  head/etc/defaults/rc.conf

Modified: head/etc/defaults/rc.conf
==
--- head/etc/defaults/rc.conf   Tue Jul 11 06:39:12 2017(r320891)
+++ head/etc/defaults/rc.conf   Tue Jul 11 12:32:40 2017(r320892)
@@ -92,7 +92,7 @@ geli_autodetach="YES" # Automatically detach on last c
 root_rw_mount="YES"# Set to NO to inhibit remounting root read-write.
 root_hold_delay="30"   # Time to wait for root mount hold release.
 fsck_y_enable="NO" # Set to YES to do fsck -y if the initial preen fails.
-fsck_y_flags=""# Additional flags for fsck -y
+fsck_y_flags="-T ffs:-R -T ufs:-R" # Additional flags for fsck -y
 background_fsck="YES"  # Attempt to run fsck in the background where possible.
 background_fsck_delay="60" # Time to wait (seconds) before starting the fsck.
 netfs_types="nfs:NFS smbfs:SMB" # Net filesystems.













___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r309124 - in head: . contrib/compiler-rt contrib/compiler-rt/include/sanitizer contrib/compiler-rt/lib/asan contrib/compiler-rt/lib/builtins contrib/compiler-rt/lib/builtins/arm contri

[Ravi Pokala]

This is huge, and a long time coming! Thanks all!

-Ravi (rpokala@)

-Original Message-
> From:  on behalf of Dimitry Andric 
> 
> Date: 2016-11-24, Thursday at 14:54
> To: , , 
> 
> Subject: svn commit: r309124 - in head: . contrib/compiler-rt 
> contrib/compiler-rt/include/sanitizer contrib/compiler-rt/lib/asan 
> contrib/compiler-rt/lib/builtins contrib/compiler-rt/lib/builtins/arm 
> contrib...
> 
> Author: dim
> Date: Thu Nov 24 22:54:55 2016
> New Revision: 309124
> URL: https://svnweb.freebsd.org/changeset/base/309124
> 
> Log:
>   Upgrade our copies of clang, llvm, lldb, compiler-rt and libc++ to 3.9.0
>   release, and add lld 3.9.0.  Also completely revamp the build system for
>   clang, llvm, lldb and their related tools.
>   
>   Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11
>   support to build; see UPDATING for more information.
>   
>   Release notes for llvm, clang and lld are available here:
>   
>   
>   
>   
>   Thanks to Ed Maste, Bryan Drewery, Andrew Turner, Antoine Brodin and Jan
>   Beich for their help.
>   
>   Relnotes:   yes
>   MFC after:  1 month



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r309374 - in head: sbin/camcontrol sys/cam/scsi

[Ravi Pokala]

-Original Message-
> From:  on behalf of Kyle Evans 
> 
> Date: 2016-12-02, Friday at 20:44
> To: "Kenneth D. Merry" 
> Cc: , , 
> 
> Subject: Re: svn commit: r309374 - in head: sbin/camcontrol sys/cam/scsi
> 
>> [...]
>> +
>> +   if (action == TIMESTAMP_REPORT) {
>> +   error = report_timestamp(device, &ts, retry_count,
>> +   timeout);
>> +   if (error != 0) {
>> +   goto bailout;
>> +   } else if (strcmp(format_string, MIL) == 0) {
>> +   printf("Timestamp in milliseconds: %ju\n",
>> +   (uintmax_t)ts);
>> +   } else {
>> +   char temp_timestamp_string[100];
>> +   time_t time_var = ts / 1000;
> 
> Hi,
> 
> FWIW: Building -CURRENT on mips.mips (w/ freebsd-wifi-build),
> mips-gcc gets upset at the above line with the following error:
> 
> /wifi-build/src/sbin/camcontrol/timestamp.c: In function 'timestamp':
> /wifi-build/src/sbin/camcontrol/timestamp.c:459:25: error: 'ts' may be
> used uninitialized in this function [-Werror=maybe-uninitialized]
> time_t time_var = ts / 1000;

Interesting. I just did a tinderbox build earlier this evening, and this wasn't 
reported.

> I understand that this is a bogus error because at this point it
> pretty much *has* to be set by the report_timestamp call just prior,
> but is there a clean way to trick GCC into agreeing, or is it just a
> matter of explicitly initializing it to 0 before the report_timestamp
> call?

Actually, it's a valid warning. While all paths to that point in timestamp() go 
through report_timestamp(), not all paths through report_timestamp() set *ts. 
Specifically, if cam_getccb() or cam_send_ccb() fail, or the request was not 
completed, report_timestamp() does 'goto bailout' without setting *ts.

I'm disappointed that `clang' (on i386 and amd64) didn't notice this; I was 
under the impression `clang' did more of that type of deep path analysis than 
`gcc'. 

-Ravi (rpokala@)

> Thanks,
> 
> Kyle Evans



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r309491 - in head/sys/modules: . bios

[Ravi Pokala]

Author: rpokala
Date: Sat Dec  3 17:54:08 2016
New Revision: 309491
URL: https://svnweb.freebsd.org/changeset/base/309491

Log:
  Build smbios.ko as a module for amd64 and i386
  
  For whatever reason, smapi, smbios, vpd are all under the "bios" directory.
  smapi is only for i386, so the entire "bios" directory is only built for
  i386. Break smapi out, and make only it i386-specific. Then, build the
  "bios" directory for both amd64 and i386.
  
  Reviewed by:  imp
  MFC after:1 week
  Sponsored by: Panasas
  Differential Revision:https://reviews.freebsd.org/D8609

Modified:
  head/sys/modules/Makefile
  head/sys/modules/bios/Makefile

Modified: head/sys/modules/Makefile
==
--- head/sys/modules/Makefile   Sat Dec  3 17:44:43 2016(r309490)
+++ head/sys/modules/Makefile   Sat Dec  3 17:54:08 2016(r309491)
@@ -550,6 +550,7 @@ _igb=   igb
 _agp=  agp
 _an=   an
 _aout= aout
+_bios= bios
 _bktr= bktr
 _bxe=  bxe
 _cardbus=  cardbus
@@ -730,7 +731,6 @@ _svr4=  svr4
 .if ${MK_EISA} != "no"
 _ahb=  ahb
 .endif
-_bios= bios
 _cm=   cm
 .if ${MK_SOURCELESS_UCODE} != "no"
 _ctau= ctau

Modified: head/sys/modules/bios/Makefile
==
--- head/sys/modules/bios/Makefile  Sat Dec  3 17:44:43 2016
(r309490)
+++ head/sys/modules/bios/Makefile  Sat Dec  3 17:54:08 2016
(r309491)
@@ -1,6 +1,10 @@
 # $FreeBSD$
 #
 
-SUBDIR=smapi smbios vpd
+SUBDIR=smbios vpd
+
+.if ${MACHINE_ARCH} == "i386"
+SUBDIR+=   smapi
+.endif
 
 .include 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r309625 - head/sbin/rcorder

[Ravi Pokala]

For grins, I ran this on my build server. The resulting graph is... complex. 
But one thing was immediately clear: neither /etc/rc.d/dhclient and 
/etc/rc.d/natd depend on anything. That seems wrong: I would expect them to 
have some sort of dependency on NETWORKING, either BEFORE (since dhclient may 
be involved in bringing up the network) or REQUIRE (since it doesn’t make sense 
to run a networking daemon like natd before networking is up).

Or am I missing something?

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Eric van Gyzen 

Date: 2016-12-06, Tuesday at 07:49
To: , , 

Subject: svn commit: r309625 - head/sbin/rcorder

Author: vangyzen
Date: Tue Dec  6 15:49:39 2016
New Revision: 309625
URL: https://svnweb.freebsd.org/changeset/base/309625

Log:
  Add rcorder-visualize.sh, which generates graphviz from rc.d scripts
  
  This is imported from NetBSD.  The author--Joerg Sonnenberger--agreed
  to apply a two-clause BSD license, just so the license was clear.
  
  This source tree location matches NetBSD, and is the first place someone
  might look for such a tool.
  
  Obtained from:Joerg Sonnenberger via NetBSD
  MFC after:3 days
  Sponsored by: Dell EMC

Added:
  head/sbin/rcorder/rcorder-visualize.sh   (contents, props changed)

Added: head/sbin/rcorder/rcorder-visualize.sh
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/sbin/rcorder/rcorder-visualize.sh  Tue Dec  6 15:49:39 2016
(r309625)
@@ -0,0 +1,52 @@
+#!/bin/sh
+# $NetBSD: rcorder-visualize.sh,v 1.5 2009/08/09 17:08:53 apb Exp $
+#
+# Copyright (c) 2009 by Joerg Sonnenberger
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#notice, this list of conditions and the following disclaimer in the
+#documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+# IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+# OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+# IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+# NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+# THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+#
+# $FreeBSD$
+#
+# Simple script to show the dependency graph for rc scripts.
+# Output is in the dot(1) language and can be rendered using
+#  sh rcorder-visualize | dot -T svg -o rcorder.svg
+# dot(1) can be found in graphics/graphviz in pkgsrc.
+
+rc_files=${*:-/etc/rc.d/*}
+
+{
+echo ' digraph {'
+for f in $rc_files; do
+< $f awk '
+/# PROVIDE: /  { provide = $3 }
+/# REQUIRE: /  { for (i = 3; i <= NF; i++) requires[$i] = $i }
+/# BEFORE: /   { for (i = 3; i <= NF; i++) befores[$i] = $i }
+
+END {
+   print "\"" provide "\";"
+   for (x in requires) print "\"" provide "\"->\"" x "\";"
+   for (x in befores) print "\"" x "\"->\"" provide "\";"
+}
+'
+done
+echo '}'
+}




___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r309625 - head/sbin/rcorder

[Ravi Pokala]

-Original Message-
> From: Ian Lepore 
> Date: 2016-12-06, Tuesday at 11:35
> To: Eric van Gyzen , Ravi Pokala , 
> , , 
> 
> Subject: Re: svn commit: r309625 - head/sbin/rcorder
> 
> On Tue, 2016-12-06 at 13:07 -0600, Eric van Gyzen wrote:
>> On 12/06/2016 11:30, Ravi Pokala wrote:
>>> 
>>> ...
>>> 
>> I saw that, too.  I'm pretty sure they're not called directly, but are
>> called from other scripts, such as network.subr and ipfw, respectively.
>> They certainly /look/ like they can be called directly.  Maybe that's
>> leftover from an older style of configuration?  I defer to the rc experts.
>> 
>> Eric
> 
> The clue for that is the "nostart" keyword -- scripts flagged with that
> won't be run automatically because /etc/rc does 'rcorder -s nostart',
> but they can be run by other scripts or from devd.
> 
> -- Ian

Ahhh! Good to know.

Thanks Ian,

Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r352925 - head/sys/dev/xen/control

[Ravi Pokala]

-Original Message-
From: Roger Pau Monné 
Date: 2019-10-02, Wednesday at 00:53
To: Ravi Pokala 
Cc: , , 

Subject: Re: svn commit: r352925 - head/sys/dev/xen/control

On Tue, Oct 01, 2019 at 06:42:14PM -0700, Ravi Pokala wrote:
> Hi Roger,
> 
> If I'm understanding this diff correctly, all of (poweroff, reboot, 
suspend) will use the common string "shutdown", rather than an event-specific 
string. Is that what we want?

I think there's some misunderstanding here. All power control events
use the same xenstore node (~/control/shutdown), but the command read
from it is different depending on the requested action (poweroff,
reboot, halt...).

Ah! Yes indeed, that was a misunderstanding on my part. I thought "shutdown" 
was the command text, rather than a component of the path containing the 
command.

See [0] for a slightly more detailed description of the xenstore node.

Note that this commit doesn't change any of this logic, it just clears
the contents of ~/control/shutdown (by writing "") so the toolstack
knows FreeBSD has acknowledged the request and it's processing it.

Yes, that all makes sense.

Thanks for clarifying!

-Ravi (rpokala@)

Roger.

[0] 
http://xenbits.xen.org/docs/4.12-testing/misc/xenstore-paths.html#platform-feature-and-control-paths



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r354102 - head/sys/sys

[Ravi Pokala]

Author: rpokala
Date: Fri Oct 25 21:32:28 2019
New Revision: 354102
URL: https://svnweb.freebsd.org/changeset/base/354102

Log:
  Args for buf_track() might be unused
  
  If neither FULL_BUF_TRACKING nor BUF_TRACKING are defined, then the body of
  buf_track() becomes empty. Mark the arguments with "__unused" so the
  compiler doesn't complain about unused arguments in that case.
  
  Reported by:  Bruce Leverett (Panasas)
  Reviewed by:  cem (on IRC)
  MFC after:1 month
  Sponsored by: Panasas

Modified:
  head/sys/sys/buf.h

Modified: head/sys/sys/buf.h
==
--- head/sys/sys/buf.h  Fri Oct 25 21:23:44 2019(r354101)
+++ head/sys/sys/buf.h  Fri Oct 25 21:32:28 2019(r354102)
@@ -457,7 +457,7 @@ buf_countdeps(struct buf *bp, int i)
 }
 
 static __inline void
-buf_track(struct buf *bp, const char *location)
+buf_track(struct buf *bp __unused, const char *location __unused)
 {
 
 #if defined(FULL_BUF_TRACKING)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r354283 - in head: stand/libsa/zfs sys/cddl/boot/zfs

[Ravi Pokala]

Uh

I've had a log device in my boot-pool for months, and have booted without issue:

[threepio:~] rpokala% zpool status zroot
  pool: zroot
 state: ONLINE
  scan: scrub repaired 0 in 0 days 00:04:36 with 0 errors on Mon Oct 28 
03:10:59 2019
config:

NAMESTATE READ WRITE CKSUM
zroot   ONLINE   0 0 0
  nvd1p4ONLINE   0 0 0
logs
  nvd0p1ONLINE   0 0 0

errors: No known data errors

-Ravi (rpokala@)

-Original Message-
From:  on behalf of Toomas Soome 

Date: 2019-11-03, Sunday at 05:25
To: , , 

Subject: svn commit: r354283 - in head: stand/libsa/zfs sys/cddl/boot/zfs

Author: tsoome
Date: Sun Nov  3 13:25:47 2019
New Revision: 354283
URL: https://svnweb.freebsd.org/changeset/base/354283

Log:
  loader: we do not support booting from pool with log device
  
  If pool has log device, stop there and tell about it.

Modified:
  head/stand/libsa/zfs/zfs.c
  head/stand/libsa/zfs/zfsimpl.c
  head/sys/cddl/boot/zfs/zfsimpl.h

Modified: head/stand/libsa/zfs/zfs.c

==
--- head/stand/libsa/zfs/zfs.c  Sun Nov  3 13:03:47 2019
(r354282)
+++ head/stand/libsa/zfs/zfs.c  Sun Nov  3 13:25:47 2019
(r354283)
@@ -668,6 +668,11 @@ zfs_dev_open(struct open_file *f, ...)
spa = spa_find_by_guid(dev->pool_guid);
if (!spa)
return (ENXIO);
+   if (spa->spa_with_log) {
+   printf("Reading pool %s is not supported due to log device.\n",
+   spa->spa_name);
+   return (ENXIO);
+   }
mount = malloc(sizeof(*mount));
if (mount == NULL)
return (ENOMEM);

Modified: head/stand/libsa/zfs/zfsimpl.c

==
--- head/stand/libsa/zfs/zfsimpl.c  Sun Nov  3 13:03:47 2019
(r354282)
+++ head/stand/libsa/zfs/zfsimpl.c  Sun Nov  3 13:25:47 2019
(r354283)
@@ -1109,6 +1109,7 @@ vdev_init_from_nvlist(const unsigned char *nvlist, vde
const unsigned char *kids;
int nkids, i, is_new;
uint64_t is_offline, is_faulted, is_degraded, is_removed, isnt_present;
+   uint64_t is_log;
 
if (nvlist_find(nvlist, ZPOOL_CONFIG_GUID, DATA_TYPE_UINT64,
NULL, &guid)
@@ -1132,17 +1133,20 @@ vdev_init_from_nvlist(const unsigned char *nvlist, 
vde
}
 
is_offline = is_removed = is_faulted = is_degraded = isnt_present = 0;
+   is_log = 0;
 
nvlist_find(nvlist, ZPOOL_CONFIG_OFFLINE, DATA_TYPE_UINT64, NULL,
-   &is_offline);
+   &is_offline);
nvlist_find(nvlist, ZPOOL_CONFIG_REMOVED, DATA_TYPE_UINT64, NULL,
-   &is_removed);
+   &is_removed);
nvlist_find(nvlist, ZPOOL_CONFIG_FAULTED, DATA_TYPE_UINT64, NULL,
-   &is_faulted);
+   &is_faulted);
nvlist_find(nvlist, ZPOOL_CONFIG_DEGRADED, DATA_TYPE_UINT64, NULL,
-   &is_degraded);
+   &is_degraded);
nvlist_find(nvlist, ZPOOL_CONFIG_NOT_PRESENT, DATA_TYPE_UINT64, NULL,
-   &isnt_present);
+   &isnt_present);
+   nvlist_find(nvlist, ZPOOL_CONFIG_IS_LOG, DATA_TYPE_UINT64, NULL,
+   &is_log);
 
vdev = vdev_find(guid);
if (!vdev) {
@@ -1217,6 +1221,7 @@ vdev_init_from_nvlist(const unsigned char *nvlist, vde
return (ENOMEM);
vdev->v_name = name;
}
+   vdev->v_islog = is_log == 1;
} else {
is_new = 0;
}
@@ -1433,6 +1438,12 @@ vdev_status(vdev_t *vdev, int indent)
 {
vdev_t *kid;
int ret;
+
+   if (vdev->v_islog) {
+   (void)pager_output("logs\n");
+   indent++;
+   }
+
ret = print_state(indent, vdev->v_name, vdev->v_state);
if (ret != 0)
return (ret);
@@ -1737,6 +1748,12 @@ vdev_probe(vdev_phys_read_t *_read, void *read_priv, 
s
printf("ZFS: inconsistent nvlist contents\n");
return (EIO);
}
+
+   /*
+* We do not support reading pools with log device.
+*/
+   if (vdev->v_islog)
+   spa->spa_with_log = vdev->v_islog;
 
/*
 * Re-evaluate top-level vdev state.

Modified: head/sys/cddl/boot/zfs/zfsimpl.h

==
--- head/sys/cddl/boot/zfs/zfsimpl.hSun Nov  3 13:03:47 2019
(r354282)
+++ head/sys/cddl/boot/zfs/zfsimpl.hSun Nov  3 13:25:47 2019
(r354283)
@@ -1670,6 +1670,7 @

svn commit: r354673 - head/stand/libsa

[Ravi Pokala]

Author: rpokala
Date: Wed Nov 13 03:56:51 2019
New Revision: 354673
URL: https://svnweb.freebsd.org/changeset/base/354673

Log:
  Logging improvements to loader::nfs
  
  Include the server IP address when logging nfs_open(), add a few missing
  "\n"s, and correct a typo.
  
  Reviewed by:  kevans
  MFC after:2 weeks
  Sponsored by: Panasas
  Differential Revision:https://reviews.freebsd.org/D22346

Modified:
  head/stand/libsa/nfs.c

Modified: head/stand/libsa/nfs.c
==
--- head/stand/libsa/nfs.c  Wed Nov 13 03:00:32 2019(r354672)
+++ head/stand/libsa/nfs.c  Wed Nov 13 03:56:51 2019(r354673)
@@ -486,7 +486,8 @@ nfs_open(const char *upath, struct open_file *f)
 
 #ifdef NFS_DEBUG
if (debug)
-   printf("nfs_open: %s (rootpath=%s)\n", upath, rootpath);
+   printf("nfs_open: %s (rootip=%s rootpath=%s)\n", upath,
+   inet_ntoa(rootip), rootpath);
 #endif
if (!rootpath[0]) {
printf("no rootpath, no nfs\n");
@@ -691,14 +692,14 @@ nfs_read(struct open_file *f, void *buf, size_t size, 
if (cc == -1) {
 #ifdef NFS_DEBUG
if (debug)
-   printf("nfs_read: read: %s", strerror(errno));
+   printf("nfs_read: read: %s\n", strerror(errno));
 #endif
return (errno); /* XXX - from nfs_readdata */
}
if (cc == 0) {
 #ifdef NFS_DEBUG
if (debug)
-   printf("nfs_read: hit EOF unexpectantly");
+   printf("nfs_read: hit EOF unexpectedly\n");
 #endif
goto ret;
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r354934 - head/sys/arm/conf

[Ravi Pokala]

-Original Message-
From:  on behalf of Ed Maste 

Date: 2019-11-20, Wednesday at 19:10
To: , , 

Subject: svn commit: r354934 - head/sys/arm/conf

Author: emaste
Date: Thu Nov 21 03:10:02 2019
New Revision: 354934
URL: https://svnweb.freebsd.org/changeset/base/354934

Log:
  mark arm.arm (v4/v5) kernels as NO_UNIVERSE for now
  
  r354290 removed arm.arm from universe, but arm.arm kernels were still
  found and built during the kernel stage.  I'm not aware of a better way
  to address this at the moment, but since there aren't many arm.arm
  kernels anyhow just add an explicit NO_UNIVERSE to them.
  
  Reported by:  rpokala

Thanks Ed!

-Ravi

Modified:
  head/sys/arm/conf/DB-78XXX
  head/sys/arm/conf/DB-88F5XXX
  head/sys/arm/conf/DB-88F6XXX
  head/sys/arm/conf/RT1310
  head/sys/arm/conf/TS7800

Modified: head/sys/arm/conf/DB-78XXX

==
--- head/sys/arm/conf/DB-78XXX  Thu Nov 21 02:49:41 2019
(r354933)
+++ head/sys/arm/conf/DB-78XXX  Thu Nov 21 03:10:02 2019
(r354934)
@@ -3,6 +3,7 @@
 #
 # $FreeBSD$
 #
+#NO_UNIVERSE
 
 ident  DB-88F78XX
 include"std.arm"

Modified: head/sys/arm/conf/DB-88F5XXX

==
--- head/sys/arm/conf/DB-88F5XXXThu Nov 21 02:49:41 2019
(r354933)
+++ head/sys/arm/conf/DB-88F5XXXThu Nov 21 03:10:02 2019
(r354934)
@@ -3,6 +3,7 @@
 #
 # $FreeBSD$
 #
+#NO_UNIVERSE
 
 ident  DB-88F5XXX
 include"std.arm"

Modified: head/sys/arm/conf/DB-88F6XXX

==
--- head/sys/arm/conf/DB-88F6XXXThu Nov 21 02:49:41 2019
(r354933)
+++ head/sys/arm/conf/DB-88F6XXXThu Nov 21 03:10:02 2019
(r354934)
@@ -3,6 +3,7 @@
 #
 # $FreeBSD$
 #
+#NO_UNIVERSE
 
 ident  DB-88F6XXX
 include"std.arm"

Modified: head/sys/arm/conf/RT1310

==
--- head/sys/arm/conf/RT1310Thu Nov 21 02:49:41 2019
(r354933)
+++ head/sys/arm/conf/RT1310Thu Nov 21 03:10:02 2019
(r354934)
@@ -3,6 +3,7 @@
 #
 # $FreeBSD$
 #
+#NO_UNIVERSE
 
 ident  RT1310
 include"std.arm"

Modified: head/sys/arm/conf/TS7800

==
--- head/sys/arm/conf/TS7800Thu Nov 21 02:49:41 2019
(r354933)
+++ head/sys/arm/conf/TS7800Thu Nov 21 03:10:02 2019
(r354934)
@@ -3,6 +3,7 @@
 #
 # $FreeBSD$
 #
+#NO_UNIVERSE
 
 ident  TS7800
 include"std.arm"



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r355006 - in head/usr.sbin: rpc.lockd rpc.statd

[Ravi Pokala]

Author: rpokala
Date: Fri Nov 22 16:53:30 2019
New Revision: 355006
URL: https://svnweb.freebsd.org/changeset/base/355006

Log:
  Add and document options to allow rpc.lockd and rpc.statd to run in the
  foreground.
  
  This allows a separate process to monitor when and how those programs exit.
  That process can then restart them if needed.
  
  Submitted by: Alex Burlyga
  Reviewed by:  bcr, imp
  MFC after:1 week
  Sponsored by: Panasas
  Differential Revision:https://reviews.freebsd.org/D22474

Modified:
  head/usr.sbin/rpc.lockd/lockd.c
  head/usr.sbin/rpc.lockd/rpc.lockd.8
  head/usr.sbin/rpc.statd/rpc.statd.8
  head/usr.sbin/rpc.statd/statd.c

Modified: head/usr.sbin/rpc.lockd/lockd.c
==
--- head/usr.sbin/rpc.lockd/lockd.c Fri Nov 22 16:31:43 2019
(r355005)
+++ head/usr.sbin/rpc.lockd/lockd.c Fri Nov 22 16:53:30 2019
(r355006)
@@ -120,6 +120,7 @@ main(int argc, char **argv)
char *endptr, **hosts_bak;
struct sigaction sigalarm;
int grace_period = 30;
+   int foreground = 0;
struct netconfig *nconf;
int have_v6 = 1;
int maxrec = RPC_MAXDATASIZE;
@@ -127,7 +128,7 @@ main(int argc, char **argv)
int attempt_cnt, port_len, port_pos, ret;
char **port_list;
 
-   while ((ch = getopt(argc, argv, "d:g:h:p:")) != (-1)) {
+   while ((ch = getopt(argc, argv, "d:Fg:h:p:")) != (-1)) {
switch (ch) {
case 'd':
debug_level = atoi(optarg);
@@ -136,6 +137,9 @@ main(int argc, char **argv)
/* NOTREACHED */
}
break;
+   case 'F':
+   foreground = 1;
+   break;
case 'g':
grace_period = atoi(optarg);
if (!grace_period) {
@@ -422,7 +426,7 @@ main(int argc, char **argv)
 * Note that it is NOT sensible to run this program from inetd - the
 * protocol assumes that it will run immediately at boot time.
 */
-   if (daemon(0, debug_level > 0)) {
+   if ((foreground == 0) && daemon(0, debug_level > 0)) {
err(1, "cannot fork");
/* NOTREACHED */
}
@@ -844,7 +848,7 @@ void
 usage()
 {
errx(1, "usage: rpc.lockd [-d ]"
-   " [-g ] [-h ] [-p ]");
+   " [-F] [-g ] [-h ] [-p ]");
 }
 
 /*

Modified: head/usr.sbin/rpc.lockd/rpc.lockd.8
==
--- head/usr.sbin/rpc.lockd/rpc.lockd.8 Fri Nov 22 16:31:43 2019
(r355005)
+++ head/usr.sbin/rpc.lockd/rpc.lockd.8 Fri Nov 22 16:53:30 2019
(r355006)
@@ -29,7 +29,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd November 2, 2007
+.Dd November 21, 2019
 .Dt RPC.LOCKD 8
 .Os
 .Sh NAME
@@ -38,6 +38,7 @@
 .Sh SYNOPSIS
 .Nm
 .Op Fl d Ar debug_level
+.Op Fl F
 .Op Fl g Ar grace period
 .Op Fl h Ar bindip
 .Op Fl p Ar port
@@ -70,6 +71,17 @@ in the generation of one log line per protocol operati
 Higher
 debug levels can be specified, causing display of operation arguments
 and internal operations of the daemon.
+.It Fl F
+Run
+.Nm
+in the foreground, rather than going into daemon mode.
+This is useful if some other process uses
+.Xr fork 2
+and
+.Xr exec 3
+to run
+.Nm ,
+and wants to monitor when and how it exits.
 .It Fl g
 The
 .Fl g

Modified: head/usr.sbin/rpc.statd/rpc.statd.8
==
--- head/usr.sbin/rpc.statd/rpc.statd.8 Fri Nov 22 16:31:43 2019
(r355005)
+++ head/usr.sbin/rpc.statd/rpc.statd.8 Fri Nov 22 16:53:30 2019
(r355006)
@@ -29,7 +29,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd November 1, 2007
+.Dd November 21, 2019
 .Dt RPC.STATD 8
 .Os
 .Sh NAME
@@ -38,6 +38,7 @@
 .Sh SYNOPSIS
 .Nm
 .Op Fl d
+.Op Fl F
 .Op Fl h Ar bindip
 .Op Fl p Ar port
 .Sh DESCRIPTION
@@ -71,6 +72,17 @@ These messages are logged with level
 LOG_DEBUG and facility LOG_DAEMON.
 Error conditions are logged irrespective
 of this option, using level LOG_ERR.
+.It Fl F
+Run
+.Nm
+in the foreground, rather than going into daemon mode.
+This is useful if some other process uses
+.Xr fork 2
+and
+.Xr exec 3
+to run
+.Nm ,
+and wants to monitor when and how it exits.
 .It Fl h Ar bindip
 Specify specific IP addresses to bind to.
 This option may be specified multiple times.

Modified: head/usr.sbin/rpc.statd/statd.c
==
--- head/usr.sbin/rpc.statd/statd.c Fri Nov 22 16:31:43 2019
(r355005)
+++ head/usr.sbin/rpc.statd/statd.c Fri Nov 22 16:53:30 2019
(r355006)
@@ -89,15 +89,19 @@ main(int argc, char **argv)
   char *endptr;
   char **hosts_bak;
   int have_v6 = 1;
+  int foreground = 0;
   int maxrec = RPC_MAXDATASIZE;
   int attempt_cnt, port_len, port_pos

Re: svn commit: r355018 - in head/sys: dev/random sys

[Ravi Pokala]

Hi Conrad,

The original code did

explicit_bzero(data, size);

which appears to have been lost in this change. Is that intentional? If so, why 
is that okay?

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Conrad Meyer 

Date: 2019-11-22, Friday at 12:20
To: , , 

Subject: svn commit: r355018 - in head/sys: dev/random sys

Author: cem
Date: Fri Nov 22 20:20:37 2019
New Revision: 355018
URL: https://svnweb.freebsd.org/changeset/base/355018

Log:
  random(4): Abstract loader entropy injection
  
  Break random_harvestq_prime up into some logical subroutines.  The goal
  is that it becomes easier to add other early entropy sources.
  
  While here, drop pre-12.0 compatibility logic.  loader default 
configuration
  should preload the file as expeced since 12.0.
  
  Approved by:  csprng(delphij, markm)
  Differential Revision:https://reviews.freebsd.org/D22482

Modified:
  head/sys/dev/random/random_harvestq.c
  head/sys/sys/random.h

Modified: head/sys/dev/random/random_harvestq.c

==
--- head/sys/dev/random/random_harvestq.c   Fri Nov 22 20:18:07 2019
(r355017)
+++ head/sys/dev/random/random_harvestq.c   Fri Nov 22 20:20:37 2019
(r355018)
@@ -402,6 +402,57 @@ random_harvestq_init(void *unused __unused)
 SYSINIT(random_device_h_init, SI_SUB_RANDOM, SI_ORDER_SECOND, 
random_harvestq_init, NULL);
 
 /*
+ * Subroutine to slice up a contiguous chunk of 'entropy' and feed it into 
the
+ * underlying algorithm.  Returns number of bytes actually fed into 
underlying
+ * algorithm.
+ */
+static size_t
+random_early_prime(char *entropy, size_t len)
+{
+   struct harvest_event event;
+   size_t i;
+
+   len = rounddown(len, sizeof(event.he_entropy));
+   if (len == 0)
+   return (0);
+
+   for (i = 0; i < len; i += sizeof(event.he_entropy)) {
+   event.he_somecounter = (uint32_t)get_cyclecount();
+   event.he_size = sizeof(event.he_entropy);
+   event.he_source = RANDOM_CACHED;
+   event.he_destination =
+   harvest_context.hc_destination[RANDOM_CACHED]++;
+   memcpy(event.he_entropy, entropy + i, sizeof(event.he_entropy));
+   random_harvestq_fast_process_event(&event);
+   }
+   explicit_bzero(entropy, len);
+   return (len);
+}
+
+/*
+ * Subroutine to search for known loader-loaded files in memory and feed 
them
+ * into the underlying algorithm early in boot.  Returns the number of 
bytes
+ * loaded (zero if none were loaded).
+ */
+static size_t
+random_prime_loader_file(const char *type)
+{
+   uint8_t *keyfile, *data;
+   size_t size;
+
+   keyfile = preload_search_by_type(type);
+   if (keyfile == NULL)
+   return (0);
+
+   data = preload_fetch_addr(keyfile);
+   size = preload_fetch_size(keyfile);
+   if (data == NULL)
+   return (0);
+
+   return (random_early_prime(data, size));
+}
+
+/*
  * This is used to prime the RNG by grabbing any early random stuff
  * known to the kernel, and inserting it directly into the hashing
  * module, currently Fortuna.
@@ -410,41 +461,19 @@ SYSINIT(random_device_h_init, SI_SUB_RANDOM, SI_ORDER_
 static void
 random_harvestq_prime(void *unused __unused)
 {
-   struct harvest_event event;
-   size_t count, size, i;
-   uint8_t *keyfile, *data;
+   size_t size;
 
/*
 * Get entropy that may have been preloaded by loader(8)
 * and use it to pre-charge the entropy harvest queue.
 */
-   keyfile = preload_search_by_type(RANDOM_CACHED_BOOT_ENTROPY_MODULE);
-#ifndef NO_BACKWARD_COMPATIBILITY
-   if (keyfile == NULL)
-   keyfile = preload_search_by_type(RANDOM_LEGACY_BOOT_ENTROPY_MODULE);
-#endif
-   if (keyfile != NULL) {
-   data = preload_fetch_addr(keyfile);
-   size = preload_fetch_size(keyfile);
-   /* Trim the size. If the admin has a file with a funny size, we 
lose some. Tough. */
-   size -= (size % sizeof(event.he_entropy));
-   if (data != NULL && size != 0) {
-   for (i = 0; i < size; i += sizeof(event.he_entropy)) {
-   count = sizeof(event.he_entropy);
-   event.he_somecounter = 
(uint32_t)get_cyclecount();
-   event.he_size = count;
-   event.he_source = RANDOM_CACHED;
-   event.he_destination =
-   
harvest_context.hc_destination[RANDOM_CACHED]++;
-   memcpy(e

Re: svn commit: r355019 - head/sbin/dhclient

[Ravi Pokala]

Hi Dave,

These changes are to sbin/dhclient; how does that help loader.efi?

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Dave Cottlehuber 

Date: 2019-11-22, Friday at 12:22
To: , , 

Subject: svn commit: r355019 - head/sbin/dhclient

Author: dch (ports committer)
Date: Fri Nov 22 20:22:16 2019
New Revision: 355019
URL: https://svnweb.freebsd.org/changeset/base/355019

Log:
  dhclient: support option 114, default-url ascii
  
  This will enable further automation of HTTP UEFI boot loader support by
  providing a specific option for providing the boot URL to FreeBSD.
  
  Documented in:
  
  
https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml
  https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcp-options
  https://tools.ietf.org/html/rfc3679
  
  Approved by:  emaste
  MFC after:2 weeks
  Sponsored by: SkunkWerks, GmbH
  Differential Revision:https://reviews.freebsd.org/D22475

Modified:
  head/sbin/dhclient/dhclient.c
  head/sbin/dhclient/dhcp-options.5
  head/sbin/dhclient/dhcp.h
  head/sbin/dhclient/tables.c

Modified: head/sbin/dhclient/dhclient.c

==
--- head/sbin/dhclient/dhclient.c   Fri Nov 22 20:20:37 2019
(r355018)
+++ head/sbin/dhclient/dhclient.c   Fri Nov 22 20:22:16 2019
(r355019)
@@ -2601,6 +2601,7 @@ check_option(struct client_lease *l, int option)
case DHO_DHCP_CLIENT_IDENTIFIER:
case DHO_BOOTFILE_NAME:
case DHO_DHCP_USER_CLASS_ID:
+   case DHO_URL:
case DHO_END:
return (1);
case DHO_CLASSLESS_ROUTES:

Modified: head/sbin/dhclient/dhcp-options.5

==
--- head/sbin/dhclient/dhcp-options.5   Fri Nov 22 20:20:37 2019
(r355018)
+++ head/sbin/dhclient/dhcp-options.5   Fri Nov 22 20:22:16 2019
(r355019)
@@ -587,6 +587,9 @@ Servers should be listed in order of preference.
 The StreetTalk Directory Assistance (STDA) server option specifies a
 list of STDA servers available to the client.
 Servers should be listed in order of preference.
+.It Ic option url Ar string ;
+This option specifies the URL that the client may use when using UEFI
+boot from a HTTP server.
 .El
 .Sh SEE ALSO
 .Xr dhclient.conf 5 ,
@@ -595,7 +598,7 @@ Servers should be listed in order of preference.
 .Xr dhclient 8 ,
 .Xr dhcpd 8
 .Rs
-.%R "RFC 2131, RFC 2132"
+.%R "RFC 2131, RFC 2132, RFC 3769"
 .Re
 .Sh AUTHORS
 .An -nosplit

Modified: head/sbin/dhclient/dhcp.h

==
--- head/sbin/dhclient/dhcp.h   Fri Nov 22 20:20:37 2019
(r355018)
+++ head/sbin/dhclient/dhcp.h   Fri Nov 22 20:22:16 2019
(r355019)
@@ -171,6 +171,7 @@ struct dhcp_packet {
 #defineDHO_STREETTALK_SERVER   75
 #defineDHO_STREETTALK_DA_SERVER76
 #define DHO_DHCP_USER_CLASS_ID 77
+#defineDHO_URL 114
 #defineDHO_DOMAIN_SEARCH   119
 #define DHO_CLASSLESS_ROUTES   121
 #define DHO_END255

Modified: head/sbin/dhclient/tables.c

==
--- head/sbin/dhclient/tables.c Fri Nov 22 20:20:37 2019
(r355018)
+++ head/sbin/dhclient/tables.c Fri Nov 22 20:22:16 2019
(r355019)
@@ -181,7 +181,7 @@ struct option dhcp_options[256] = {
{ "option-111", "X",&dhcp_universe, 111 },
{ "option-112", "X",&dhcp_universe, 112 },
{ "option-113", "X",&dhcp_universe, 113 },
-   { "option-114", "X",&dhcp_universe, 114 },
+   { "url", "t",   &dhcp_universe, 114 },
{ "option-115", "X",&dhcp_universe, 115 },
{ "option-116", "X",&dhcp_universe, 116 },
{ "option-117", "X",&dhcp_universe, 117 },
@@ -404,11 +404,12 @@ unsigned char dhcp_option_default_priority_list[] = {
DHO_STREETTALK_DA_SERVER,
DHO_DHCP_USER_CLASS_ID,
DHO_DOMAIN_SEARCH,
+   DHO_URL,
 
/* Presently-undefined options... */
62, 63, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91,
92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105,
-   106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117,
+   106, 107, 108, 109, 110, 111, 112, 113,  

Re: svn commit: r355018 - in head/sys: dev/random sys

[Ravi Pokala]

-Original Message-
From: Conrad Meyer 
Reply-To: 
Date: 2019-11-22, Friday at 13:07
To: Ravi Pokala 
Cc: src-committers , svn-src-all 
, svn-src-head 
Subject: Re: svn commit: r355018 - in head/sys: dev/random sys

It wasn't lost in the change.  The parameters now have the names
"entropy" and "len," but it is the same functionality.



I really need to get new glasses... 

-Ravi (rpokala@)

Best,
Conrad

On Fri, Nov 22, 2019 at 12:56 PM Ravi Pokala  wrote:
>
> Hi Conrad,
>
> The original code did
>
> explicit_bzero(data, size);
>
> which appears to have been lost in this change. Is that intentional? If 
so, why is that okay?
>
> Thanks,
>
> Ravi (rpokala@)
>
> -Original Message-
> From:  on behalf of Conrad Meyer 

> Date: 2019-11-22, Friday at 12:20
> To: , , 

> Subject: svn commit: r355018 - in head/sys: dev/random sys
>
> Author: cem
> Date: Fri Nov 22 20:20:37 2019
> New Revision: 355018
> URL: https://svnweb.freebsd.org/changeset/base/355018
>
> Log:
>   random(4): Abstract loader entropy injection
>
>   Break random_harvestq_prime up into some logical subroutines.  The 
goal
>   is that it becomes easier to add other early entropy sources.
>
>   While here, drop pre-12.0 compatibility logic.  loader default 
configuration
>   should preload the file as expeced since 12.0.
>
>   Approved by:  csprng(delphij, markm)
>   Differential Revision:https://reviews.freebsd.org/D22482
>
> Modified:
>   head/sys/dev/random/random_harvestq.c
>   head/sys/sys/random.h
>
> Modified: head/sys/dev/random/random_harvestq.c
> 
==
> --- head/sys/dev/random/random_harvestq.c   Fri Nov 22 20:18:07 2019  
  (r355017)
> +++ head/sys/dev/random/random_harvestq.c   Fri Nov 22 20:20:37 2019  
  (r355018)
> @@ -402,6 +402,57 @@ random_harvestq_init(void *unused __unused)
>  SYSINIT(random_device_h_init, SI_SUB_RANDOM, SI_ORDER_SECOND, 
random_harvestq_init, NULL);
>
>  /*
> + * Subroutine to slice up a contiguous chunk of 'entropy' and feed 
it into the
> + * underlying algorithm.  Returns number of bytes actually fed into 
underlying
> + * algorithm.
> + */
> +static size_t
> +random_early_prime(char *entropy, size_t len)
> +{
> +   struct harvest_event event;
> +   size_t i;
> +
> +   len = rounddown(len, sizeof(event.he_entropy));
> +   if (len == 0)
> +   return (0);
> +
> +   for (i = 0; i < len; i += sizeof(event.he_entropy)) {
> +   event.he_somecounter = (uint32_t)get_cyclecount();
> +   event.he_size = sizeof(event.he_entropy);
> +   event.he_source = RANDOM_CACHED;
> +   event.he_destination =
> +   harvest_context.hc_destination[RANDOM_CACHED]++;
> +   memcpy(event.he_entropy, entropy + i, 
sizeof(event.he_entropy));
> +   random_harvestq_fast_process_event(&event);
> +   }
> +   explicit_bzero(entropy, len);
> +   return (len);
> +}
> +
> +/*
> + * Subroutine to search for known loader-loaded files in memory and 
feed them
> + * into the underlying algorithm early in boot.  Returns the number 
of bytes
> + * loaded (zero if none were loaded).
> + */
> +static size_t
> +random_prime_loader_file(const char *type)
> +{
> +   uint8_t *keyfile, *data;
> +   size_t size;
> +
> +   keyfile = preload_search_by_type(type);
> +   if (keyfile == NULL)
> +   return (0);
> +
> +   data = preload_fetch_addr(keyfile);
> +   size = preload_fetch_size(keyfile);
> +   if (data == NULL)
> +   return (0);
> +
> +   return (random_early_prime(data, size));
> +}
> +
> +/*
>   * This is used to prime the RNG by grabbing any early random stuff
>   * known to the kernel, and inserting it directly into the hashing
>   * module, currently Fortuna.
> @@ -410,41 +461,19 @@ SYSINIT(random_device_h_init, SI_SUB_RANDOM, 
SI_ORDER_
>  static void
>  random_

svn commit: r345611 - head/sys/dev/jedec_dimm

[Ravi Pokala]

Author: rpokala
Date: Wed Mar 27 21:50:01 2019
New Revision: 345611
URL: https://svnweb.freebsd.org/changeset/base/345611

Log:
  Teach jedec_dimm(4) to be more forgiving of non-fatal errors.
  
  It looks like some DIMMs claim to have a TSOD, but actually don't. Some
  claim they weren't able to change the SPD page, but they did. Neither of
  those should be fatal errors.
  
  PR:   235944
  Submitted by: Greg V 
  Reported by:  Greg V 
  Reviewed by:  cem
  MFC after:1 weeks
  Sponsored by: Panasas
  Differential Revision:https://reviews.freebsd.org/D19681

Modified:
  head/sys/dev/jedec_dimm/jedec_dimm.c

Modified: head/sys/dev/jedec_dimm/jedec_dimm.c
==
--- head/sys/dev/jedec_dimm/jedec_dimm.cWed Mar 27 21:46:45 2019
(r345610)
+++ head/sys/dev/jedec_dimm/jedec_dimm.cWed Mar 27 21:50:01 2019
(r345611)
@@ -270,12 +270,16 @@ jedec_dimm_attach(device_t dev)
}
 
/* The MSBit of the TSOD-presence byte reports whether or not the TSOD
-* is in fact present. If it is, read manufacturer and device info from
-* it to confirm that it's a valid TSOD device. It's an error if any of
-* those bytes are unreadable; it's not an error if the device is simply
-* not known to us (tsod_match == NULL).
-* While DDR3 and DDR4 don't explicitly require a TSOD, essentially all
-* DDR3 and DDR4 DIMMs include one.
+* is in fact present. (While DDR3 and DDR4 don't explicitly require a
+* TSOD, essentially all DDR3 and DDR4 DIMMs include one.) But, as
+* discussed in [PR 235944], it turns out that some DIMMs claim to have
+* a TSOD when they actually don't. (Or maybe the firmware blocks it?)
+* 
+* If the SPD data says the TSOD is present, try to read manufacturer
+* and device info from it to confirm that it's a valid TSOD device.
+* If the data is unreadable, just continue as if the TSOD isn't there.
+* If the data was read successfully, see if it is a known TSOD device;
+* it's okay if it isn't (tsod_match == NULL).
 */
rc = smbus_readb(sc->smbus, sc->spd_addr, tsod_present_offset, &byte);
if (rc != 0) {
@@ -289,12 +293,14 @@ jedec_dimm_attach(device_t dev)
if (rc != 0) {
device_printf(dev,
"failed to read TSOD Manufacturer ID\n");
-   goto out;
+   rc = 0;
+   goto no_tsod;
}
rc = jedec_dimm_readw_be(sc, TSOD_REG_DEV_REV, &devid);
if (rc != 0) {
device_printf(dev, "failed to read TSOD Device ID\n");
-   goto out;
+   rc = 0;
+   goto no_tsod;
}
 
tsod_match = jedec_dimm_tsod_match(vendorid, devid);
@@ -309,6 +315,7 @@ jedec_dimm_attach(device_t dev)
}
}
} else {
+no_tsod:
tsod_match = NULL;
tsod_present = false;
}
@@ -621,9 +628,12 @@ jedec_dimm_dump(struct jedec_dimm_softc *sc, enum dram
rc = smbus_writeb(sc->smbus,
(JEDEC_DTI_PAGE | JEDEC_LSA_PAGE_SET1), 0, 0);
if (rc != 0) {
+   /* Some SPD devices (or SMBus controllers?) claim the
+* page-change command failed when it actually
+* succeeded. Log a message but soldier on.
+*/
device_printf(sc->dev, "unable to change page: %d\n",
rc);
-   goto out;
}
/* Add 256 to the store location, because we're in the second
 * page.


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r345680 - head/sys/conf

[Ravi Pokala]

-Original Message-
From:  on behalf of Kyle Evans 

Date: 2019-03-28, Thursday at 21:00
To: , , 

Subject: svn commit: r345680 - head/sys/conf

> Author: kevans
> Date: Fri Mar 29 04:00:46 2019
> New Revision: 345680
> URL: https://svnweb.freebsd.org/changeset/base/345680
> 
> Log:
>   NOTES: Use non-default value for BOOT_TAG

Why?

(I was on IRC when jhb debugged this, but I didn't quite get it; and of course 
lots of us *weren't* on IRC at the time.)

Thanks,

Ravi (rpokala@)

>   Reported by:jhb
>   MFC after:  1 week (except non-empty value in stable/11)
> 
> Modified:
>   head/sys/conf/NOTES
> 
> Modified: head/sys/conf/NOTES
> ==
> --- head/sys/conf/NOTES   Fri Mar 29 03:25:20 2019(r345679)
> +++ head/sys/conf/NOTES   Fri Mar 29 04:00:46 2019(r345680)
> @@ -150,7 +150,7 @@ options   BOOTHOWTO=RB_MULTIPLE
>  #
>  # Default boot tag; may use 'kern.boot_tag' loader tunable to override.  The
>  # current boot's tag is also exposed via the 'kern.boot_tag' sysctl.
> -options  BOOT_TAG=\"---<>---\"
> +options  BOOT_TAG=\"\"
>  # Maximum boot tag size the kernel's static buffer should accomodate.  
> Maximum
>  # size for both BOOT_TAG and the assocated tunable.
>  options  BOOT_TAG_SZ=32





___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r351747 - head/sys/dev/nvme

[Ravi Pokala]

Hi Warner,

+   /*
+* Per Section 7.6.2 of NVMe spec 1.4, to properly suspend, we need to
+* delete the hardware I/O queues, and then shutdown. This properly
+* flushes any metadata the drive may have stored so it can survive
+* having its power removed and prevents the unsafe shutdown count from
+* incriminating. Once we delete the qpairs, we have to disable them
+* before shutting down. The delay is out of paranoia in
+* nvme_ctrlr_hw_reset, and is repeated here (though we should have no
+* pending I/O that the delay copes with).
+*/
+   nvme_ctrlr_delete_qpairs(ctrlr);
+   nvme_ctrlr_disable_qpairs(ctrlr);
+   DELAY(100*1000);
+   nvme_ctrlr_shutdown(ctrlr);

This seems backwards to me. From that section:

> The host should perform the following actions in sequence for a normal 
> shutdown:
> 1. Stop submitting any new I/O commands to the controller and allow any 
> outstanding commands to complete;
> 2. If the controller implements I/O queues, then the host should delete 
> all I/O Submission Queues, using the Delete I/O Submission Queue command. A 
> result of the successful completion of the Delete I/O Submission Queue 
> command is that any remaining commands outstanding are aborted;
> 3. If the controller implements I/O queues, then the host should delete 
> all I/O Completion Queues, using the Delete I/O Completion Queue command; and
> 4. The host should set the Shutdown Notification (CC.SHN) field to 01b to 
> indicate a normal shutdown operation. The controller indicates when shutdown 
> processing is completed by updating the Shutdown Status (CSTS.SHST) field to 
> 10b.

You are calling nvme_ctrlr_delete_qpairs() -- which implements steps (2) and 
(3) -- before you are calling nvme_ctrlr_disable_qpairs() -- which implements 
step (1).

Or am I missing something?

Thanks,

Ravi (rpokala@)


-Original Message-
From:  on behalf of Warner Losh 

Date: 2019-09-03, Tuesday at 08:26
To: , , 

Subject: svn commit: r351747 - head/sys/dev/nvme

Author: imp
Date: Tue Sep  3 15:26:11 2019
New Revision: 351747
URL: https://svnweb.freebsd.org/changeset/base/351747

Log:
  Implement nvme suspend / resume for pci attachment
  
  When we suspend, we need to properly shutdown the NVME controller. The
  controller may go into D3 state (or may have the power removed), and
  to properly flush the metadata to non-volatile RAM, we must complete a
  normal shutdown. This consists of deleting the I/O queues and setting
  the shutodown bit. We have to do some extra stuff to make sure we
  reset the software state of the queues as well.
  
  On resume, we have to reset the card twice, for reasons described in
  the attach funcion. Once we've done that, we can restart the card. If
  any of this fails, we'll fail the NVMe card, just like we do when a
  reset fails.
  
  Set is_resetting for the duration of the suspend / resume. This keeps
  the reset taskqueue from running a concurrent reset, and also is
  needed to prevent any hw completions from queueing more I/O to the
  card. Pass resetting flag to nvme_ctrlr_start. It doesn't need to get
  that from the global state of the ctrlr. Wait for any pending reset to
  finish. All queued I/O will get sent to the hardware as part of
  nvme_ctrlr_start(), though the upper layers shouldn't send any
  down. Disabling the qpairs is the other failsafe to ensure all I/O is
  queued.
  
  Rename nvme_ctrlr_destory_qpairs to nvme_ctrlr_delete_qpairs to avoid
  confusion with all the other destroy functions.  It just removes the
  queues in hardware, while the other _destroy_ functions tear down
  driver data structures.
  
  Split parts of the hardware reset function up so that I can
  do part of the reset in suspsend. Split out the software disabling
  of the qpairs into nvme_ctrlr_disable_qpairs.
  
  Finally, fix a couple of spelling errors in comments related to
  this.
  
  Relnotes: Yes
  MFC After: 1 week
  Reviewed by: scottl@ (prior version)
  Differential Revision: https://reviews.freebsd.org/D21493

Modified:
  head/sys/dev/nvme/nvme.c
  head/sys/dev/nvme/nvme_ctrlr.c
  head/sys/dev/nvme/nvme_pci.c
  head/sys/dev/nvme/nvme_private.h

Modified: head/sys/dev/nvme/nvme.c

==
--- head/sys/dev/nvme/nvme.cTue Sep  3 14:55:19 2019
(r351746)
+++ head/sys/dev/nvme/nvme.cTue Sep  3 15:26:11 2019
(r351747)
@@ -137,9 +137,10 @@ nvme_attach(device_t dev)
}
 
/*
-* Reset controller twice to ensure we do a transition from cc.en==1
-*  to cc.en==0.  This is because we don't really know what status
-   

Re: svn commit: r352925 - head/sys/dev/xen/control

[Ravi Pokala]

Hi Roger,

If I'm understanding this diff correctly, all of (poweroff, reboot, suspend) 
will use the common string "shutdown", rather than an event-specific string. Is 
that what we want?

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Roger Pau Monné 

Date: 2019-10-01, Tuesday at 01:21
To: , , 

Subject: svn commit: r352925 - head/sys/dev/xen/control

Author: royger
Date: Tue Oct  1 08:21:41 2019
New Revision: 352925
URL: https://svnweb.freebsd.org/changeset/base/352925

Log:
  xen/ctrl: acknowledge all control requests
  
  Currently only suspend requests are acknowledged by writing an empty
  string back to the xenstore control node, but poweroff or reboot
  requests are not acknowledged and FreeBSD simply proceeds to perform
  the desired action.
  
  Fix this by acknowledging all requests, and remove the suspend specific
  ack done in the handler.
  
  Sponsored by: Citrix Systems R&D
  MFC after:3 days

Modified:
  head/sys/dev/xen/control/control.c

Modified: head/sys/dev/xen/control/control.c

==
--- head/sys/dev/xen/control/control.c  Tue Oct  1 03:35:54 2019
(r352924)
+++ head/sys/dev/xen/control/control.c  Tue Oct  1 08:21:41 2019
(r352925)
@@ -221,12 +221,6 @@ xctrl_suspend()
KASSERT((PCPU_GET(cpuid) == 0), ("Not running on CPU#0"));
 
/*
-* Clear our XenStore node so the toolstack knows we are
-* responding to the suspend request.
-*/
-   xs_write(XST_NIL, "control", "shutdown", "");
-
-   /*
 * Be sure to hold Giant across DEVICE_SUSPEND/RESUME since non-MPSAFE
 * drivers need this.
 */
@@ -368,6 +362,11 @@ xctrl_on_watch_event(struct xs_watch *watch, const cha
&result_len, (void **)&result);
if (error != 0)
return;
+
+   /* Acknowledge the request by writing back an empty string. */
+   error = xs_write(XST_NIL, "control", "shutdown", "");
+   if (error != 0)
+   printf("unable to ack shutdown request, proceeding anyway\n");
 
reason = xctrl_shutdown_reasons;
last_reason = reason + nitems(xctrl_shutdown_reasons);



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r348376 - head/sys/sys

[Ravi Pokala]

Author: rpokala
Date: Wed May 29 23:50:31 2019
New Revision: 348376
URL: https://svnweb.freebsd.org/changeset/base/348376

Log:
  Add bits related to SANITIZE, SED, and form-factor to (struct ata_params)
  
  Based on ATA-ACS-4, recognize several bit-fields related to the ATA SANITIZE
  feature-set, Self-Encrypting Drives, and form-factor identification.
  
  As part of this change, the name of word 48 of (struct ata_params) is being
  changed. The previous name, "usedmovsd" does not appear to be related to the
  previous definition of the word ("double-word IO supported"). The word was
  defined that way in ATA-1 (1994), but it was marked "Reserved" (meaning
  "unused, but might be used in the future") in ATA-2 (1996). It stayed that
  way until ATA-8 (2008), which re-defined it as implemented in this change.
  The field is not used in-tree.
  
  Reviewed by:  mav
  Sponsored by: Panasas
  Differential Revision:https://reviews.freebsd.org/D20455

Modified:
  head/sys/sys/ata.h

Modified: head/sys/sys/ata.h
==
--- head/sys/sys/ata.h  Wed May 29 23:11:07 2019(r348375)
+++ head/sys/sys/ata.h  Wed May 29 23:50:31 2019(r348376)
@@ -66,7 +66,8 @@ struct ata_params {
 /*023*/ u_int8_trevision[8];/* firmware revision */
 /*027*/ u_int8_tmodel[40];  /* model name */
 /*047*/ u_int16_t   sectors_intr;   /* sectors per interrupt */
-/*048*/ u_int16_t   usedmovsd;  /* double word read/write? */
+/*048*/ u_int16_t   tcg;/* Trusted Computing Group */
+#define ATA_SUPPORT_TCG 0x0001
 /*049*/ u_int16_t   capabilities1;
 #define ATA_SUPPORT_DMA 0x0100
 #define ATA_SUPPORT_LBA 0x0200
@@ -92,6 +93,10 @@ struct ata_params {
 /*057*/ u_int16_t   current_size_1;
 /*058*/ u_int16_t   current_size_2;
 /*059*/ u_int16_t   multi;
+#define ATA_SUPPORT_BLOCK_ERASE_EXT 0x8000
+#define ATA_SUPPORT_OVERWRITE_EXT   0x4000
+#define ATA_SUPPORT_CRYPTO_SCRAMBLE_EXT 0x2000
+#define ATA_SUPPORT_SANITIZE0x1000
 #define ATA_MULTI_VALID 0x0100
 
 /*060*/ u_int16_t   lba_size_1;
@@ -107,6 +112,7 @@ struct ata_params {
 /*069*/ u_int16_t   support3;
 #define ATA_SUPPORT_RZAT0x0020
 #define ATA_SUPPORT_DRAT0x4000
+#define ATA_ENCRYPTS_ALL_USER_DATA  0x0010  /* Self-encrypting drive */
 #defineATA_SUPPORT_ZONE_MASK   0x0003
 #defineATA_SUPPORT_ZONE_NR 0x
 #defineATA_SUPPORT_ZONE_HOST_AWARE 0x0001
@@ -259,7 +265,19 @@ struct ata_params {
 /*162*/ u_int16_t   cfa_kms_support;
 /*163*/ u_int16_t   cfa_trueide_modes;
 /*164*/ u_int16_t   cfa_memory_modes;
-   u_int16_t   reserved165[4];
+   u_int16_t   reserved165[3];
+/*168*/ u_int16_t   form_factor;
+#define ATA_FORM_FACTOR_MASK   0x000f
+#define ATA_FORM_FACTOR_NOT_REPORTED   0x
+#define ATA_FORM_FACTOR_5_25   0x0001
+#define ATA_FORM_FACTOR_3_50x0002
+#define ATA_FORM_FACTOR_2_50x0003
+#define ATA_FORM_FACTOR_1_80x0004
+#define ATA_FORM_FACTOR_SUB_1_80x0005
+#define ATA_FORM_FACTOR_MSATA  0x0006
+#define ATA_FORM_FACTOR_M_20x0007
+#define ATA_FORM_FACTOR_MICRO_SSD  0x0008
+#define ATA_FORM_FACTOR_C_FAST 0x0009
 /*169*/u_int16_t   support_dsm;
 #define ATA_SUPPORT_DSM_TRIM   0x0001
u_int16_t   reserved170[6];
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r350665 - in head: . etc/mtree sbin/mount_fusefs share/man/man5 sys/fs/fuse sys/sys tests/sys/fs tests/sys/fs/fusefs

[Ravi Pokala]

-Original Message-
From:  on behalf of Alan Somers 

Date: 2019-08-06, Tuesday at 17:38
To: , , 

Subject: svn commit: r350665 - in head: . etc/mtree sbin/mount_fusefs 
share/man/man5 sys/fs/fuse sys/sys tests/sys/fs tests/sys/fs/fusefs

> Author: asomers
> Date: Wed Aug  7 00:38:26 2019
> New Revision: 350665
> URL: https://svnweb.freebsd.org/changeset/base/350665
> 
> Log:
>   fusefs: merge from projects/fuse2

Thanks Alan! I've been watching this work with significant interest[*] for 
quite a while, and am glad this is finally landing.

Thanks again,

Ravi (rpokala@)

[*] or as much interest as anyone who knows ~nothing about filesystems can 
muster ;-)

>   This commit imports the new fusefs driver. It raises the protocol level
>   from 7.8 to 7.23, fixes many bugs, adds a test suite for the driver, and
>   adds many new features. New features include:
>   
>   * Optional kernel-side permissions checks (-o default_permissions)
>   * Implement VOP_MKNOD, VOP_BMAP, and VOP_ADVLOCK
>   * Allow interrupting FUSE operations
>   * Support named pipes and unix-domain sockets in fusefs file systems
>   * Forward UTIME_NOW during utimensat(2) to the daemon
>   * kqueue support for /dev/fuse
>   * Allow updating mounts with "mount -u"
>   * Allow exporting fusefs file systems over NFS
>   * Server-initiated invalidation of the name cache or data cache
>   * Respect RLIMIT_FSIZE
>   * Try to support servers as old as protocol 7.4
>   
>   Performance enhancements include:
>   
>   * Implement FUSE's FOPEN_KEEP_CACHE and FUSE_ASYNC_READ flags
>   * Cache file attributes
>   * Cache lookup entries, both positive and negative
>   * Server-selectable cache modes: writethrough, writeback, or uncached
>   * Write clustering
>   * Readahead
>   * Use counter(9) for statistical reporting
>   
>   PR: 199934 216391 233783 234581 235773 235774 235775
>   PR: 236226 236231 236236 236291 236329 236381 236405
>   PR: 236327 236466 236472 236473 236474 236530 236557
>   PR: 236560 236844 237052 237181 237588 238565
>   Reviewed by:bcr (man pages)
>   Reviewed by:cem, ngie, rpokala, glebius, kib, bde, emaste 
> (post-commit
>   review on project branch)
>   MFC after:  3 weeks
>   Relnotes:   yes
>   Sponsored by:   The FreeBSD Foundation
>   Pull Request:   https://reviews.freebsd.org/D21110


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r350843 - head

[Ravi Pokala]

Since you brought it up, why are the LINTs generated into the src tree anyway? 
Shouldn't they go in the build tree?

-Ravi (rpokala@)

-Original Message-
From:  on behalf of Conrad Meyer 

Date: 2019-08-10, Saturday at 11:22
To: , , 

Subject: svn commit: r350843 - head

Author: cem
Date: Sat Aug 10 18:22:22 2019
New Revision: 350843
URL: https://svnweb.freebsd.org/changeset/base/350843

Log:
  .gitignore: Add LINT kernel configurations generated into SRCDIR

Modified:
  head/.gitignore

Modified: head/.gitignore

==
--- head/.gitignore Sat Aug 10 17:58:30 2019(r350842)
+++ head/.gitignore Sat Aug 10 18:22:22 2019(r350843)
@@ -17,3 +17,19 @@ GTAGS
 ID
 cscope.out
 ?cscope.out
+# Ignore LINT generated configs.
+/sys/amd64/conf/LINT
+/sys/amd64/conf/LINT-NOINET
+/sys/amd64/conf/LINT-NOINET6
+/sys/amd64/conf/LINT-NOIP
+/sys/arm/conf/LINT
+/sys/arm/conf/LINT-V5
+/sys/arm/conf/LINT-V7
+/sys/arm64/conf/LINT
+/sys/i386/conf/LINT
+/sys/i386/conf/LINT-NOINET
+/sys/i386/conf/LINT-NOINET6
+/sys/i386/conf/LINT-NOIP
+/sys/powerpc/conf/LINT
+/sys/powerpc/conf/LINT64
+/sys/sparc64/conf/LINT




___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r362781 - head/sys/compat/linuxkpi/common/include/linux

[Ravi Pokala]

-Original Message-
From:  on behalf of Hans Petter Selasky 

Date: 2020-06-29, Monday at 06:08
To: , , 

Subject: svn commit: r362781 - head/sys/compat/linuxkpi/common/include/linux

Author: hselasky
Date: Mon Jun 29 13:08:40 2020
New Revision: 362781
URL: https://svnweb.freebsd.org/changeset/base/362781

Log:
  Implement is_signed(), type_max() and type_min() function macros in the
  LinuxKPI.

  MFC after:1 week
  Sponsored by: Mellanox Technologies

Modified:
  head/sys/compat/linuxkpi/common/include/linux/kernel.h

Modified: head/sys/compat/linuxkpi/common/include/linux/kernel.h

==
--- head/sys/compat/linuxkpi/common/include/linux/kernel.h  Mon Jun 29 
12:59:09 2020(r362780)
+++ head/sys/compat/linuxkpi/common/include/linux/kernel.h  Mon Jun 29 
13:08:40 2020(r362781)
@@ -564,4 +564,20 @@ linux_ratelimited(linux_ratelimit_t *rl)
 #define__is_constexpr(x) \
__builtin_constant_p(x)

Hi Hans,

+#defineis_signed(x) (((x)-1 / (x)2) == (x)0)

It took me several reads to understand this, until I figured out that 'x' is 
not a variable, it's the name of a *type*.

If 'x' is a variable, then '(x)-1' is subtraction, but '(x)2' and '(x)0' are 
nonsensical.

If 'x' is a *type*, then '(x)-1' is typecasting '-1', and similarly for '(x)2' 
and '(x)0'.

So, perhaps a comment, or a better name for 'x'?

Thanks,

Ravi (rpokala@)

+#definetype_max(x) (   
\
+  (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MAX : UINT64_MAX) : \
+  (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MAX : UINT32_MAX) : \
+  (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MAX : UINT16_MAX) : \
+(is_signed(x) ? INT8_MAX : UINT8_MAX)  \
+)
+
+#definetype_min(x) (   \
+  (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MIN : 0) :  \
+  (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MIN : 0) :  \
+  (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MIN : 0) :  \
+(is_signed(x) ? INT8_MIN : 0)  \
+)
+
 #endif /* _LINUX_KERNEL_H_ */


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r362781 - head/sys/compat/linuxkpi/common/include/linux

[Ravi Pokala]

From:  on behalf of Warner Losh 

Date: 2020-06-29, Monday at 13:26
To: Ravi Pokala 
Cc: Hans Petter Selasky , src-committers 
, , 

Subject: Re: svn commit: r362781 - head/sys/compat/linuxkpi/common/include/linux

 

On Mon, Jun 29, 2020, 2:15 PM Ravi Pokala  wrote:

-Original Message-
From:  on behalf of Hans Petter Selasky 

Date: 2020-06-29, Monday at 06:08
To: , , 

Subject: svn commit: r362781 - head/sys/compat/linuxkpi/common/include/linux

Author: hselasky
Date: Mon Jun 29 13:08:40 2020
New Revision: 362781
URL: https://svnweb.freebsd.org/changeset/base/362781

Log:
  Implement is_signed(), type_max() and type_min() function macros in the
  LinuxKPI.

  MFC after:1 week
  Sponsored by: Mellanox Technologies

Modified:
  head/sys/compat/linuxkpi/common/include/linux/kernel.h

Modified: head/sys/compat/linuxkpi/common/include/linux/kernel.h

==
--- head/sys/compat/linuxkpi/common/include/linux/kernel.h  Mon Jun 29 
12:59:09 2020(r362780)
+++ head/sys/compat/linuxkpi/common/include/linux/kernel.h  Mon Jun 29 
13:08:40 2020(r362781)
@@ -564,4 +564,20 @@ linux_ratelimited(linux_ratelimit_t *rl)
 #define__is_constexpr(x) \
__builtin_constant_p(x)

Hi Hans,

+#defineis_signed(x) (((x)-1 / (x)2) == (x)0)

It took me several reads to understand this, until I figured out that 'x' is 
not a variable, it's the name of a *type*.

If 'x' is a variable, then '(x)-1' is subtraction, but '(x)2' and '(x)0' are 
nonsensical.

If 'x' is a *type*, then '(x)-1' is typecasting '-1', and similarly for '(x)2' 
and '(x)0'.

So, perhaps a comment, or a better name for 'x'?

 

I had similar thoughts. Maybe 't' instead?

 

Letters are cheap now, Warner; we can afford to spell out "type". :-)

 

-Ravi (rpokala@)

 

Warner

 

Thanks,

Ravi (rpokala@)

+#definetype_max(x) (   
\
+  (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MAX : UINT64_MAX) : \
+  (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MAX : UINT32_MAX) : \
+  (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MAX : UINT16_MAX) : \
+(is_signed(x) ? INT8_MAX : UINT8_MAX)  \
+)
+
+#definetype_min(x) (   \
+  (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MIN : 0) :  \
+  (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MIN : 0) :  \
+  (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MIN : 0) :  \
+(is_signed(x) ? INT8_MIN : 0)  \
+)
+
 #endif /* _LINUX_KERNEL_H_ */


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r362794 - head/sys/compat/linuxkpi/common/include/linux

[Ravi Pokala]

Thank you!

-Ravi (rpokala@)


-Original Message-
From:  on behalf of Hans Petter Selasky 

Date: 2020-06-30, Tuesday at 01:41
To: , , 

Subject: svn commit: r362794 - head/sys/compat/linuxkpi/common/include/linux

Author: hselasky
Date: Tue Jun 30 08:41:33 2020
New Revision: 362794
URL: https://svnweb.freebsd.org/changeset/base/362794

Log:
  Document the is_signed(), type_max() and type_min() function macros in the
  LinuxKPI. Try to make the function argument more readable.

  Suggested by: several
  MFC after:1 week
  Sponsored by: Mellanox Technologies

Modified:
  head/sys/compat/linuxkpi/common/include/linux/kernel.h

Modified: head/sys/compat/linuxkpi/common/include/linux/kernel.h

==
--- head/sys/compat/linuxkpi/common/include/linux/kernel.h  Tue Jun 30 
07:37:24 2020(r362793)
+++ head/sys/compat/linuxkpi/common/include/linux/kernel.h  Tue Jun 30 
08:41:33 2020(r362794)
@@ -564,20 +564,33 @@ linux_ratelimited(linux_ratelimit_t *rl)
 #define__is_constexpr(x) \
__builtin_constant_p(x)

-#defineis_signed(x) (((x)-1 / (x)2) == (x)0)
+/*
+ * The is_signed() macro below returns true if the passed data type is
+ * signed. Else false is returned.
+ */
+#defineis_signed(datatype) (((datatype)-1 / (datatype)2) == 
(datatype)0)

-#definetype_max(x) (   \
-  (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MAX : UINT64_MAX) : \
-  (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MAX : UINT32_MAX) : \
-  (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MAX : UINT16_MAX) : \
-(is_signed(x) ? INT8_MAX : UINT8_MAX)  \
+/*
+ * The type_max() macro below returns the maxium positive value the
+ * passed data type can hold.
+ */
+#definetype_max(datatype) ( \
+  (sizeof(datatype) >= 8) ? (is_signed(datatype) ? INT64_MAX : UINT64_MAX) 
: \
+  (sizeof(datatype) >= 4) ? (is_signed(datatype) ? INT32_MAX : UINT32_MAX) 
: \
+  (sizeof(datatype) >= 2) ? (is_signed(datatype) ? INT16_MAX : UINT16_MAX) 
: \
+   (is_signed(datatype) ? INT8_MAX : UINT8_MAX) \
 )

-#definetype_min(x) (   \
-  (sizeof(x) >= 8) ? (is_signed(x) ? INT64_MIN : 0) :  \
-  (sizeof(x) >= 4) ? (is_signed(x) ? INT32_MIN : 0) :  \
-  (sizeof(x) >= 2) ? (is_signed(x) ? INT16_MIN : 0) :  \
-(is_signed(x) ? INT8_MIN : 0)  \
+/*
+ * The type_min() macro below returns the minimum value the passed
+ * data type can hold. For unsigned types the minimum value is always
+ * zero. For signed types it may vary.
+ */
+#definetype_min(datatype) ( \
+  (sizeof(datatype) >= 8) ? (is_signed(datatype) ? INT64_MIN : 0) : \
+  (sizeof(datatype) >= 4) ? (is_signed(datatype) ? INT32_MIN : 0) : \
+  (sizeof(datatype) >= 2) ? (is_signed(datatype) ? INT16_MIN : 0) : \
+   (is_signed(datatype) ? INT8_MIN : 0) \
 )

 #endif /* _LINUX_KERNEL_H_ */


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r363091 - in head/contrib/bc: . include manuals src tests tests/bc

[Ravi Pokala]

-Original Message-
From:  on behalf of Jessica Clarke 

Date: 2020-07-30, Thursday at 09:35
To: Baptiste Daroussin 
Cc: Stefan Eßer , src-committers 
, , 

Subject: Re: svn commit: r363091 - in head/contrib/bc: . include manuals src 
tests tests/bc

On 30 Jul 2020, at 17:31, Baptiste Daroussin  wrote:
> On Thu, Jul 30, 2020 at 05:28:19PM +0100, Jessica Clarke wrote:
>> On 30 Jul 2020, at 17:20, Baptiste Daroussin  wrote:
>>> On Sat, Jul 11, 2020 at 07:33:19AM +, Stefan Eßer wrote:
 Author: se
 Date: Sat Jul 11 07:33:18 2020
 New Revision: 363091
 URL: https://svnweb.freebsd.org/changeset/base/363091
 
 Log:
 Update to version 3.1.3
 
>>> Jumping on that commit, since the switch from our previous bc.
>>> 
>>> The output of the interactive bc has changed, the previous version had 
a clean
>>> UI, the new version "pollutes" the output with plenty of lines about the
>>> copyright:
>>> 
>>> 
>>> Copyright (c) 2018-2020 Gavin D. Howard and contributors
>>> Report bugs at: https://git.yzena.com/gavin/bc
>>> 
>>> This is free software with ABSOLUTELY NO WARRANTY.
>>> 
>>> 
>>> Imagine if all programs where doing that, it would be painful, do you 
think
>>> upstream can be convinced to remove those lines?
>>> 
>>> I no the GNU version also has the same polluted output which was one of 
the
>>> reason I was happy with out previous version of bc.
>> 
>> By default both will print such a banner if and only if being called
>> interactively. You can disable the banner explicitly with -q/--quiet
>> for both GNU bc and this bc. I agree it's a bit noisy and would be
>> nicer to not have that printed, but it's not without precedent for
>> REPL-like things.
> 
> Yes it is not without precedent for REPL-like things, still I dislike 
this and
> would be happy to get bc interactive be as nice as the previous one we 
had :)
> 
> If not I will deal with it and just yell internally each time I run it :D

`alias bc='bc -q'` / `alias bc bc -q` and preserve your inner zen? :)

Jess

I was actually about to complain about the new `dc' not exiting after 
evaluating a '-e' expression, without an explicit 'q'. But then I noticed the 
"DC_EXPR_EXIT" envvar, which restores the desired behavior. That lead me to 
discover "DC_ENV_ARGS" and, correspondingly, "BC_ENV_ARGS"; that last one would 
be helpful here.

Thanks,

Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r363091 - in head/contrib/bc: . include manuals src tests tests/bc

[Ravi Pokala]

-Original Message-
From:  on behalf of Stefan Eßer 

Date: 2020-07-30, Thursday at 09:55
To: Jessica Clarke , Ravi Pokala 
Cc: Baptiste Daroussin , Stefan Eßer , 
src-committers , , 

Subject: Re: svn commit: r363091 - in head/contrib/bc: . include manuals src 
tests tests/bc

Am 30.07.20 um 18:45 schrieb Jessica Clarke:
> On 30 Jul 2020, at 17:40, Ravi Pokala  wrote:
>>
>> -Original Message-
>> From:  on behalf of Jessica Clarke 

>> Date: 2020-07-30, Thursday at 09:35
>> To: Baptiste Daroussin 
>> Cc: Stefan Eßer , src-committers 
, , 

>> Subject: Re: svn commit: r363091 - in head/contrib/bc: . include manuals 
src tests tests/bc
>>
>>On 30 Jul 2020, at 17:31, Baptiste Daroussin  wrote:
>>> On Thu, Jul 30, 2020 at 05:28:19PM +0100, Jessica Clarke wrote:
>>>> On 30 Jul 2020, at 17:20, Baptiste Daroussin  wrote:
>>>>> On Sat, Jul 11, 2020 at 07:33:19AM +, Stefan Eßer wrote:
>>>>>> Author: se
>>>>>> Date: Sat Jul 11 07:33:18 2020
>>>>>> New Revision: 363091
>>>>>> URL: https://svnweb.freebsd.org/changeset/base/363091
>>>>>>
>>>>>> Log:
>>>>>> Update to version 3.1.3
>>>>>>
>>>>> Jumping on that commit, since the switch from our previous bc.
>>>>>
>>>>> The output of the interactive bc has changed, the previous version 
had a clean
>>>>> UI, the new version "pollutes" the output with plenty of lines about 
the
>>>>> copyright:
>>>>>
>>>>> 
>>>>> Copyright (c) 2018-2020 Gavin D. Howard and contributors
>>>>> Report bugs at: https://git.yzena.com/gavin/bc
>>>>>
>>>>> This is free software with ABSOLUTELY NO WARRANTY.
>>>>> 
>>>>>
>>>>> Imagine if all programs where doing that, it would be painful, do you 
think
>>>>> upstream can be convinced to remove those lines?
>>>>>
>>>>> I no the GNU version also has the same polluted output which was one 
of the
>>>>> reason I was happy with out previous version of bc.
>>>>
>>>> By default both will print such a banner if and only if being called
>>>> interactively. You can disable the banner explicitly with -q/--quiet
>>>> for both GNU bc and this bc. I agree it's a bit noisy and would be
>>>> nicer to not have that printed, but it's not without precedent for
>>>> REPL-like things.
>>>
>>> Yes it is not without precedent for REPL-like things, still I dislike 
this and
>>> would be happy to get bc interactive be as nice as the previous one we 
had :)
>>>
>>> If not I will deal with it and just yell internally each time I run it 
:D
>>
>>`alias bc='bc -q'` / `alias bc bc -q` and preserve your inner zen? :)
>>
>>Jess
>>
>> I was actually about to complain about the new `dc' not exiting after 
evaluating a '-e' expression, without an explicit 'q'. But then I noticed the 
"DC_EXPR_EXIT" envvar, which restores the desired behavior. That lead me to 
discover "DC_ENV_ARGS" and, correspondingly, "BC_ENV_ARGS"; that last one would 
be helpful here.
> 
> That does feel like the wrong default; even GNU dc doesn't do that, and
> the principle of least surprise would suggest exiting is the right
> thing to do. It's also unlikely you want to evaluate something and then
> use it interactively.

Interesting observation - I've got to admit that I hardly ever use dc
(despite being the owner of a collection of HP UPN calculators ;-) ).

Ironically, I couldn't wrap my head around HP RPN calculators in the '90s, so I 
used a TI-85 or TI-89 instead. Now, I do all my non-trivial math using RPN in 
`dc'. :-)

-Ravi

I'll forward this to the author of this bc/dc and I'm sure he will
offer a patched version (unless there are strong reasons for the
current behavior, e.g. compatibility with another dc ...)

Regards, STefan


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r363733 - head/usr.sbin/bhyve

[Ravi Pokala]

-Original Message-
From:  on behalf of Peter Grehan 

Date: 2020-07-31, Friday at 05:10
To: , , 

Subject: svn commit: r363733 - head/usr.sbin/bhyve

Author: grehan
Date: Fri Jul 31 12:10:28 2020
New Revision: 363733
URL: https://svnweb.freebsd.org/changeset/base/363733

Log:
  Replace magic numbers in Identify page register 0 with ATA definitions.

  No functional change. Verified with objdump output before/after.

  Requested by: rpokala
  Reviewed by:  rpokala
  MFC after:3 weeks

Thanks! :-)

-Ravi (rpokala@)

Modified:
  head/usr.sbin/bhyve/pci_ahci.c

Modified: head/usr.sbin/bhyve/pci_ahci.c

==
--- head/usr.sbin/bhyve/pci_ahci.c  Fri Jul 31 12:09:59 2020
(r363732)
+++ head/usr.sbin/bhyve/pci_ahci.c  Fri Jul 31 12:10:28 2020
(r363733)
@@ -999,7 +999,8 @@ ata_identify_init(struct ahci_port* p, int atapi)
struct ata_params* ata_ident = &p->ata_ident;

if (atapi) {
-   ata_ident->config = (2 << 14 | 5 << 8 | 1 << 7 | 2 << 5);
+   ata_ident->config = ATA_PROTO_ATAPI | ATA_ATAPI_TYPE_CDROM |
+   ATA_ATAPI_REMOVABLE | ATA_DRQ_FAST;
ata_ident->capabilities1 = ATA_SUPPORT_LBA |
ATA_SUPPORT_DMA;
ata_ident->capabilities2 = (1 << 14 | 1);


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r364071 - head/sys/kern

[Ravi Pokala]

-Original Message-
From:  on behalf of Mateusz Guzik 

Date: 2020-08-10, Monday at 03:40
To: , , 

Subject: svn commit: r364071 - head/sys/kern

Author: mjg
Date: Mon Aug 10 10:40:14 2020
New Revision: 364071
URL: https://svnweb.freebsd.org/changeset/base/364071

Log:
  cache: strlcpy -> memcpy

But why?

-Ravi (rpokala@)

Modified:
  head/sys/kern/vfs_cache.c

Modified: head/sys/kern/vfs_cache.c

==
--- head/sys/kern/vfs_cache.c   Mon Aug 10 10:37:16 2020
(r364070)
+++ head/sys/kern/vfs_cache.c   Mon Aug 10 10:40:14 2020
(r364071)
@@ -1934,7 +1934,8 @@ cache_enter_time(struct vnode *dvp, struct vnode *vp, 
}
len = ncp->nc_nlen = cnp->cn_namelen;
hash = cache_get_hash(cnp->cn_nameptr, len, dvp);
-   strlcpy(ncp->nc_name, cnp->cn_nameptr, len + 1);
+   memcpy(ncp->nc_name, cnp->cn_nameptr, len);
+   ncp->nc_name[len] = '\0';
cache_enter_lock(&cel, dvp, vp, hash);

/*


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r364076 - head/sys/fs/devfs

[Ravi Pokala]

-Original Message-
From:  on behalf of Mateusz Guzik 

Date: 2020-08-10, Monday at 04:46
To: , , 

Subject: svn commit: r364076 - head/sys/fs/devfs

Author: mjg
Date: Mon Aug 10 11:46:39 2020
New Revision: 364076
URL: https://svnweb.freebsd.org/changeset/base/364076

Log:
  devfs: bool -> int

  Fixes buildworld after r364069

It was returning the result of a "!=" test; is that not a bool?

-Ravi (rpokala@)

Modified:
  head/sys/fs/devfs/devfs.h
  head/sys/fs/devfs/devfs_devs.c

Modified: head/sys/fs/devfs/devfs.h

==
--- head/sys/fs/devfs/devfs.h   Mon Aug 10 10:58:43 2020
(r364075)
+++ head/sys/fs/devfs/devfs.h   Mon Aug 10 11:46:39 2020
(r364076)
@@ -192,7 +192,7 @@ char*devfs_fqpn(char *, struct devfs_mount *, 
struct 
struct componentname *);
 void   devfs_delete(struct devfs_mount *, struct devfs_dirent *, int);
 void   devfs_dirent_free(struct devfs_dirent *);
-bool   devfs_populate_needed(struct devfs_mount *dm);
+intdevfs_populate_needed(struct devfs_mount *dm);
 void   devfs_populate(struct devfs_mount *);
 void   devfs_cleanup(struct devfs_mount *);
 void   devfs_unmount_final(struct devfs_mount *);

Modified: head/sys/fs/devfs/devfs_devs.c

==
--- head/sys/fs/devfs/devfs_devs.c  Mon Aug 10 10:58:43 2020
(r364075)
+++ head/sys/fs/devfs/devfs_devs.c  Mon Aug 10 11:46:39 2020
(r364076)
@@ -659,7 +659,7 @@ devfs_populate_loop(struct devfs_mount *dm, int cleanu
return (0);
 }

-bool
+int
 devfs_populate_needed(struct devfs_mount *dm)
 {



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r366686 - head/sys/ofed/drivers/infiniband/ulp/ipoib

[Ravi Pokala]

Author: rpokala
Date: Tue Oct 13 20:41:51 2020
New Revision: 366686
URL: https://svnweb.freebsd.org/changeset/base/366686

Log:
  Allow IP over IB to work with multiple FIBs.
  
  Call M_SETFIB() to make sure the IPoIB packet is directed to the correct
  interface-specific FIB.
  
  This was sufficient to allow general-purpose routing using the default FIB,
  and a separate FIB for routing between IPoIB on ib0 and IPoEthernet on mce0.
  
  Reviewed by:  hselasky
  Obtained from:Anmol Kumar 
  MFC after:1 week
  Sponsored by: Panasas
  Differential Revision:https://reviews.freebsd.org/D25239

Modified:
  head/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c

Modified: head/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c
==
--- head/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c Tue Oct 13 
20:40:09 2020(r366685)
+++ head/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c Tue Oct 13 
20:41:51 2020(r366686)
@@ -1617,6 +1617,8 @@ ipoib_demux(struct ifnet *ifp, struct mbuf *m, u_short
m_freem(m);
return;
}
+   /* Direct packet to correct FIB based on interface config */
+   M_SETFIB(m, ifp->if_fib);
/*
 * Dispatch frame to upper layer.
 */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r366686 - head/sys/ofed/drivers/infiniband/ulp/ipoib

[Ravi Pokala]

-Original Message-
From:  on behalf of Ravi Pokala 

Date: 2020-10-13, Tuesday at 13:41
To: , , 

Subject: svn commit: r366686 - head/sys/ofed/drivers/infiniband/ulp/ipoib

Author: rpokala
Date: Tue Oct 13 20:41:51 2020
New Revision: 366686
URL: https://svnweb.freebsd.org/changeset/base/366686

Log:
  Allow IP over IB to work with multiple FIBs.

  Call M_SETFIB() to make sure the IPoIB packet is directed to the correct
  interface-specific FIB.

  This was sufficient to allow general-purpose routing using the default 
FIB,
  and a separate FIB for routing between IPoIB on ib0 and IPoEthernet on 
mce0.

  Reviewed by:  hselasky
  Obtained from:Anmol Kumar 
  MFC after:1 week
  Sponsored by: Panasas
  Differential Revision:https://reviews.freebsd.org/D25239

That's actually https://reviews.freebsd.org/D26733

-Ravi (rpokala@)

Modified:
  head/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c

Modified: head/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c

==
--- head/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c Tue Oct 13 
20:40:09 2020(r366685)
+++ head/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c Tue Oct 13 
20:41:51 2020(r366686)
@@ -1617,6 +1617,8 @@ ipoib_demux(struct ifnet *ifp, struct mbuf *m, u_short
m_freem(m);
return;
}
+   /* Direct packet to correct FIB based on interface config */
+   M_SETFIB(m, ifp->if_fib);
/*
 * Dispatch frame to upper layer.
 */


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r367130 - in head/sys: kern sys

[Ravi Pokala]

Hi Mateusz,

You define NAMEI_DBG_HADSTARTDIR, you check for it being set, but it doesn't 
look like you actually set it anywhere...?

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Mateusz Guzik 

Date: 2020-10-29, Thursday at 05:56
To: , , 

Subject: svn commit: r367130 - in head/sys: kern sys

Author: mjg
Date: Thu Oct 29 12:56:02 2020
New Revision: 367130
URL: https://svnweb.freebsd.org/changeset/base/367130

Log:
  vfs: add NDREINIT to facilitate repeated namei calls

  struct nameidata mixes caller arguments, internal state and output, which
  can be quite error prone.

  Recent addition of valdiating ni_resflags uncovered a caller which could
  repeatedly call namei, effectively operating on partially populated state.

  Add bare minimium validation this does not happen. The real fix would
  decouple aforementioned state.

  Reported by:  pho
  Tested by:pho (different variant)

Modified:
  head/sys/kern/vfs_lookup.c
  head/sys/kern/vfs_vnops.c
  head/sys/sys/namei.h

Modified: head/sys/kern/vfs_lookup.c

==
--- head/sys/kern/vfs_lookup.c  Thu Oct 29 11:19:47 2020
(r367129)
+++ head/sys/kern/vfs_lookup.c  Thu Oct 29 12:56:02 2020
(r367130)
@@ -502,6 +502,11 @@ namei(struct nameidata *ndp)
cnp = &ndp->ni_cnd;
td = cnp->cn_thread;
 #ifdef INVARIANTS
+   KASSERT((ndp->ni_debugflags & NAMEI_DBG_CALLED) == 0,
+   ("%s: repeated call to namei without NDREINIT", __func__));
+   KASSERT(ndp->ni_debugflags == NAMEI_DBG_INITED,
+   ("%s: bad debugflags %d", __func__, ndp->ni_debugflags));
+   ndp->ni_debugflags |= NAMEI_DBG_CALLED;
/*
 * For NDVALIDATE.
 *

Modified: head/sys/kern/vfs_vnops.c

==
--- head/sys/kern/vfs_vnops.c   Thu Oct 29 11:19:47 2020
(r367129)
+++ head/sys/kern/vfs_vnops.c   Thu Oct 29 12:56:02 2020
(r367130)
@@ -259,6 +259,7 @@ restart:
if ((error = vn_start_write(NULL, &mp,
V_XSLEEP | PCATCH)) != 0)
return (error);
+   NDREINIT(ndp);
goto restart;
}
if ((vn_open_flags & VN_OPEN_NAMECACHE) != 0)

Modified: head/sys/sys/namei.h

==
--- head/sys/sys/namei.hThu Oct 29 11:19:47 2020(r367129)
+++ head/sys/sys/namei.hThu Oct 29 12:56:02 2020(r367130)
@@ -95,11 +95,15 @@ struct nameidata {
 */
u_int   ni_resflags;
/*
+* Debug for validating API use by the callers.
+*/
+   u_short ni_debugflags;
+   /*
 * Shared between namei and lookup/commit routines.
 */
+   u_short ni_loopcnt; /* count of symlinks encountered */
size_t  ni_pathlen; /* remaining chars in path */
char*ni_next;   /* next location in pathname */
-   u_int   ni_loopcnt; /* count of symlinks encountered */
/*
 * Lookup parameters: this structure describes the subset of
 * information from the nameidata structure that is passed
@@ -122,7 +126,15 @@ intcache_fplookup(struct nameidata *ndp, enum 
cache_f
  *
  * If modifying the list make sure to check whether NDVALIDATE needs 
updating.
  */
+
 /*
+ * Debug.
+ */
+#defineNAMEI_DBG_INITED0x0001
+#defineNAMEI_DBG_CALLED0x0002
+#defineNAMEI_DBG_HADSTARTDIR   0x0004
+
+/*
  * namei operational modifier flags, stored in ni_cnd.flags
  */
 #defineNC_NOMAKEENTRY  0x0001  /* name must not be added to cache */
@@ -215,8 +227,18 @@ intcache_fplookup(struct nameidata *ndp, enum 
cache_f
  */
 #ifdef INVARIANTS
 #define NDINIT_PREFILL(arg)memset(arg, 0xff, sizeof(*arg))
+#define NDINIT_DBG(arg){ (arg)->ni_debugflags = 
NAMEI_DBG_INITED; }
+#define NDREINIT_DBG(arg)  {   
\
+   if (((arg)->ni_debugflags & NAMEI_DBG_INITED) == 0) 
\
+   panic("namei data not inited"); 
\
+   if (((arg)->ni_debugflags & NAMEI_DBG_HADSTARTDIR) != 0)
\
+   panic("NDREINIT on namei data with NAMEI_DBG_HADSTARTDIR"); 
\
+   (arg)->ni_debugflags = NAMEI_DBG_INITED;
\
+}
 #else
 #define NDINIT_PREFILL(arg)do { } while (0)
+#define NDINIT_DBG(arg)do { } whi

Re: svn commit: r367651 - head/usr.sbin/bhyve

[Ravi Pokala]

>+#define FIRMWARE_RELEASE_DATE "11/10/2020"

Might I suggest "2020-11-10", as sorting, logic, ${DEITY}, and ISO-8601 demand? 
;-)

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Rebecca Cran 

Date: 2020-11-13, Friday at 11:47
To: , , 

Subject: svn commit: r367651 - head/usr.sbin/bhyve

Author: bcran
Date: Fri Nov 13 19:47:16 2020
New Revision: 367651
URL: https://svnweb.freebsd.org/changeset/base/367651

Log:
  bhyve: update smbiostbl.c to bump the version and release date

  Since lots of work has been done on bhyve since 2014, increase the version
  to 13.0 to match 13-CURRENT, and update the release date.

  Reviewed by:  grehan
  Differential Revision:https://reviews.freebsd.org/D27147

Modified:
  head/usr.sbin/bhyve/smbiostbl.c

Modified: head/usr.sbin/bhyve/smbiostbl.c

==
--- head/usr.sbin/bhyve/smbiostbl.c Fri Nov 13 19:22:53 2020
(r367650)
+++ head/usr.sbin/bhyve/smbiostbl.c Fri Nov 13 19:47:16 2020
(r367651)
@@ -51,6 +51,9 @@ __FBSDID("$FreeBSD$");

 #define SMBIOS_BASE0xF1000

+#define FIRMWARE_VERSION   "13.0"
+#define FIRMWARE_RELEASE_DATE  "11/10/2020"
+
 /* BHYVE_ACPI_BASE - SMBIOS_BASE) */
 #defineSMBIOS_MAX_LENGTH   (0xF2400 - 0xF1000)

@@ -323,9 +326,9 @@ struct smbios_table_type0 smbios_type0_template = {
 };

 const char *smbios_type0_strings[] = {
-   "BHYVE",/* vendor string */
-   "1.00", /* bios version string */
-   "03/14/2014",   /* bios release date string */
+   "BHYVE",/* vendor string */
+   FIRMWARE_VERSION,   /* bios version string */
+   FIRMWARE_RELEASE_DATE,  /* bios release date string */
NULL
 };



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r367651 - head/usr.sbin/bhyve

[Ravi Pokala]

-Original Message-
From:  on behalf of Jessica Clarke 

Date: 2020-11-13, Friday at 16:53
To: Ravi Pokala 
Cc: Rebecca Cran , , 
, 
Subject: Re: svn commit: r367651 - head/usr.sbin/bhyve

On 14 Nov 2020, at 00:47, Ravi Pokala  wrote:
> 
>>   +#define FIRMWARE_RELEASE_DATE "11/10/2020"
> 
> Might I suggest "2020-11-10", as sorting, logic, ${DEITY}, and ISO-8601 
demand? ;-)

Alas that is a "feature" of the specification:

  String number of the BIOS release date. The date string, if supplied,
  is in either mm/dd/yy or mm/dd/ format. If the year portion of the
  string is two digits, the year is assumed to be 19yy.

  NOTE: The mm/dd/ format is required for SMBIOS version 2.3 and
  later.

(SMBIOS Specification version 3.4.0c)



Yeah, it occurred to me that it might be something like that shortly after I 
hit "send". :-p

It might be worth putting a comment in so people don't accidentally
change it to the wrong thing in future though, given it's currently
ambiguous otherwise.

That would be appreciated.

Thanks,

Ravi (rpokala@)

Jess



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r368163 - in head: sbin/ifconfig sys/dev/if_wg sys/dev/if_wg/include sys/dev/if_wg/include/crypto sys/dev/if_wg/include/sys sys/dev/if_wg/include/zinc sys/dev/if_wg/module sys/dev/if_w

[Ravi Pokala]

-Original Message-
From:  on behalf of Ian Lepore 

Date: 2020-11-29, Sunday at 16:26
To: Shawn Webb , Matt Macy 
Cc: , , 

Subject: Re: svn commit: r368163 - in head: sbin/ifconfig sys/dev/if_wg 
sys/dev/if_wg/include sys/dev/if_wg/include/crypto sys/dev/if_wg/include/sys 
sys/dev/if_wg/include/zinc sys/dev/if_wg/module sys/dev/if_wg...

On Sun, 2020-11-29 at 19:20 -0500, Shawn Webb wrote:
> On Sun, Nov 29, 2020 at 07:38:04PM +, Matt Macy wrote:
> > Author: mmacy
> > Date: Sun Nov 29 19:38:03 2020
> > New Revision: 368163
> > URL: https://svnweb.freebsd.org/changeset/base/368163
> > 
> > Log:
> >   Import kernel WireGuard support
> >   
> >   Data path largely shared with the OpenBSD implementation by
> >   Matt Dunwoodie 
> >   
> >   Reviewed by:  gre...@freebsd.org
> >   MFC after:1 month
> >   Sponsored by: Rubicon LLC, (Netgate)
> >   Differential Revision:https://reviews.freebsd.org/D26137
> 
> RELNOTES: yes?
> 
> Thanks,
> 

Or maybe an entry in src/RELNOTES, preferably one that (unlike the
commit message) has at least some tiny shred of a clue about what
Wireguard is.

-- Ian

In addition to an update to RELNOTES, a manpage would also be greatly 
appreciated.

-Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r368820 - head

[Ravi Pokala]

-Original Message-
From:  on behalf of "Hartmann, O." 

Organization: walstatt.org
Date: 2020-12-24, Thursday at 13:34
To: "Hartmann, O." 
Cc: Li-Wen Hsu , , 
, 
Subject: Re: svn commit: r368820 - head

On Sun, 20 Dec 2020 15:46:12 +0100
"Hartmann, O."  wrote:

According to the status of the wiki refered to by 
https://wiki.freebsd.org/git, most of
the transition from svn to git has been done.
According to the recent logs reported at https://cgit.freebsd.org/src/, the 
recent
commits for "main" (I assume this is CURRENT?) are done 35 minutes ago, 
commit
322a188d45f17457f0de00a78c77228751dff03c.
The last message on this list is still this one I'm replying to.

I've been getting mail from git, sent to src-committers@, dev-commits-src-all@, 
and dev-commits-src-main@ (-HEAD) or dev-commits-src-branches@ (stable). The 
first such message was:


From:  on behalf of Li-Wen Hsu 

Date: 2020-12-22, Tuesday at 20:29
To: , , 

Subject: git: 5ef5f51d2bef - Mark the repository has been converted to Git

The branch main has been updated by lwhsu:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=5ef5f51d2bef80b0ede9b10ad5b0e9440b60518c

commit 5ef5f51d2bef80b0ede9b10ad5b0e9440b60518c
Author: Li-Wen Hsu 
AuthorDate: 2020-12-23 04:27:27 +
Commit: Li-Wen Hsu 
CommitDate: 2020-12-23 04:27:27 +

Mark the repository has been converted to Git

This is the first Git commit to src.

Sponsored by:   The FreeBSD Foundation
---
README| 2 --
README.md | 2 --
2 files changed, 4 deletions(-)

diff --git a/README b/README
index eb38522b1357..aad363baf9ea 100644
--- a/README
+++ b/README
@@ -1,5 +1,3 @@
-This repository is being converted from Subversion to Git.
-
This is the top level of the FreeBSD source directory.  This file
was last revised on:
$FreeBSD$
diff --git a/README.md b/README.md
index 0eba39438e46..72bd634cd813 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,3 @@
-This repository is being converted from Subversion to Git.
-
FreeBSD Source:
---
This is the top level of the FreeBSD source directory.  This file


-Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r355188 - in head/riscv: . sifive

[Ravi Pokala]

Hi Manu,

This creates a top-level "riscv" directory, but there are no other top-level 
${TARGET} directories.

It looks like other *.dts and *.dtsi files live in either

sys/dts/${TARGET}

or

sys/gnu/dts/${TARGET}/(vendor/)?

So perhaps these should be moved to one of those directories, as appropriate?

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Emmanuel Vadot 

Date: 2019-11-28, Thursday at 11:38
To: , , 

Subject: svn commit: r355188 - in head/riscv: . sifive

Author: manu
Date: Thu Nov 28 19:38:57 2019
New Revision: 355188
URL: https://svnweb.freebsd.org/changeset/base/355188

Log:
  Import riscv DTS files
  
  Requested by: mhorne

Added:
  head/riscv/
 - copied from r355184, vendor/device-tree/dist/src/riscv/
Replaced:
  head/riscv/sifive/fu540-c000.dtsi
 - copied unchanged from r355185, 
vendor/device-tree/dist/src/riscv/sifive/fu540-c000.dtsi
  head/riscv/sifive/hifive-unleashed-a00.dts
 - copied unchanged from r355185, 
vendor/device-tree/dist/src/riscv/sifive/hifive-unleashed-a00.dts

Copied: head/riscv/sifive/fu540-c000.dtsi (from r355185, 
vendor/device-tree/dist/src/riscv/sifive/fu540-c000.dtsi)

==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/riscv/sifive/fu540-c000.dtsi   Thu Nov 28 19:38:57 2019
(r355188, copy of r355185, 
vendor/device-tree/dist/src/riscv/sifive/fu540-c000.dtsi)
@@ -0,0 +1,251 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Copyright (c) 2018-2019 SiFive, Inc */
+
+/dts-v1/;
+
+#include 
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   compatible = "sifive,fu540-c000", "sifive,fu540";
+
+   aliases {
+   serial0 = &uart0;
+   serial1 = &uart1;
+   ethernet0 = ð0;
+   };
+
+   chosen {
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   cpu0: cpu@0 {
+   compatible = "sifive,e51", "sifive,rocket0", "riscv";
+   device_type = "cpu";
+   i-cache-block-size = <64>;
+   i-cache-sets = <128>;
+   i-cache-size = <16384>;
+   reg = <0>;
+   riscv,isa = "rv64imac";
+   status = "disabled";
+   cpu0_intc: interrupt-controller {
+   #interrupt-cells = <1>;
+   compatible = "riscv,cpu-intc";
+   interrupt-controller;
+   };
+   };
+   cpu1: cpu@1 {
+   compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
+   d-cache-block-size = <64>;
+   d-cache-sets = <64>;
+   d-cache-size = <32768>;
+   d-tlb-sets = <1>;
+   d-tlb-size = <32>;
+   device_type = "cpu";
+   i-cache-block-size = <64>;
+   i-cache-sets = <64>;
+   i-cache-size = <32768>;
+   i-tlb-sets = <1>;
+   i-tlb-size = <32>;
+   mmu-type = "riscv,sv39";
+   reg = <1>;
+   riscv,isa = "rv64imafdc";
+   tlb-split;
+   cpu1_intc: interrupt-controller {
+   #interrupt-cells = <1>;
+   compatible = "riscv,cpu-intc";
+   interrupt-controller;
+   };
+   };
+   cpu2: cpu@2 {
+   compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
+   d-cache-block-size = <64>;
+   d-cache-sets = <64>;
+   d-cache-size = <32768>;
+   d-tlb-sets = <1>;
+   d-tlb-size = <32>;
+   device_type = "cpu";
+   i-cache-block-size = <64>;
+   i-cache-sets = <64>;
+   i-cache-size = <32768>;
+   i-tlb-sets = <1>;
+   i-tlb-size = <32>;
+   mmu-type = "riscv,sv39";
+   reg = <2>;
+   riscv,isa = "rv64imafdc";
+   tlb-split;
+   cpu2_intc: interrupt-controller {
+   #interrupt-cells = <1>;
+   compatible = "riscv,cpu-intc";
+   interrupt-controller;
+   };
+   };
+   cpu3: cpu@3 {
+ 

Re: svn commit: r355188 - in head/riscv: . sifive

[Ravi Pokala]

-Original Message-
From: Emmanuel Vadot 
Date: 2019-12-03, Tuesday at 01:13
To: Ravi Pokala 
Cc: Emmanuel Vadot , , 
, 
Subject: Re: svn commit: r355188 - in head/riscv: . sifive

On Mon, 02 Dec 2019 13:36:06 -0800
Ravi Pokala  wrote:

> Hi Manu,
> 
> This creates a top-level "riscv" directory, but there are no other 
top-level ${TARGET} directories.
> 
> It looks like other *.dts and *.dtsi files live in either
> 
> sys/dts/${TARGET}
> 
> or
> 
> sys/gnu/dts/${TARGET}/(vendor/)?
> 
> So perhaps these should be moved to one of those directories, as 
appropriate?
> 
> Thanks,
> 
> Ravi (rpokala@)

 Thanks, I don't know how I didn't see that ... fixed with revert +
r355324.

Thank you!

-Ravi (rpokala@)

> ?-Original Message-
> From:  on behalf of Emmanuel Vadot 

> Date: 2019-11-28, Thursday at 11:38
> To: , , 

> Subject: svn commit: r355188 - in head/riscv: . sifive
> 
> Author: manu
> Date: Thu Nov 28 19:38:57 2019
> New Revision: 355188
> URL: https://svnweb.freebsd.org/changeset/base/355188
> 
> Log:
>   Import riscv DTS files
>   
>   Requested by: mhorne
> 
> Added:
>   head/riscv/
>  - copied from r355184, vendor/device-tree/dist/src/riscv/
> Replaced:
>   head/riscv/sifive/fu540-c000.dtsi
>  - copied unchanged from r355185, 
vendor/device-tree/dist/src/riscv/sifive/fu540-c000.dtsi
>   head/riscv/sifive/hifive-unleashed-a00.dts
>  - copied unchanged from r355185, 
vendor/device-tree/dist/src/riscv/sifive/hifive-unleashed-a00.dts
> 
> Copied: head/riscv/sifive/fu540-c000.dtsi (from r355185, 
vendor/device-tree/dist/src/riscv/sifive/fu540-c000.dtsi)
> 
==
> --- /dev/null 00:00:00 1970   (empty, because file is newly added)
> +++ head/riscv/sifive/fu540-c000.dtsi Thu Nov 28 19:38:57 2019
(r355188, copy of r355185, 
vendor/device-tree/dist/src/riscv/sifive/fu540-c000.dtsi)
> @@ -0,0 +1,251 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/* Copyright (c) 2018-2019 SiFive, Inc */
> +
> +/dts-v1/;
> +
> +#include 
> +
> +/ {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + compatible = "sifive,fu540-c000", "sifive,fu540";
> +
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + ethernet0 = ð0;
> + };
> +
> + chosen {
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu0: cpu@0 {
> + compatible = "sifive,e51", "sifive,rocket0", 
"riscv";
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <128>;
> + i-cache-size = <16384>;
> + reg = <0>;
> + riscv,isa = "rv64imac";
> + status = "disabled";
> + cpu0_intc: interrupt-controller {
> + #interrupt-cells = <1>;
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + };
> + };
> + cpu1: cpu@1 {
> + compatible = "sifive,u54-mc", "sifive,rocket0", 
"riscv";
> + d-cache-block-size = <64>;
> + d-cache-sets = <64>;
> + d-cache-size = <32768>;
> + d-tlb-sets = <1>;
> + d-tlb-size = <32>;
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <64>;
> + i-cache-size = <32768>;
>

Re: svn commit: r355412 - head/sys/geom

[Ravi Pokala]

-Original Message-
From:  on behalf of Alexander Motin 

Date: 2019-12-04, Wednesday at 20:52
To: , , 

Subject: svn commit: r355412 - head/sys/geom

Author: mav
Date: Thu Dec  5 04:52:19 2019
New Revision: 355412
URL: https://svnweb.freebsd.org/changeset/base/355412

Log:
  Wrap g_trace() into a macro to avoid unneeded calls.
  
  In most cases with debug disabled this function does nothing, but argument
  passing and the call still cost measurable time due to cache misses, etc.

Hi Alexander,

I'm having trouble understanding this change, on a few levels.

- Why did you add parentheses around the function declaration and definition?
- How can that function with that name co-exist with a macro of the same name?
- Isn't the "g_debugflags" test in geom_dump.c:g_trace() now redundant?
- Why not simply convert geom_dump.c:g_trace() into a 'static inline' in 
geom.h, and not have to bother with the macro at all?

What am I missing?

Thanks,

Ravi (rpokala@)

  MFC after:2 weeks
  Sponsored by: iXsystems, Inc.

Modified:
  head/sys/geom/geom.h
  head/sys/geom/geom_dump.c

Modified: head/sys/geom/geom.h

==
--- head/sys/geom/geom.hThu Dec  5 04:18:22 2019(r355411)
+++ head/sys/geom/geom.hThu Dec  5 04:52:19 2019(r355412)
@@ -255,11 +255,15 @@ void g_dev_physpath_changed(void);
 struct g_provider *g_dev_getprovider(struct cdev *dev);
 
 /* geom_dump.c */
-void g_trace(int level, const char *, ...);
+void (g_trace)(int level, const char *, ...) __printflike(2, 3);
 #  define G_T_TOPOLOGY 1
 #  define G_T_BIO  2
 #  define G_T_ACCESS   4
-
+extern int g_debugflags;
+#defineg_trace(level, fmt, ...) do {   \
+   if (__predict_false(g_debugflags & (level)))\
+   (g_trace)(level, fmt, ## __VA_ARGS__);  \
+} while (0)
 
 /* geom_event.c */
 typedef void g_event_t(void *, int flag);

Modified: head/sys/geom/geom_dump.c

==
--- head/sys/geom/geom_dump.c   Thu Dec  5 04:18:22 2019
(r355411)
+++ head/sys/geom/geom_dump.c   Thu Dec  5 04:52:19 2019
(r355412)
@@ -319,7 +319,7 @@ g_confxml(void *p, int flag)
 }
 
 void
-g_trace(int level, const char *fmt, ...)
+(g_trace)(int level, const char *fmt, ...)
 {
va_list ap;
 



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r355727 - in head: share/man/man9 sys/arm/broadcom/bcm2835 sys/arm/freescale/imx sys/arm/mv sys/arm/ti sys/dev/glxiic sys/dev/ichsmb sys/dev/ow sys/kern sys/sys

[Ravi Pokala]

Hi Warner,

This change takes a bunch of cases of

> config_intrhook_oneshot((ich_func_t)bus_generic_attach, dev);
> return (0)

And replaces them with a *mix* of:

> return (bus_delayed_attach_children(dev));

and

> bus_delayed_attach_children(dev);
> return (0)

Why the two different idioms?

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Warner Losh 

Date: 2019-12-13, Friday at 11:39
To: , , 

Subject: svn commit: r355727 - in head: share/man/man9 sys/arm/broadcom/bcm2835 
sys/arm/freescale/imx sys/arm/mv sys/arm/ti sys/dev/glxiic sys/dev/ichsmb 
sys/dev/ow sys/kern sys/sys

Author: imp
Date: Fri Dec 13 19:39:33 2019
New Revision: 355727
URL: https://svnweb.freebsd.org/changeset/base/355727

Log:
  Create new wrapper function: bus_delayed_attach_children()
  
  Delay the attachment of children, when requested, until after interrutps 
are
  running. This is often needed to allow children to run transactions on 
i2c or
  spi busses. It's a common enough idiom that it will be useful to have its 
own
  wrapper.
  
  Reviewed by: ian
  Differential Revision: https://reviews.freebsd.org/D21465

Added:
  head/share/man/man9/bus_delayed_attach_children.9   (contents, props 
changed)
Modified:
  head/share/man/man9/Makefile
  head/sys/arm/broadcom/bcm2835/bcm2835_bsc.c
  head/sys/arm/freescale/imx/imx_i2c.c
  head/sys/arm/freescale/imx/imx_spi.c
  head/sys/arm/mv/a37x0_spi.c
  head/sys/arm/mv/mv_spi.c
  head/sys/arm/ti/ti_i2c.c
  head/sys/dev/glxiic/glxiic.c
  head/sys/dev/ichsmb/ichsmb.c
  head/sys/dev/ow/owc_gpiobus.c
  head/sys/kern/subr_bus.c
  head/sys/sys/bus.h

Modified: head/share/man/man9/Makefile

==
--- head/share/man/man9/MakefileFri Dec 13 19:27:51 2019
(r355726)
+++ head/share/man/man9/MakefileFri Dec 13 19:39:33 2019
(r355727)
@@ -34,6 +34,7 @@ MAN=  accept_filter.9 \
BUS_CHILD_DELETED.9 \
BUS_CHILD_DETACHED.9 \
BUS_CONFIG_INTR.9 \
+   bus_delayed_attach_children.9 \
BUS_DESCRIBE_INTR.9 \
bus_dma.9 \
bus_generic_attach.9 \

Added: head/share/man/man9/bus_delayed_attach_children.9

==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/share/man/man9/bus_delayed_attach_children.9   Fri Dec 13 
19:39:33 2019(r355727)
@@ -0,0 +1,55 @@
+.\" -*- nroff -*-
+.\"
+.\" Copyright (c) 2019 M. Warner Losh
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS 
OR
+.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 
WARRANTIES
+.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+.\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT,
+.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 
BUT
+.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF 
USE,
+.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
OF
+.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+.\"
+.\" $FreeBSD$
+.\"
+.Dd August 29, 2019
+.Dt BUS_DELAYED_ATTACH_CHILDREN 9
+.Os
+.Sh NAME
+.Nm bus_delayed_attach_children
+.Nd "request that the children be attached when interrupts are enabled"
+.Sh SYNOPSIS
+.In sys/param.h
+.In sys/bus.h
+.Pp
+.Ft int
+.Fn bus_delayed_attach_children "device_t dev"
+.Sh DESCRIPTION
+The
+.Fn bus_delayed_attach_children
+function requests that the children of this device
+be attached when interrupts are running.
+If interrupts are currently running, this happens immediately.
+If interrupts aren't yet running, this happens after interrupts are 
enabled, but
+before the system mounts root.
+.Sh RETURN VALUES
+A zero return value indicates success.
+.Sh SEE ALSO
+.Xr bus 9 ,
+.Xr device 9 ,
+.Xr driver 9
+.Sh AUTHORS

Re: svn commit: r355735 - in head/sys: arm/broadcom/bcm2835 arm/mv dev/ow

[Ravi Pokala]

Thanks!

-Ravi (rpokala@)

-Original Message-
From:  on behalf of Warner Losh 

Date: 2019-12-13, Friday at 13:39
To: , , 

Subject: svn commit: r355735 - in head/sys: arm/broadcom/bcm2835 arm/mv dev/ow

Author: imp
Date: Fri Dec 13 21:39:20 2019
New Revision: 355735
URL: https://svnweb.freebsd.org/changeset/base/355735

Log:
  Be consistent about checking return value from 
bus_delayed_attach_children.
  
  Most places checked, but a couple last minute changes didn't. Make them 
all use
  the return value.
  
  Noticed by: rpokala@

Modified:
  head/sys/arm/broadcom/bcm2835/bcm2835_bsc.c
  head/sys/arm/mv/a37x0_spi.c
  head/sys/dev/ow/owc_gpiobus.c

Modified: head/sys/arm/broadcom/bcm2835/bcm2835_bsc.c

==
--- head/sys/arm/broadcom/bcm2835/bcm2835_bsc.c Fri Dec 13 21:39:10 
2019(r355734)
+++ head/sys/arm/broadcom/bcm2835/bcm2835_bsc.c Fri Dec 13 21:39:20 
2019(r355735)
@@ -347,9 +347,7 @@ bcm_bsc_attach(device_t dev)
}
 
/* Probe and attach the iicbus when interrupts are available. */
-   bus_delayed_attach_children(dev);
-
-   return (0);
+   return (bus_delayed_attach_children(dev));
 }
 
 static int

Modified: head/sys/arm/mv/a37x0_spi.c

==
--- head/sys/arm/mv/a37x0_spi.c Fri Dec 13 21:39:10 2019
(r355734)
+++ head/sys/arm/mv/a37x0_spi.c Fri Dec 13 21:39:20 2019
(r355735)
@@ -220,9 +220,7 @@ a37x0_spi_attach(device_t dev)
device_add_child(dev, "spibus", -1);
 
/* Probe and attach the spibus when interrupts are available. */
-   bus_delayed_attach_children(dev);
-
-   return (0);
+   return (bus_delayed_attach_children(dev));
 }
 
 static int

Modified: head/sys/dev/ow/owc_gpiobus.c

==
--- head/sys/dev/ow/owc_gpiobus.c   Fri Dec 13 21:39:10 2019
(r355734)
+++ head/sys/dev/ow/owc_gpiobus.c   Fri Dec 13 21:39:20 2019
(r355735)
@@ -131,9 +131,7 @@ owc_gpiobus_attach(device_t dev)
free(kids, M_TEMP);
if (nkid == 0)
device_add_child(dev, "ow", -1);
-   bus_delayed_attach_children(dev);
-
-   return (0);
+   return (bus_delayed_attach_children(dev));
 }
 
 static int



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r357002 - in head: share/man/man4 sys/conf sys/kern sys/modules/cpufreq sys/sys sys/x86/cpufreq

[Ravi Pokala]

-Original Message-
From:  on behalf of Conrad Meyer 

Date: 2020-01-22, Wednesday at 15:28
To: , , 

Subject: svn commit: r357002 - in head: share/man/man4 sys/conf sys/kern 
sys/modules/cpufreq sys/sys sys/x86/cpufreq

Author: cem
Date: Wed Jan 22 23:28:42 2020
New Revision: 357002
URL: https://svnweb.freebsd.org/changeset/base/357002

Log:
  cpufreq(4): Add support for Intel Speed Shift
  
  Intel Speed Shift is Intel's technology to control frequency in hardware,
  with hints from software.

Not to be confused with Intel Speed *Step*, right?

(/me was confused; naming things is hard)

-Ravi (rpokala@)

  Let's get a working version of this in the tree and we can refine it from
  here.
  
  Submitted by: bwidawsk, scottph
  Reviewed by:  bcr (manpages), myself
  Discussed with:   jhb, kib (earlier versions)
  With feedback from:   Greg V, gallatin, freebsdnewbie AT freenet.de
  Relnotes: yes
  Differential Revision:https://reviews.freebsd.org/D18028
 


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r360453 - head

[Ravi Pokala]

Interesting. This change purports to fix a problem with r360443, but I had no 
trouble with that change (make tinderbox WITH_META_MODE=YES), while this change 
results in an early fatal error:

make[2]: "Makefile" line 718: "Target architecture for amd64/conf/GENERIC 
unknown.  config(8) likely too old."

I'm running kernel and world r360270.

Thoughts?

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Bryan Drewery 

Date: 2020-04-28, Tuesday at 19:18
To: , , 

Subject: svn commit: r360453 - head

Author: bdrewery
Date: Wed Apr 29 02:18:39 2020
New Revision: 360453
URL: https://svnweb.freebsd.org/changeset/base/360453

Log:
  Use universe-toolchain config(8)

  This is a temporary hack to aid with config(8) changing in r360443.
  It will not work for all cases.

  env PATH is used because universe-toolchain is only built when worlds
  are built, and then only if clang is needed, so it may not exist.

  universe-toolchain needs to be expanded to always be built, inspected to
  remove non-cross-build-safe tools, used for buildworld/buildkernel,
  and potentially incremental build support.

  Sponsored by: Dell EMC

Modified:
  head/Makefile

Modified: head/Makefile

==
--- head/Makefile   Tue Apr 28 20:34:27 2020(r360452)
+++ head/Makefile   Wed Apr 29 02:18:39 2020(r360453)
@@ -711,6 +711,7 @@ KERNCONFS!= cd ${KERNSRCDIR}/${TARGET}/conf && \
 universe_kernconfs: universe_kernels_prologue .PHONY
 .for kernel in ${KERNCONFS}
 TARGET_ARCH_${kernel}!=cd ${KERNSRCDIR}/${TARGET}/conf && \
+   env PATH=${HOST_OBJTOP}/tmp/legacy/bin:${PATH:Q} \
config -m ${KERNSRCDIR}/${TARGET}/conf/${kernel} 2> /dev/null | \
grep -v WARNING: | cut -f 2
 .if empty(TARGET_ARCH_${kernel})


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r360453 - head

[Ravi Pokala]

-Original Message-
From:  on behalf of Ravi Pokala 

Date: 2020-05-03, Sunday at 14:24
To: Bryan Drewery , , 
, 
Subject: Re: svn commit: r360453 - head

Interesting. This change purports to fix a problem with r360443, but I had 
no trouble with that change (make tinderbox WITH_META_MODE=YES), while this 
change results in an early fatal error:

make[2]: "Makefile" line 718: "Target architecture for 
amd64/conf/GENERIC unknown.  config(8) likely too old."

I'm running kernel and world r360270.

Interesting; I was unable to build at HOL; was able to able to buildworld and 
kernel at r360443, rebooted into that, synced to HOL, and now able to build 
again.

-Ravi

Thoughts?

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Bryan Drewery 

Date: 2020-04-28, Tuesday at 19:18
To: , , 

Subject: svn commit: r360453 - head

Author: bdrewery
Date: Wed Apr 29 02:18:39 2020
New Revision: 360453
URL: https://svnweb.freebsd.org/changeset/base/360453

Log:
  Use universe-toolchain config(8)

  This is a temporary hack to aid with config(8) changing in r360443.
  It will not work for all cases.

  env PATH is used because universe-toolchain is only built when worlds
  are built, and then only if clang is needed, so it may not exist.

  universe-toolchain needs to be expanded to always be built, inspected 
to
  remove non-cross-build-safe tools, used for buildworld/buildkernel,
  and potentially incremental build support.

  Sponsored by: Dell EMC

Modified:
  head/Makefile

Modified: head/Makefile

==
--- head/Makefile   Tue Apr 28 20:34:27 2020(r360452)
+++ head/Makefile   Wed Apr 29 02:18:39 2020(r360453)
@@ -711,6 +711,7 @@ KERNCONFS!= cd ${KERNSRCDIR}/${TARGET}/conf && \
 universe_kernconfs: universe_kernels_prologue .PHONY
 .for kernel in ${KERNCONFS}
 TARGET_ARCH_${kernel}!=cd ${KERNSRCDIR}/${TARGET}/conf && \
+   env PATH=${HOST_OBJTOP}/tmp/legacy/bin:${PATH:Q} \
config -m ${KERNSRCDIR}/${TARGET}/conf/${kernel} 2> /dev/null | 
\
grep -v WARNING: | cut -f 2
 .if empty(TARGET_ARCH_${kernel})




___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r360964 - in head: lib/libclang_rt lib/libthr lib/msun libexec/rtld-elf libexec/tftpd/tests share/mk stand stand/arm/uboot stand/efi stand/efi/boot1 stand/efi/loader stand/i386/boot2 s

[Ravi Pokala]

This feels like it deserves an UPDATING (and possibly a RELNOTES) entry.

-Ravi (rpokala@)

-Original Message-
From:  on behalf of Eric van Gyzen 

Date: 2020-05-12, Tuesday at 08:22
To: , , 

Subject: svn commit: r360964 - in head: lib/libclang_rt lib/libthr lib/msun 
libexec/rtld-elf libexec/tftpd/tests share/mk stand stand/arm/uboot stand/efi 
stand/efi/boot1 stand/efi/loader stand/i386/boot2 st...

Author: vangyzen
Date: Tue May 12 15:22:40 2020
New Revision: 360964
URL: https://svnweb.freebsd.org/changeset/base/360964

Log:
  Remove tests for obsolete compilers in the build system

  Assume gcc is at least 6.4, the oldest xtoolchain in the ports tree.
  Assume clang is at least 6, which was in 11.2-RELEASE.  Drop conditions
  for older compilers.

  Reviewed by:  imp (earlier version), emaste, jhb
  MFC after:2 weeks
  Sponsored by: Dell EMC Isilon
  Differential Revision:https://reviews.freebsd.org/D24802

Modified:
  head/lib/libclang_rt/Makefile.inc
  head/lib/libthr/Makefile
  head/lib/msun/Makefile
  head/libexec/rtld-elf/Makefile
  head/libexec/tftpd/tests/Makefile
  head/share/mk/bsd.compiler.mk
  head/share/mk/bsd.sys.mk
  head/stand/arm/uboot/Makefile
  head/stand/defs.mk
  head/stand/efi/Makefile
  head/stand/efi/boot1/Makefile
  head/stand/efi/loader/Makefile
  head/stand/i386/boot2/Makefile
  head/stand/i386/isoboot/Makefile
  head/stand/libsa/Makefile
  head/sys/conf/Makefile.arm
  head/sys/conf/Makefile.powerpc
  head/sys/conf/kern.mk
  head/sys/conf/kern.post.mk
  head/sys/conf/kern.pre.mk
  head/sys/conf/kmod.mk
  head/sys/modules/Makefile
  head/usr.sbin/acpi/acpidb/Makefile
  head/usr.sbin/trpt/Makefile
  head/usr.sbin/zic/zic/Makefile

Modified: head/lib/libclang_rt/Makefile.inc

==
--- head/lib/libclang_rt/Makefile.inc   Tue May 12 14:47:38 2020
(r360963)
+++ head/lib/libclang_rt/Makefile.inc   Tue May 12 15:22:40 2020
(r360964)
@@ -32,7 +32,7 @@ CFLAGS+=  ${PICFLAG}
 CFLAGS+=   -fno-builtin
 CFLAGS+=   -fno-exceptions
 CXXFLAGS+= -fno-rtti
-.if ${COMPILER_TYPE} == clang && ${COMPILER_VERSION} >= 30700
+.if ${COMPILER_TYPE} == clang
 CFLAGS+=   -fno-sanitize=safe-stack
 .endif
 CFLAGS+=   -fno-stack-protector

Modified: head/lib/libthr/Makefile

==
--- head/lib/libthr/MakefileTue May 12 14:47:38 2020
(r360963)
+++ head/lib/libthr/MakefileTue May 12 15:22:40 2020
(r360964)
@@ -29,10 +29,7 @@ CFLAGS+=-Winline

 CFLAGS.thr_stack.c+=   -Wno-cast-align
 CFLAGS.rtld_malloc.c+= -Wno-cast-align
-.include 
-.if !(${COMPILER_TYPE} == "gcc" && ${COMPILER_VERSION} < 40300)
 CFLAGS.thr_symbols.c+= -Wno-missing-variable-declarations
-.endif

 .ifndef NO_THREAD_UNWIND_STACK
 CFLAGS+=-fexceptions

Modified: head/lib/msun/Makefile

==
--- head/lib/msun/Makefile  Tue May 12 14:47:38 2020(r360963)
+++ head/lib/msun/Makefile  Tue May 12 15:22:40 2020(r360964)
@@ -108,13 +108,13 @@ COMMON_SRCS+= catrigl.c \
s_nextafterl.c s_nexttoward.c s_remquol.c s_rintl.c s_roundl.c \
s_scalbnl.c s_sinl.c s_sincosl.c \
s_tanhl.c s_tanl.c s_truncl.c w_cabsl.c
-# Work around this warning from gcc 6:
+# Work around this warning from gcc:
 # lib/msun/ld80/e_powl.c:275:1: error: floating constant exceeds range 
of
 # 'long double' [-Werror=overflow]
 # if( y >= LDBL_MAX )
 # See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=130067
 .include 
-.if ${COMPILER_TYPE} == "gcc" && ${COMPILER_VERSION} >= 6
+.if ${COMPILER_TYPE} == "gcc"
 CFLAGS.e_powl.c+= -Wno-error=overflow
 .endif
 .endif

Modified: head/libexec/rtld-elf/Makefile

==
--- head/libexec/rtld-elf/Makefile  Tue May 12 14:47:38 2020
(r360963)
+++ head/libexec/rtld-elf/Makefile  Tue May 12 15:22:40 2020
(r360964)
@@ -90,8 +90,4 @@ ${PROG_FULL}: ${VERSION_MAP}
 # GCC warns about redeclarations even though they have __exported
 # and are therefore not identical to the ones from the system headers.
 CFLAGS+=   -Wno-redundant-decls
-.if ${COMPILER_VERSION} < 40300
-# Silence -Wshadow false positives in ancient GCC
-CFLAGS+=   -Wno-shadow
-.endif
 .endif

Modified: head/libexec/tftpd/tests/Makefile

==
--- head/libexec/tftpd/tests/Mak

Re: svn commit: r361143 - head/release/tools

[Ravi Pokala]

-Original Message-
From:  on behalf of Colin Percival 

Date: 2020-05-17, Sunday at 18:30
To: Oliver Pinter 
Cc: "src-committ...@freebsd.org" , 
"svn-src-...@freebsd.org" , "svn-src-head@freebsd.org" 

Subject: Re: svn commit: r361143 - head/release/tools

> On 2020-05-17 16:48, Oliver Pinter wrote:
>> On Sunday, May 17, 2020, Colin Percival > > wrote:
>> +REGION=`fetch -qo-
>> http://169.254.169.254/latest/meta-data/placement/availability-zone
>>  |
>> sed -e 's/[a-z]$//'`
>> 
>> What will be this hard-coded ip address without any verification or at least
>> https?
> 
> That's a magic IP address which connects to the EC2 "instance metadata
> service".  It doesn't actually go out over the network.

A comment would be appreciated, e.g. "Amazon uses this link-local address for 
the EC2 instance metadata service"

Thanks,

Ravi (rpokala@)

> -- 
> Colin Percival
> Security Officer Emeritus, FreeBSD | The power to serve
> Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r361546 - head/sys/cam/ata

[Ravi Pokala]

-Original Message-
From:  on behalf of Adrian Chadd 

Date: 2020-05-26, Tuesday at 19:10
To: , , 

Subject: svn commit: r361546 - head/sys/cam/ata

Author: adrian
Date: Wed May 27 02:10:09 2020
New Revision: 361546
URL: https://svnweb.freebsd.org/changeset/base/361546

Log:
  [ata_da] remove duplicate definition; it trips up ye olde gcc-6 on mips32

s/definition/declaration/



-Ravi (rpokala@)

  Checked first with: irc

Modified:
  head/sys/cam/ata/ata_da.c

Modified: head/sys/cam/ata/ata_da.c

==
--- head/sys/cam/ata/ata_da.c   Wed May 27 01:35:46 2020
(r361545)
+++ head/sys/cam/ata/ata_da.c   Wed May 27 02:10:09 2020
(r361546)
@@ -836,7 +836,6 @@ static  voidadaasync(void *callback_arg, 
u_int32_t co
 static int adabitsysctl(SYSCTL_HANDLER_ARGS);
 static int adaflagssysctl(SYSCTL_HANDLER_ARGS);
 static int adazonesupsysctl(SYSCTL_HANDLER_ARGS);
-static int adazonesupsysctl(SYSCTL_HANDLER_ARGS);
 static voidadasysctlinit(void *context, int pending);
 static int adagetattr(struct bio *bp);
 static voidadasetflags(struct ada_softc *softc,


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r361677 - in head/usr.bin/svn: . lib lib/libapr lib/libapr_util lib/libserf lib/libsvn_client lib/libsvn_delta lib/libsvn_diff lib/libsvn_fs lib/libsvn_fs_fs lib/libsvn_fs_util lib/lib

[Ravi Pokala]

-Original Message-
From:  on behalf of "Rodney W. Grimes" 

Reply-To: 
Date: 2020-06-01, Monday at 09:40
To: Ian Lepore 
Cc: Dimitry Andric , , 
, 
Subject: Re: svn commit: r361677 - in head/usr.bin/svn: . lib lib/libapr 
lib/libapr_util lib/libserf lib/libsvn_client lib/libsvn_delta lib/libsvn_diff 
lib/libsvn_fs lib/libsvn_fs_fs lib/libsvn_fs_util lib/libs...

> On Sun, 2020-05-31 at 22:04 +, Dimitry Andric wrote:
> > Author: dim
> > Date: Sun May 31 22:04:51 2020
> > New Revision: 361677
> > URL: https://svnweb.freebsd.org/changeset/base/361677
> > 
> > Log:
> >   Change Makefiles under usr.bin/svn to make them easier to
> > incrementally
> >   update. No functional change intended.
> >   
> >   MFC after:2 weeks
> > 
> 
> I wish we could get style.Makefile(9) updated to mandate this 1-per-
> line style when listing sources, dirs, etc, when the number of items is
> greater than N, where N is something like 3-6 filenames.  Otherwise the
> requirement to sort the names alphabetically pretty much mandates that
> many lines of the file will change just to insert one or two new files,
> and that makes it all but impossible to figure out from a diff what
> actually changed.

I like this idea, though rather than 3-6 filenames I propose
it to be anything longer than 3 lines, which is kinda about when
the pain point should start.  See the immediate SUBDIR below, it
is 11 items on 2ish/3 lines, and any change would worst case be a
3 line diff.  This probably covers a large portion of the tree.

FWIW, I'm partial to the 'FOO+=bar' syntax, rather than continuation lines. 
It's too easy to forget to add the continuation when appending or inserting.

I particularly do not like massive amounts of vertical white
space which this would create, but lacking an automated tool
this is probably a reasonable compromise.

If we did it everywhere it would mean lots of scrolling when
working on rather simple makefiles.

I generally feel the opposite -- I do a destressing amount of work on an 80x24 
serial console :-/ -- but I agree that "> 3 lines" is a reasonable compromise.

-Ravi (rpokala@)

> -- Ian
> 
> > 
> [...] 
> > -SUBDIR=lib .WAIT \
> > -   svn svnadmin svnbench svndumpfilter svnfsfs svnlook svnserve \
> > -   svnsync svnversion svnmucc svnrdump
> > +SUBDIR=lib \
> > +   .WAIT \
> > +   svn \
> > +   svnadmin \
> > +   svnbench \
> > +   svndumpfilter \
> > +   svnfsfs \
> > +   svnlook \
> > +   svnserve \
> > +   svnsync \
> > +   svnversion \
> > +   svnmucc \
> > +   svnrdump
> >  SUBDIR_PARALLEL=
> >  
> 
> 

-- 
Rod Grimes 
rgri...@freebsd.org


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r361677 - in head/usr.bin/svn: . lib lib/libapr lib/libapr_util lib/libserf lib/libsvn_client lib/libsvn_delta lib/libsvn_diff lib/libsvn_fs lib/libsvn_fs_fs lib/libsvn_fs_util lib/lib

[Ravi Pokala]

> > I generally feel the opposite -- I do a destressing amount of work on an 
> > 80x24 serial console :-/ -- but I agree that "> 3 lines" is a reasonable 
> > compromise.
> 
> I think we have had a communications breakdown?  To me it sounds as we both 
> agree that needlessly making Makefiles vertically long is not wanted, but 
> acceptable when folding these very long lists onto wide lines creates a 
> different problem.

That's exactly what I said: 'but I agree that "> 3 lines" is a reasonable 
compromise.'

:-)

-Ravi (rpokala@)

-Original Message-
From: "Rodney W. Grimes" 
Reply-To: 
Date: 2020-06-01, Monday at 19:47
To: Ravi Pokala 
Cc: , Ian Lepore , Dimitry Andric 
, , , 

Subject: Re: svn commit: r361677 - in head/usr.bin/svn: . lib lib/libapr 
lib/libapr_util lib/libserf lib/libsvn_client lib/libsvn_delta lib/libsvn_diff 
lib/libsvn_fs lib/libsvn_fs_fs lib/libsvn_fs_util lib/libs...

> -Original Message-
> From:  on behalf of "Rodney W. Grimes" 

> Reply-To: 
> Date: 2020-06-01, Monday at 09:40
> To: Ian Lepore 
> Cc: Dimitry Andric , , 
, 
> Subject: Re: svn commit: r361677 - in head/usr.bin/svn: . lib lib/libapr 
lib/libapr_util lib/libserf lib/libsvn_client lib/libsvn_delta lib/libsvn_diff 
lib/libsvn_fs lib/libsvn_fs_fs lib/libsvn_fs_util lib/libs...
> 
> > On Sun, 2020-05-31 at 22:04 +, Dimitry Andric wrote:
> > > Author: dim
> > > Date: Sun May 31 22:04:51 2020
> > > New Revision: 361677
> > > URL: https://svnweb.freebsd.org/changeset/base/361677
> > > 
> > > Log:
> > >   Change Makefiles under usr.bin/svn to make them easier to
> > > incrementally
> > >   update. No functional change intended.
> > >   
> > >   MFC after:  2 weeks
> > > 
> > 
> > I wish we could get style.Makefile(9) updated to mandate this 1-per-
> > line style when listing sources, dirs, etc, when the number of 
items is
> > greater than N, where N is something like 3-6 filenames.  Otherwise 
the
> > requirement to sort the names alphabetically pretty much mandates 
that
> > many lines of the file will change just to insert one or two new 
files,
> > and that makes it all but impossible to figure out from a diff what
> > actually changed.
> 
> I like this idea, though rather than 3-6 filenames I propose
> it to be anything longer than 3 lines, which is kinda about when
> the pain point should start.  See the immediate SUBDIR below, it
> is 11 items on 2ish/3 lines, and any change would worst case be a
> 3 line diff.  This probably covers a large portion of the tree.
> 
> FWIW, I'm partial to the 'FOO+=bar' syntax, rather than continuation 
lines. It's too easy to forget to add the continuation when appending or 
inserting.

That is indeed a better technique.

> 
> I particularly do not like massive amounts of vertical white
> space which this would create, but lacking an automated tool
> this is probably a reasonable compromise.
> 
> If we did it everywhere it would mean lots of scrolling when
> working on rather simple makefiles.
> 
> I generally feel the opposite -- I do a destressing amount of work on an 
80x24 serial console :-/ -- but I agree that "> 3 lines" is a reasonable 
compromise.

I think we have had a communications breakdown?  To me it sounds as we
both agree that needlessly making Makefiles vertically long is
not wanted, but acceptable when folding these very long lists
onto wide lines creates a different problem.

> -Ravi (rpokala@)
> 
> > -- Ian
> > 
> > > 
> > [...] 
> > > -SUBDIR=  lib .WAIT \
> > > - svn svnadmin svnbench svndumpfilter svnfsfs svnlook svnserve \
> > > - svnsync svnversion svnmucc svnrdump
> > > +SUBDIR=  lib \
> > > + .WAIT \
> > > + svn \
> > > + svnadmin \
> > > + svnbench \
> > > + svndumpfilter \
> > > + svnfsfs \
> > > + svnlook \
> > > + svnserve \
> > > + svnsync \
> > > + svnversion \
> > > + svnmucc \
> > > + svnrdump
> > >  SUBDIR_PARALLEL=
> > >  
> > 
> > 
> 
> -- 
> Rod Grimes 
rgri...@freebsd.org
> 
> 
> 

-- 
Rod Grimes 
rgri...@freebsd.org


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r361997 - head/sys/sys

[Ravi Pokala]

Hi Doug,

Shoot, it's still failing, but in a different way:


/usr/home/rpokala/freebsd/dev/base/head/sys/kern/subr_stats.c:3385:14: error: 
expected ')'
qstr);
 ^
/usr/home/rpokala/freebsd/dev/base/head/sys/kern/subr_stats.c:3375:11: note: to 
match this '('
printf(" RB ctd=%3d p=%3d l=%3d r=%3d c=%2d "
  ^
1 error generated.
--- subr_stats.o ---


Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Doug Moore 

Date: 2020-06-09, Tuesday at 19:50
To: , , 

Subject: svn commit: r361997 - head/sys/sys

Author: dougm
Date: Wed Jun 10 02:50:25 2020
New Revision: 361997
URL: https://svnweb.freebsd.org/changeset/base/361997

Log:
  Restore an RB_COLOR macro, for the benefit of a bit of DIAGNOSTIC code
  that depends on it.

  Reported by:  rpokala, mjguzik
  Reviewed by:  markj
  Differential Revision:https://reviews.freebsd.org/D25204

Modified:
  head/sys/sys/tree.h

Modified: head/sys/sys/tree.h

==
--- head/sys/sys/tree.h Wed Jun 10 01:32:13 2020(r361996)
+++ head/sys/sys/tree.h Wed Jun 10 02:50:25 2020(r361997)
@@ -333,6 +333,12 @@ struct {   
\
 #define RB_TRUE1
 #define RB_FALSE   0

+/* For debugging support */
+#define RB_COLOR(elm, field)   (RB_PARENT(elm, field) == NULL 
? RB_FALSE : \
+   RB_LEFT(RB_PARENT(elm, field), 
field) == elm ? \
+   RB_RED_LF(RB_PARENT(elm, field), 
field) : \
+   RB_RED_RT(RB_PARENT(elm, field), 
field)
+
 /*
  * Something to be invoked in a loop at the root of every modified subtree,
  * from the bottom up to the root, to update augmented node data.


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r362078 - in head: sbin/ifconfig sys/net

[Ravi Pokala]

Author: rpokala
Date: Thu Jun 11 22:46:08 2020
New Revision: 362078
URL: https://svnweb.freebsd.org/changeset/base/362078

Log:
  Decode the "LACP Fast Timeout" LAGG option flag
  
  r286700 added the "lacp_fast_timeout" option to `ifconfig', but we forgot to
  include the new option in the string used to decode the option bits. Add
  "LACP_FAST_TIMO" to LAGG_OPT_BITS.
  
  Also, s/LAGG_OPT_LACP_TIMEOUT/LAGG_OPT_LACP_FAST_TIMO/g , to be clearer that
  the flag indicates "Fast Timeout" mode.
  
  Reported by:  Greg Foster 
  Reviewed by:  jpaetzel
  MFC after:1 week
  Sponsored by: Panasas
  Differential Revision:https://reviews.freebsd.org/D25239

Modified:
  head/sbin/ifconfig/iflagg.c
  head/sys/net/if_lagg.c
  head/sys/net/if_lagg.h

Modified: head/sbin/ifconfig/iflagg.c
==
--- head/sbin/ifconfig/iflagg.c Thu Jun 11 21:52:06 2020(r362077)
+++ head/sbin/ifconfig/iflagg.c Thu Jun 11 22:46:08 2020(r362078)
@@ -141,8 +141,8 @@ setlaggsetopt(const char *val, int d, int s, const str
case -LAGG_OPT_LACP_TXTEST:
case LAGG_OPT_LACP_RXTEST:
case -LAGG_OPT_LACP_RXTEST:
-   case LAGG_OPT_LACP_TIMEOUT:
-   case -LAGG_OPT_LACP_TIMEOUT:
+   case LAGG_OPT_LACP_FAST_TIMO:
+   case -LAGG_OPT_LACP_FAST_TIMO:
break;
default:
err(1, "Invalid lagg option");
@@ -316,8 +316,8 @@ static struct cmd lagg_cmds[] = {
DEF_CMD("-lacp_txtest", -LAGG_OPT_LACP_TXTEST,  setlaggsetopt),
DEF_CMD("lacp_rxtest",  LAGG_OPT_LACP_RXTEST,   setlaggsetopt),
DEF_CMD("-lacp_rxtest", -LAGG_OPT_LACP_RXTEST,  setlaggsetopt),
-   DEF_CMD("lacp_fast_timeout",LAGG_OPT_LACP_TIMEOUT,  setlaggsetopt),
-   DEF_CMD("-lacp_fast_timeout",   -LAGG_OPT_LACP_TIMEOUT, setlaggsetopt),
+   DEF_CMD("lacp_fast_timeout",LAGG_OPT_LACP_FAST_TIMO,
setlaggsetopt),
+   DEF_CMD("-lacp_fast_timeout",   -LAGG_OPT_LACP_FAST_TIMO,   
setlaggsetopt),
DEF_CMD_ARG("flowid_shift", setlaggflowidshift),
DEF_CMD_ARG("rr_limit", setlaggrr_limit),
 };

Modified: head/sys/net/if_lagg.c
==
--- head/sys/net/if_lagg.c  Thu Jun 11 21:52:06 2020(r362077)
+++ head/sys/net/if_lagg.c  Thu Jun 11 22:46:08 2020(r362078)
@@ -1246,7 +1246,7 @@ lagg_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data
if (lsc->lsc_strict_mode != 0)
ro->ro_opts |= LAGG_OPT_LACP_STRICT;
if (lsc->lsc_fast_timeout != 0)
-   ro->ro_opts |= LAGG_OPT_LACP_TIMEOUT;
+   ro->ro_opts |= LAGG_OPT_LACP_FAST_TIMO;
 
ro->ro_active = sc->sc_active;
} else {
@@ -1305,8 +1305,8 @@ lagg_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data
case -LAGG_OPT_LACP_RXTEST:
case LAGG_OPT_LACP_STRICT:
case -LAGG_OPT_LACP_STRICT:
-   case LAGG_OPT_LACP_TIMEOUT:
-   case -LAGG_OPT_LACP_TIMEOUT:
+   case LAGG_OPT_LACP_FAST_TIMO:
+   case -LAGG_OPT_LACP_FAST_TIMO:
valid = lacp = 1;
break;
default:
@@ -1366,14 +1366,14 @@ lagg_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data
case -LAGG_OPT_LACP_STRICT:
lsc->lsc_strict_mode = 0;
break;
-   case LAGG_OPT_LACP_TIMEOUT:
+   case LAGG_OPT_LACP_FAST_TIMO:
LACP_LOCK(lsc);
LIST_FOREACH(lp, &lsc->lsc_ports, lp_next)
lp->lp_state |= LACP_STATE_TIMEOUT;
LACP_UNLOCK(lsc);
lsc->lsc_fast_timeout = 1;
break;
-   case -LAGG_OPT_LACP_TIMEOUT:
+   case -LAGG_OPT_LACP_FAST_TIMO:
LACP_LOCK(lsc);
LIST_FOREACH(lp, &lsc->lsc_ports, lp_next)
lp->lp_state &= ~LACP_STATE_TIMEOUT;

Modified: head/sys/net/if_lagg.h
==
--- head/sys/net/if_lagg.h  Thu Jun 11 21:52:06 2020(r362077)
+++ head/sys/net/if_lagg.h  Thu Jun 11 22:46:08 2020(r362078)
@@ -148,7 +148,7 @@ struct lagg_reqopts {
 #defineLAGG_OPT_LACP_STRICT0x10/* LACP strict 
mode */
 #defineLAGG_OPT_LACP_TXTEST0x20/* LACP debug: 
txtest */
 #defineLAGG_OPT_LACP_RXTEST0x40/* LACP debug: 
rxtest */
-#defineLAGG_OPT_LACP_TIMEO

Re: svn commit: r325796 - head/sys/cam/nvme

[Ravi Pokala]

In r325794, you set speed/max_speed to a KBps value; here, you're reporting 
those values as PCI Generation. That's... not right.

-Ravi (rpokala@)

-Original Message-
From:  on behalf of Warner Losh 

Date: 2017-11-13, Monday at 21:05
To: , , 

Subject: svn commit: r325796 - head/sys/cam/nvme

Author: imp
Date: Tue Nov 14 05:05:26 2017
New Revision: 325796
URL: https://svnweb.freebsd.org/changeset/base/325796

Log:
  Properly decode NVMe state of the drive and print out the information
  in the attach to more closely match what SCSI and ATA attached
  storage provides.
  
  Sponsored by: Netflix

Modified:
  head/sys/cam/nvme/nvme_all.c
  head/sys/cam/nvme/nvme_all.h
  head/sys/cam/nvme/nvme_xpt.c

Modified: head/sys/cam/nvme/nvme_all.c
==
--- head/sys/cam/nvme/nvme_all.cTue Nov 14 05:05:21 2017
(r325795)
+++ head/sys/cam/nvme/nvme_all.cTue Nov 14 05:05:26 2017
(r325796)
@@ -87,9 +87,16 @@ nvme_identify_match(caddr_t identbuffer, caddr_t table
 
 void
 nvme_print_ident(const struct nvme_controller_data *cdata,
-const struct nvme_namespace_data *data)
+const struct nvme_namespace_data *data, struct sbuf *sb)
 {
-   printf("I'm a pretty NVME drive\n");
+
+   sbuf_printf(sb, "<");
+   cam_strvis_sbuf(sb, cdata->mn, sizeof(cdata->mn), 0);
+   sbuf_printf(sb, " ");
+   cam_strvis_sbuf(sb, cdata->fr, sizeof(cdata->fr), 0);
+   sbuf_printf(sb, " ");
+   cam_strvis_sbuf(sb, cdata->sn, sizeof(cdata->sn), 0);
+   sbuf_printf(sb, ">\n");
 }
 
 /* XXX need to do nvme admin opcodes too, but those aren't used yet by nda */

Modified: head/sys/cam/nvme/nvme_all.h
==
--- head/sys/cam/nvme/nvme_all.hTue Nov 14 05:05:21 2017
(r325795)
+++ head/sys/cam/nvme/nvme_all.hTue Nov 14 05:05:26 2017
(r325796)
@@ -39,7 +39,8 @@ void  nvme_ns_cmd(struct ccb_nvmeio *nvmeio, uint8_t cm
 
 intnvme_identify_match(caddr_t identbuffer, caddr_t table_entry);
 
-void   nvme_print_ident(const struct nvme_controller_data *, const struct 
nvme_namespace_data *);
+struct sbuf;
+void   nvme_print_ident(const struct nvme_controller_data *, const struct 
nvme_namespace_data *, struct sbuf *);
 const char *nvme_op_string(const struct nvme_command *);
 const char *nvme_cmd_string(const struct nvme_command *, char *, size_t);
 const void *nvme_get_identify_cntrl(struct cam_periph *);

Modified: head/sys/cam/nvme/nvme_xpt.c
==
--- head/sys/cam/nvme/nvme_xpt.cTue Nov 14 05:05:21 2017
(r325795)
+++ head/sys/cam/nvme/nvme_xpt.cTue Nov 14 05:05:26 2017
(r325796)
@@ -619,35 +619,49 @@ nvme_announce_periph(struct cam_periph *periph)
struct  ccb_pathinq cpi;
struct  ccb_trans_settings cts;
struct  cam_path *path = periph->path;
+   struct ccb_trans_settings_nvme  *nvmex;
 
cam_periph_assert(periph, MA_OWNED);
 
+   /* Ask the SIM for connection details */
xpt_setup_ccb(&cts.ccb_h, path, CAM_PRIORITY_NORMAL);
cts.ccb_h.func_code = XPT_GET_TRAN_SETTINGS;
cts.type = CTS_TYPE_CURRENT_SETTINGS;
xpt_action((union ccb*)&cts);
if ((cts.ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP)
return;
+   nvmex = &cts.xport_specific.nvme;
+
/* Ask the SIM for its base transfer speed */
xpt_setup_ccb(&cpi.ccb_h, path, CAM_PRIORITY_NORMAL);
cpi.ccb_h.func_code = XPT_PATH_INQ;
xpt_action((union ccb *)&cpi);
-   /* XXX NVME STUFF HERE */
+   printf("%s%d: nvme version %d.%d x%d (max x%d) lanes PCIe Gen%d (max 
Gen%d) link",
+   periph->periph_name, periph->unit_number,
+   NVME_MAJOR(nvmex->spec),
+   NVME_MINOR(nvmex->spec),
+   nvmex->lanes, nvmex->max_lanes,
+   nvmex->speed, nvmex->max_speed);
printf("\n");
 }
 
 static void
 nvme_proto_announce(struct cam_ed *device)
 {
+   struct sbuf sb;
+   charbuffer[120];
 
-   nvme_print_ident(device->nvme_cdata, device->nvme_data);
+   sbuf_new(&sb, buffer, sizeof(buffer), SBUF_FIXEDLEN);
+   nvme_print_ident(device->nvme_cdata, device->nvme_data, &sb);
+   sbuf_finish(&sb);
+   sbuf_putbuf(&sb);
 }
 
 static void
 nvme_proto_denounce(struct cam_ed *device)
 {
 
-   nvme_print_ident(device->nvme_cdata, device->nvme_data);
+   nvme_proto_announce(device);
 }
 
 static void




___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r325817 - head/tests/sys/aio

[Ravi Pokala]

Hi Alan,

This appears to blow up most ARM worlds (and maybe other things too? My `make 
tinderbox' is still working through the ARMs):

_.arm.arm.buildworld:
--- all_subdir_tests/sys/aio ---
/usr/home/rpokala/freebsd/clean/base/head/tests/sys/aio/lio_kqueue_test.c:123:12:
 error: format specifies type 'long' but the argument has type 'off_t' (aka 'lo
ng long') [-Werror,-Wformat]
   iocb[k]->aio_offset);
   ^~~
/usr/home/rpokala/freebsd/clean/base/head/tests/sys/aio/lio_kqueue_test.c:137:8:
 error: format specifies type 'long' but the argument has type 'time_t' (aka 'lo
ng long') [-Werror,-Wformat]
time1, time2, time2-time1, result);
^
/usr/home/rpokala/freebsd/clean/base/head/tests/sys/aio/lio_kqueue_test.c:137:15:
 error: format specifies type 'long' but the argument has type 'time_t' (aka 'l
ong long') [-Werror,-Wformat]
time1, time2, time2-time1, result);
   ^
/usr/home/rpokala/freebsd/clean/base/head/tests/sys/aio/lio_kqueue_test.c:137:22:
 error: format specifies type 'long' but the argument has type 'long long' [-We
rror,-Wformat]
time1, time2, time2-time1, result);
  ^~~

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Alan Somers 

Date: 2017-11-14, Tuesday at 09:46
To: , , 

Subject: svn commit: r325817 - head/tests/sys/aio

Author: asomers
Date: Tue Nov 14 17:46:37 2017
New Revision: 325817
URL: https://svnweb.freebsd.org/changeset/base/325817

Log:
  AIO tests: increase limits
  
  tests/sys/aio/aio_kqueue_test.c
Instead of using a hard-coded queue depth, use
vfs.aio.max_aio_queue_per_proc
  
  tests/sys/aio/lio_kqueue_test.c
The old, small limit on lio_listio's operation count was lifted by
change 324941.  Raise the operation count as high as possible without
exceeding the process's operation limit.
  
  MFC after:3 weeks
  Sponsored by: Spectra Logic Corp

Modified:
  head/tests/sys/aio/aio_kqueue_test.c
  head/tests/sys/aio/lio_kqueue_test.c

Modified: head/tests/sys/aio/aio_kqueue_test.c
==
--- head/tests/sys/aio/aio_kqueue_test.cTue Nov 14 17:16:03 2017
(r325816)
+++ head/tests/sys/aio/aio_kqueue_test.cTue Nov 14 17:46:37 2017
(r325817)
@@ -51,28 +51,37 @@
 
 #define PATH_TEMPLATE   "aio.XX"
 
-#define MAX_IOCBS 128
 #define MAX_RUNS 300
 /* #define DEBUG */
 
 int
 main (int argc, char *argv[])
 {
-   struct aiocb *iocb[MAX_IOCBS], *kq_iocb;
+   struct aiocb **iocb, *kq_iocb;
char *file, pathname[sizeof(PATH_TEMPLATE)+1];
struct kevent ke, kq_returned;
struct timespec ts;
char buffer[32768];
+   int max_queue_per_proc;
+   size_t max_queue_per_proc_size;
 #ifdef DEBUG
int cancel, error;
 #endif
int failed = 0, fd, kq, pending, result, run;
int tmp_file = 0;
-   unsigned i, j;
+   int i, j;
 
PLAIN_REQUIRE_KERNEL_MODULE("aio", 0);
PLAIN_REQUIRE_UNSAFE_AIO(0);
 
+   max_queue_per_proc_size = sizeof(max_queue_per_proc);
+   if (sysctlbyname("vfs.aio.max_aio_queue_per_proc",
+   &max_queue_per_proc, &max_queue_per_proc_size, NULL, 0) != 0)
+   err(1, "sysctlbyname");
+   iocb = calloc(max_queue_per_proc, sizeof(struct aiocb*));
+   if (iocb == NULL)
+   err(1, "calloc");
+
kq = kqueue();
if (kq < 0) {
perror("No kqeueue\n");
@@ -95,7 +104,7 @@ main (int argc, char *argv[])
 #ifdef DEBUG
printf("Run %d\n", run);
 #endif
-   for (i = 0; i < nitems(iocb); i++) {
+   for (i = 0; i < max_queue_per_proc; i++) {
iocb[i] = (struct aiocb *)calloc(1,
sizeof(struct aiocb));
if (iocb[i] == NULL)
@@ -103,7 +112,7 @@ main (int argc, char *argv[])
}
 
pending = 0;
-   for (i = 0; i < nitems(iocb); i++) {
+   for (i = 0; i < max_queue_per_proc; i++) {
pending++;
iocb[i]->aio_nbytes = sizeof(buffer);
iocb[i]->aio_buf = buffer;
@@ -139,7 +148,7 @@ main (int argc, char *argv[])
}
}
 #ifdef DEBUG
-   cancel = nitems(iocb) - pending;
+   cancel = max_queue_per_proc - pending;
 #endif
 
i = 0;
@@ -173,11 +182,11 @@ main (int argc, char *argv[])
break;
 #ifdef DEBUG
printf("Try again left %d out of %lu %d\n",
-   pending, nitems(iocb), cancel);
+ 

Re: svn commit: r325796 - head/sys/cam/nvme

[Ravi Pokala]

Well that's wonderfully ambiguous... :-p

Okay, thanks for clearing that up.

-Ravi (rpokala@)

-Original Message-
From:  on behalf of Warner Losh 
Date: 2017-11-14, Tuesday at 12:38
To: Ravi Pokala 
Cc: Warner Losh , src-committers 
, "svn-src-...@freebsd.org" 
, "svn-src-head@freebsd.org" 
Subject: Re: svn commit: r325796 - head/sys/cam/nvme



On Mon, Nov 13, 2017 at 10:35 PM, Ravi Pokala  wrote:

In r325794, you set speed/max_speed to a KBps value; here, you're reporting 
those values as PCI Generation. That's... not right.



Two different CCBs. The PATH_INQ one returns a general KB/s number. The 
GET_TRANSPORT one returns the raw numbers.

Warner

 

-Ravi (rpokala@)

-Original Message-
From:  on behalf of Warner Losh 

Date: 2017-11-13, Monday at 21:05
To: , , 

Subject: svn commit: r325796 - head/sys/cam/nvme

Author: imp
Date: Tue Nov 14 05:05:26 2017
New Revision: 325796
URL: https://svnweb.freebsd.org/changeset/base/325796

Log:
  Properly decode NVMe state of the drive and print out the information
  in the attach to more closely match what SCSI and ATA attached
  storage provides.

  Sponsored by: Netflix

Modified:
  head/sys/cam/nvme/nvme_all.c
  head/sys/cam/nvme/nvme_all.h
  head/sys/cam/nvme/nvme_xpt.c

Modified: head/sys/cam/nvme/nvme_all.c
==
--- head/sys/cam/nvme/nvme_all.cTue Nov 14 05:05:21 2017
(r325795)
+++ head/sys/cam/nvme/nvme_all.cTue Nov 14 05:05:26 2017
(r325796)
@@ -87,9 +87,16 @@ nvme_identify_match(caddr_t identbuffer, caddr_t table

 void
 nvme_print_ident(const struct nvme_controller_data *cdata,
-const struct nvme_namespace_data *data)
+const struct nvme_namespace_data *data, struct sbuf *sb)
 {
-   printf("I'm a pretty NVME drive\n");
+
+   sbuf_printf(sb, "<");
+   cam_strvis_sbuf(sb, cdata->mn, sizeof(cdata->mn), 0);
+   sbuf_printf(sb, " ");
+   cam_strvis_sbuf(sb, cdata->fr, sizeof(cdata->fr), 0);
+   sbuf_printf(sb, " ");
+   cam_strvis_sbuf(sb, cdata->sn, sizeof(cdata->sn), 0);
+   sbuf_printf(sb, ">\n");
 }

 /* XXX need to do nvme admin opcodes too, but those aren't used yet by nda */

Modified: head/sys/cam/nvme/nvme_all.h
==
--- head/sys/cam/nvme/nvme_all.hTue Nov 14 05:05:21 2017
(r325795)
+++ head/sys/cam/nvme/nvme_all.hTue Nov 14 05:05:26 2017
(r325796)
@@ -39,7 +39,8 @@ void  nvme_ns_cmd(struct ccb_nvmeio *nvmeio, uint8_t cm

 intnvme_identify_match(caddr_t identbuffer, caddr_t table_entry);

-void   nvme_print_ident(const struct nvme_controller_data *, const struct 
nvme_namespace_data *);
+struct sbuf;
+void   nvme_print_ident(const struct nvme_controller_data *, const struct 
nvme_namespace_data *, struct sbuf *);
 const char *nvme_op_string(const struct nvme_command *);
 const char *nvme_cmd_string(const struct nvme_command *, char *, size_t);
 const void *nvme_get_identify_cntrl(struct cam_periph *);

Modified: head/sys/cam/nvme/nvme_xpt.c
==
--- head/sys/cam/nvme/nvme_xpt.cTue Nov 14 05:05:21 2017
(r325795)
+++ head/sys/cam/nvme/nvme_xpt.cTue Nov 14 05:05:26 2017
(r325796)
@@ -619,35 +619,49 @@ nvme_announce_periph(struct cam_periph *periph)
struct  ccb_pathinq cpi;
struct  ccb_trans_settings cts;
struct  cam_path *path = periph->path;
+   struct ccb_trans_settings_nvme  *nvmex;

cam_periph_assert(periph, MA_OWNED);

+   /* Ask the SIM for connection details */
xpt_setup_ccb(&cts.ccb_h, path, CAM_PRIORITY_NORMAL);
cts.ccb_h.func_code = XPT_GET_TRAN_SETTINGS;
cts.type = CTS_TYPE_CURRENT_SETTINGS;
xpt_action((union ccb*)&cts);
if ((cts.ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP)
return;
+   nvmex = &cts.xport_specific.nvme;
+
/* Ask the SIM for its base transfer speed */
xpt_setup_ccb(&cpi.ccb_h, path, CAM_PRIORITY_NORMAL);
cpi.ccb_h.func_code = XPT_PATH_INQ;
xpt_action((union ccb *)&cpi);
-   /* XXX NVME STUFF HERE */
+   printf("%s%d: nvme version %d.%d x%d (max x%d) lanes PCIe Gen%d (max 
Gen%d) link",
+   periph->periph_name, periph->unit_number,
+   NVME_MAJOR(nvmex->spec),
+   NVME_MINOR(nvmex->spec),
+   nvmex->lanes, nvmex->max_lanes,
+   nvmex->speed, nvmex->max_speed);
printf("\n");
 }

 static void
 nvme_proto_announce(struct cam_ed *device)
 {
+   struct sbuf sb;
+   charbuffer[120];

-   nvme_print_ident(device->nvme_cdata, device->nvme_data);
+   

Re: svn commit: r357865 - in head/sys/amd64/vmm: . io

[Ravi Pokala]

Why "svm"?

-Ravi (rpokala@)

-Original Message-
From:  on behalf of Konstantin Belousov 

Date: 2020-02-13, Thursday at 11:03
To: , , 

Subject: svn commit: r357865 - in head/sys/amd64/vmm: . io

Author: kib
Date: Thu Feb 13 19:03:12 2020
New Revision: 357865
URL: https://svnweb.freebsd.org/changeset/base/357865

Log:
  vmm: Add Hygon Dhyana support.
  
  Submitted by: Pu Wen 
  Discussed with:   grehan
  Reviewed by:  jhb (previous version)
  MFC after:1 week
  Differential revision:https://reviews.freebsd.org/D23553

Modified:
  head/sys/amd64/vmm/io/iommu.c
  head/sys/amd64/vmm/vmm.c
  head/sys/amd64/vmm/vmm_stat.c
  head/sys/amd64/vmm/vmm_util.c
  head/sys/amd64/vmm/vmm_util.h
  head/sys/amd64/vmm/x86.c

Modified: head/sys/amd64/vmm/io/iommu.c

==
--- head/sys/amd64/vmm/io/iommu.c   Thu Feb 13 18:37:17 2020
(r357864)
+++ head/sys/amd64/vmm/io/iommu.c   Thu Feb 13 19:03:12 2020
(r357865)
@@ -184,7 +184,7 @@ iommu_init(void)
 
if (vmm_is_intel())
ops = &iommu_ops_intel;
-   else if (vmm_is_amd())
+   else if (vmm_is_svm())
ops = &iommu_ops_amd;
else
ops = NULL;

Modified: head/sys/amd64/vmm/vmm.c

==
--- head/sys/amd64/vmm/vmm.cThu Feb 13 18:37:17 2020
(r357864)
+++ head/sys/amd64/vmm/vmm.cThu Feb 13 19:03:12 2020
(r357865)
@@ -347,7 +347,7 @@ vmm_init(void)

if (vmm_is_intel())
ops = &vmm_ops_intel;
-   else if (vmm_is_amd())
+   else if (vmm_is_svm())
ops = &vmm_ops_amd;
else
return (ENXIO);

Modified: head/sys/amd64/vmm/vmm_stat.c

==
--- head/sys/amd64/vmm/vmm_stat.c   Thu Feb 13 18:37:17 2020
(r357864)
+++ head/sys/amd64/vmm/vmm_stat.c   Thu Feb 13 19:03:12 2020
(r357865)
@@ -67,7 +67,7 @@ vmm_stat_register(void *arg)
if (vst->scope == VMM_STAT_SCOPE_INTEL && !vmm_is_intel())
return;
 
-   if (vst->scope == VMM_STAT_SCOPE_AMD && !vmm_is_amd())
+   if (vst->scope == VMM_STAT_SCOPE_AMD && !vmm_is_svm())
return;
 
if (vst_num_elems + vst->nelems >= MAX_VMM_STAT_ELEMS) {

Modified: head/sys/amd64/vmm/vmm_util.c

==
--- head/sys/amd64/vmm/vmm_util.c   Thu Feb 13 18:37:17 2020
(r357864)
+++ head/sys/amd64/vmm/vmm_util.c   Thu Feb 13 19:03:12 2020
(r357865)
@@ -46,9 +46,10 @@ vmm_is_intel(void)
 }
 
 bool
-vmm_is_amd(void)
+vmm_is_svm(void)
 {
-   return (strcmp(cpu_vendor, "AuthenticAMD") == 0);
+   return (strcmp(cpu_vendor, "AuthenticAMD") == 0 ||
+   strcmp(cpu_vendor, "HygonGenuine") == 0);
 }
 
 bool

Modified: head/sys/amd64/vmm/vmm_util.h

==
--- head/sys/amd64/vmm/vmm_util.h   Thu Feb 13 18:37:17 2020
(r357864)
+++ head/sys/amd64/vmm/vmm_util.h   Thu Feb 13 19:03:12 2020
(r357865)
@@ -34,7 +34,7 @@
 struct trapframe;
 
 bool   vmm_is_intel(void);
-bool   vmm_is_amd(void);
+bool   vmm_is_svm(void);
 bool   vmm_supports_1G_pages(void);
 
 void   dump_trapframe(struct trapframe *tf);

Modified: head/sys/amd64/vmm/x86.c

==
--- head/sys/amd64/vmm/x86.cThu Feb 13 18:37:17 2020
(r357864)
+++ head/sys/amd64/vmm/x86.cThu Feb 13 19:03:12 2020
(r357865)
@@ -135,7 +135,7 @@ x86_emulate_cpuid(struct vm *vm, int vcpu_id,
break;
case CPUID_8000_0008:
cpuid_count(*eax, *ecx, regs);
-   if (vmm_is_amd()) {
+   if (vmm_is_svm()) {
/*
 * As on Intel (_0007:0, EDX), mask out
 * unsupported or unsafe AMD extended features
@@ -234,7 +234,7 @@ x86_emulate_cpuid(struct vm *vm, int vcpu_id,
 
case CPUID_8000_001D:
/* AMD Cache topology, like _0004 for Intel. */
-   if (!vmm_is_amd())
+   if (!vmm_is_svm())
goto default_leaf;
 
/*
@@ -276,8 +276,11 @@ x86_emulate_cpuid(struct vm *vm, in

Re: svn commit: r357865 - in head/sys/amd64/vmm: . io

[Ravi Pokala]

-Original Message-
From:  on behalf of Konstantin Belousov 

Date: 2020-02-13, Thursday at 14:08
To: Ravi Pokala 
Cc: , , 

Subject: Re: svn commit: r357865 - in head/sys/amd64/vmm: . io

On Thu, Feb 13, 2020 at 01:49:09PM -0800, Ravi Pokala wrote:
> Why "svm"?
Because this is how AMD calls its virtualization extensions.
Secure Virtual Machine.

Okay, thanks. That would have been good to note in the commit message. ;-)

Thanks,

Ravi (rpokala@)

> 
> -Ravi (rpokala@)
> 
> -Original Message-
> From:  on behalf of Konstantin Belousov 

> Date: 2020-02-13, Thursday at 11:03
> To: , , 

> Subject: svn commit: r357865 - in head/sys/amd64/vmm: . io
> 
> Author: kib
> Date: Thu Feb 13 19:03:12 2020
> New Revision: 357865
> URL: https://svnweb.freebsd.org/changeset/base/357865
> 
> Log:
>   vmm: Add Hygon Dhyana support.
>   
>   Submitted by:   Pu Wen 
>   Discussed with: grehan
>   Reviewed by:jhb (previous version)
>   MFC after:  1 week
>   Differential revision:  https://reviews.freebsd.org/D23553
> 
> Modified:
>   head/sys/amd64/vmm/io/iommu.c
>   head/sys/amd64/vmm/vmm.c
>   head/sys/amd64/vmm/vmm_stat.c
>   head/sys/amd64/vmm/vmm_util.c
>   head/sys/amd64/vmm/vmm_util.h
>   head/sys/amd64/vmm/x86.c
> 
> Modified: head/sys/amd64/vmm/io/iommu.c
> 
==
> --- head/sys/amd64/vmm/io/iommu.c Thu Feb 13 18:37:17 2020
(r357864)
> +++ head/sys/amd64/vmm/io/iommu.c Thu Feb 13 19:03:12 2020
(r357865)
> @@ -184,7 +184,7 @@ iommu_init(void)
>  
>   if (vmm_is_intel())
>   ops = &iommu_ops_intel;
> - else if (vmm_is_amd())
> + else if (vmm_is_svm())
>   ops = &iommu_ops_amd;
>   else
>   ops = NULL;
> 
> Modified: head/sys/amd64/vmm/vmm.c
> 
==
> --- head/sys/amd64/vmm/vmm.c  Thu Feb 13 18:37:17 2020
(r357864)
> +++ head/sys/amd64/vmm/vmm.c  Thu Feb 13 19:03:12 2020
(r357865)
> @@ -347,7 +347,7 @@ vmm_init(void)
>   
>   if (vmm_is_intel())
>   ops = &vmm_ops_intel;
> - else if (vmm_is_amd())
> + else if (vmm_is_svm())
>   ops = &vmm_ops_amd;
>   else
>   return (ENXIO);
> 
> Modified: head/sys/amd64/vmm/vmm_stat.c
> 
==
> --- head/sys/amd64/vmm/vmm_stat.c Thu Feb 13 18:37:17 2020
(r357864)
> +++ head/sys/amd64/vmm/vmm_stat.c Thu Feb 13 19:03:12 2020
(r357865)
> @@ -67,7 +67,7 @@ vmm_stat_register(void *arg)
>   if (vst->scope == VMM_STAT_SCOPE_INTEL && !vmm_is_intel())
>   return;
>  
> - if (vst->scope == VMM_STAT_SCOPE_AMD && !vmm_is_amd())
> + if (vst->scope == VMM_STAT_SCOPE_AMD && !vmm_is_svm())
>   return;
>  
>   if (vst_num_elems + vst->nelems >= MAX_VMM_STAT_ELEMS) {
> 
> Modified: head/sys/amd64/vmm/vmm_util.c
> 
==
> --- head/sys/amd64/vmm/vmm_util.c Thu Feb 13 18:37:17 2020
(r357864)
> +++ head/sys/amd64/vmm/vmm_util.c Thu Feb 13 19:03:12 2020
(r357865)
> @@ -46,9 +46,10 @@ vmm_is_intel(void)
>  }
>  
>  bool
> -vmm_is_amd(void)
> +vmm_is_svm(void)
>  {
> - return (strcmp(cpu_vendor, "AuthenticAMD") == 0);
> + return (strcmp(cpu_vendor, "AuthenticAMD") == 0 ||
> + strcmp(cpu_vendor, "HygonGenuine") == 0);
>  }
>  
>  bool
> 
> Modified: head/sys/amd64/vmm/vmm_util.h
> 
==
> --- head/sys/amd64/vmm/vmm_util.h Thu Feb 13 18:37:17 2020
(r357864)
> +++ head/sys/amd64/vmm/vmm_util.h Thu Feb 13 19:03:12 2020
(r3578

Re: svn commit: r358317 - head/sys/kern

[Ravi Pokala]

-Original Message-
From:  on behalf of Gleb Smirnoff 

Date: 2020-02-25, Tuesday at 11:11
To: , , 

Subject: svn commit: r358317 - head/sys/kern

Author: glebius
Date: Tue Feb 25 19:11:20 2020
New Revision: 358317
URL: https://svnweb.freebsd.org/changeset/base/358317

Log:
  When sendfile_swapin() sweeps through pages in search for a bogus page
  skip first and last pages.  This is a micro optimisation.

Yes, but *why* skip the first and last pages?

-Ravi

Modified:
  head/sys/kern/kern_sendfile.c

Modified: head/sys/kern/kern_sendfile.c

==
--- head/sys/kern/kern_sendfile.c   Tue Feb 25 19:04:39 2020
(r358316)
+++ head/sys/kern/kern_sendfile.c   Tue Feb 25 19:11:20 2020
(r358317)
@@ -462,7 +462,7 @@ sendfile_swapin(vm_object_t obj, struct sf_io *sfio, i
 * Restore the valid page pointers.  They are already
 * unbusied, but still wired.
 */
-   for (j = i; j < i + count; j++)
+   for (j = i + 1; j < i + count - 1; j++)
if (pa[j] == bogus_page) {
pa[j] = vm_page_lookup(obj,
OFF_TO_IDX(vmoff(j, off)));



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r358317 - head/sys/kern

[Ravi Pokala]

-Original Message-
From: Gleb Smirnoff 
Date: 2020-02-26, Wednesday at 13:55
To: Ravi Pokala 
Cc: , , 

Subject: Re: svn commit: r358317 - head/sys/kern

On Tue, Feb 25, 2020 at 12:02:29PM -0800, Ravi Pokala wrote:
R>   When sendfile_swapin() sweeps through pages in search for a bogus 
page
R>   skip first and last pages.  This is a micro optimisation.
R> 
R> Yes, but *why* skip the first and last pages?

We may have inserted bogus pages in the middle of a request. We never 
substitute
first or last.

-- 
Gleb Smirnoff

Oh god, "bogus_page" -- Panasas had to jump through a bunch of hoops involving 
bogus_page and our RAIDing-across-sectors GEOM class years ago. 

-Ravi (rpokala@)



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r359377 - head/contrib/binutils/binutils

[Ravi Pokala]

I note there's no version on that deprecation notice...?

-Ravi

-Original Message-
From:  on behalf of Ed Maste 

Date: 2020-03-27, Friday at 12:39
To: , , 

Subject: svn commit: r359377 - head/contrib/binutils/binutils

Author: emaste
Date: Fri Mar 27 19:39:14 2020
New Revision: 359377
URL: https://svnweb.freebsd.org/changeset/base/359377

Log:
  objdump: emit a deprecation notice at program start
  
  PR:   212319

Modified:
  head/contrib/binutils/binutils/objdump.c

Modified: head/contrib/binutils/binutils/objdump.c

==
--- head/contrib/binutils/binutils/objdump.cFri Mar 27 19:17:45 
2020(r359376)
+++ head/contrib/binutils/binutils/objdump.cFri Mar 27 19:39:14 
2020(r359377)
@@ -3248,6 +3248,8 @@ main (int argc, char **argv)
}
 }
 
+  non_fatal (_("objdump 2.17.50 is deprecated in FreeBSD and will be 
removed"));
+
   if (show_version)
 print_version ("objdump");
 



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r359493 - head/sys/mips/nlm/dev/net

[Ravi Pokala]

Author: rpokala
Date: Tue Mar 31 20:09:20 2020
New Revision: 359493
URL: https://svnweb.freebsd.org/changeset/base/359493

Log:
  Fix build for mips.XLP64 kernel, by re-ordering headers
  
  The log for the failure contained errors like this:
  
  | In file included from ${SRCTOP}/sys/mips/nlm/dev/net/xlpge.c:34:
  | In file included from ${SRCTOP}/sys/sys/systm.h:44:
  | In file included from ./machine/atomic.h:849:
  | ${SRCTOP}/sys/sys/_atomic_subword.h:222:37: error: unknown type name 
'u_long'; did you mean 'long'?
  | atomic_testandset_acq_long(volatile u_long *p, u_int v)
  | ^~
  | long
  
  And similar "unknown type name" errors for u_int, not recognizing bool as a 
type, etc.
  
  This was caused by including  too far down; move it up where it 
belongs.
  
  While here, add a blank line after '__FBSDID()', in keeping with convention.
  
  Reviewed by:  emaste
  Sponsored by: Panasas
  Differential Revision:https://reviews.freebsd.org/D24242

Modified:
  head/sys/mips/nlm/dev/net/xlpge.c

Modified: head/sys/mips/nlm/dev/net/xlpge.c
==
--- head/sys/mips/nlm/dev/net/xlpge.c   Tue Mar 31 17:57:11 2020
(r359492)
+++ head/sys/mips/nlm/dev/net/xlpge.c   Tue Mar 31 20:09:20 2020
(r359493)
@@ -30,10 +30,11 @@
 
 #include 
 __FBSDID("$FreeBSD$");
+
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r359499 - head/sys/dev/ahci

[Ravi Pokala]

-Original Message-
From:  on behalf of Alexander Motin 

Date: 2020-03-31, Tuesday at 20:19
To: , , 

Subject: svn commit: r359499 - head/sys/dev/ahci

Author: mav
Date: Wed Apr  1 03:19:42 2020
New Revision: 359499
URL: https://svnweb.freebsd.org/changeset/base/359499

Log:
  Add ID for JMicron JMB582/JMB585 AHCI controller.
  
  JMB582 has 2 6Gbps SATA ports and PCIe 3.0 x1.
  JMB585 has 5 6Gbps SATA ports and PCIe 3.0 x2.
  
  Both chips support AHCI v1.31, Port Multiplier with FBS and 8 MSI vectors.

Hi Alexander,

The second line of diff seems unrelated...?

Thanks,

Ravi (rpokala@)

  MFC after:2 weeks

Modified:
  head/sys/dev/ahci/ahci_pci.c

Modified: head/sys/dev/ahci/ahci_pci.c

==
--- head/sys/dev/ahci/ahci_pci.cWed Apr  1 02:13:01 2020
(r359498)
+++ head/sys/dev/ahci/ahci_pci.cWed Apr  1 03:19:42 2020
(r359499)
@@ -247,6 +247,7 @@ static const struct {
{0x2365197b, 0x00, "JMicron JMB365",AHCI_Q_NOFORCE},
{0x2366197b, 0x00, "JMicron JMB366",AHCI_Q_NOFORCE},
{0x2368197b, 0x00, "JMicron JMB368",AHCI_Q_NOFORCE},
+   {0x0585197b, 0x00, "JMicron JMB58x",0},
{0x61ab, 0x00, "Marvell 88SE6111",  AHCI_Q_NOFORCE | AHCI_Q_NOPMP |
AHCI_Q_1CH | AHCI_Q_EDGEIS},
{0x612111ab, 0x00, "Marvell 88SE6121",  AHCI_Q_NOFORCE | AHCI_Q_NOPMP |
@@ -399,6 +400,7 @@ ahci_probe(device_t dev)
 !(ahci_ids[i].quirks & AHCI_Q_NOFORCE {
/* Do not attach JMicrons with single PCI function. */
if (pci_get_vendor(dev) == 0x197b &&
+   (ahci_ids[i].quirks & AHCI_Q_NOFORCE) &&
(pci_read_config(dev, 0xdf, 1) & 0x40) == 0)
return (ENXIO);
snprintf(buf, sizeof(buf), "%s AHCI SATA controller",



___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r335708 - head

[Ravi Pokala]

-Original Message-
From:  on behalf of Bryan Drewery 

Date: 2018-06-27, Wednesday at 09:58
To: , , 

Subject: svn commit: r335708 - head

> Author: bdrewery
> Date: Wed Jun 27 16:57:59 2018
> New Revision: 335708
> URL: https://svnweb.freebsd.org/changeset/base/335708
> 
> Log:
>   tinderbox: Give details about kernel builds.
>   
>   This is a bit noisy now but it was silent before leading to
>   wondering if it was doing anything.
>   
>   MFC after:  1 week
>   Suggested by:   rpokala
>   Sponsored by:   Dell EMC
> 
> Modified:
>   head/Makefile

\o/ Yay!

Thank you sir!

-Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r335979 - in head: . lib/libkvm sys/kern sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat

[Ravi Pokala]

Hi Brooks,

-Original Message-
From:  on behalf of Brooks Davis 

Date: 2018-07-05, Thursday at 06:13
To: , , 

Subject: svn commit: r335979 - in head: . lib/libkvm sys/kern sys/netinet 
sys/sys usr.bin/netstat usr.bin/sockstat

> Author: brooks
> Date: Thu Jul  5 13:13:48 2018
> New Revision: 335979
> URL: https://svnweb.freebsd.org/changeset/base/335979
> 
> Log:
>   Make struct xinpcb and friends word-size independent.
>   
>   Replace size_t members with ksize_t (uint64_t) and pointer members
>   (never used as pointers in userspace, but instead as unique
>   idenitifiers) with kvaddr_t (uint64_t). This makes the structs
>   identical between 32-bit and 64-bit ABIs.
...
> Modified: head/UPDATING
> ==
> --- head/UPDATING Thu Jul  5 11:50:59 2018(r335978)
> +++ head/UPDATING Thu Jul  5 13:13:48 2018(r335979)
> @@ -31,6 +31,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW:
>   disable the most expensive debugging functionality run
>   "ln -s 'abort:false,junk:false' /etc/malloc.conf".)
>  
> +20180705:
> + The ABI of syscalls used by management tools like sockstat and
> + netstat has been broken to allow 32-bit binaries to work on
> + 64-bit kernels without modification.

Isn't that what the compat32 layer is for?

> These programs will need
> + to match the kernel in order to function.  External programs may
> + require minor modifications to accommodate a change of type in
> + structures from pointers to 64-bit virtual addresses.
> +

Doesn't this contradict the earlier statement about letting things run 
unmodified?

Thanks,

Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r336077 - in head/share/man/man4: . man4.aarch64 man4.arm

[Ravi Pokala]

-Original Message-
From:  on behalf of Ian Lepore 

Date: 2018-07-07, Saturday at 14:49
To: , , 

Subject: svn commit: r336077 - in head/share/man/man4: . man4.aarch64 man4.arm

> Author: ian
> Date: Sat Jul  7 21:49:30 2018
> New Revision: 336077
> URL: https://svnweb.freebsd.org/changeset/base/336077
> 
> Log:
>   Move arm- and aarch64-specific manpages into arch-specific directories.
>   
>   This removes a bit of the .if/.endif clutter from man4/Makefile by using
>   the existing machinery that supports per-arch manpages.

Hi Ian,

This breaks arm64 buildworld:

make[8]: make[8]: don't know how to make armv8crypto.4. Stop

-Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r336077 - in head/share/man/man4: . man4.aarch64 man4.arm

[Ravi Pokala]

-Original Message-
From:  on behalf of Ian Lepore 

Date: 2018-07-07, Saturday at 17:02
To: Ravi Pokala , , 
, 
Subject: Re: svn commit: r336077 - in head/share/man/man4: . man4.aarch64 
man4.arm

> On Sat, 2018-07-07 at 16:35 -0700, Ravi Pokala wrote:
>> -Original Message-
>> From:  on behalf of Ian Lepore 
>> Date: 2018-07-07, Saturday at 14:49
>> To: , , 
>> Subject: svn commit: r336077 - in head/share/man/man4: . man4.aarch64 
>> man4.arm
>> 
>>> 
>>> Author: ian
>>> Date: Sat Jul  7 21:49:30 2018
>>> New Revision: 336077
>>> URL: https://svnweb.freebsd.org/changeset/base/336077
>>> 
>>> Log:
>>>   Move arm- and aarch64-specific manpages into arch-specific directories.
>>>   
>>>   This removes a bit of the .if/.endif clutter from man4/Makefile by using
>>>   the existing machinery that supports per-arch manpages.
>> Hi Ian,
>> 
>> This breaks arm64 buildworld:
>> 
>> make[8]: make[8]: don't know how to make armv8crypto.4. Stop
>> 
> 
> Doh!  Fixed in r336078; sorry about that.
> 
> -- Ian

No worries. :-)

Thanks,

Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r336046 - in head/sys: amd64/include i386/include sys

[Ravi Pokala]

-Original Message-
From:  on behalf of "Rodney W. Grimes" 

Reply-To: 
Date: 2018-07-09, Monday at 09:12
To: Ian Lepore 
Cc: Alexey Dokuchaev , Brooks Davis , 
Konstantin Belousov , , 
, 
Subject: Re: svn commit: r336046 - in head/sys: amd64/include i386/include sys

> Or svn could grow the proper features to have immutability, you just
> have to revision control the log entry, something that is at least
> 40 year old technology in the paper world of document control.
> 
> I have never understood why this feature is missing from every
> automated VCS system I have seen.
> 
> -- 
> Rod Grimes rgri...@freebsd.org

FWIW, Perforce allows the log entry to be changed after the submit, and I'm 98% 
sure it's versioned.

-Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r336144 - head/sys/powerpc/powernv

[Ravi Pokala]

-Original Message-
From:  on behalf of Justin Hibbits 

Date: 2018-07-09, Monday at 13:33
To: , , 

Subject: svn commit: r336144 - head/sys/powerpc/powernv

> Author: jhibbits
> Date: Mon Jul  9 20:33:48 2018
> New Revision: 336144
> URL: https://svnweb.freebsd.org/changeset/base/336144
> 
> Log:
>   powerpc/powernv: Make opal_i2c driver work with attached i2c drivers
>   
>   * FreeBSD stores addresses in 8 bit format, but the OPAL API requires the 
> 7-bit
> address, and encodes the direction elsewhere.  Behave like other i2c 
> drivers,
> and shift accordingly.

You got seven contiguous address bits? LUXURY!

Look for "slave" and "write_op" in sys/dev/imcsmb.c:imcsmb_transfer(); it's 
"hilarious".

-Ravi


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r336188 - head/usr.sbin/bhyve

[Ravi Pokala]

Hi Marcelo,

If the intention is to have specific exit codes have specific meanings, 
wouldn't it be useful to set up defines or an enum or something, so a symbolic 
value can be used rather than a bare integer?

Thanks,

Ravi (rpokala@)

-Original Message-
From:  on behalf of Marcelo Araujo 

Date: 2018-07-10, Tuesday at 20:23
To: , , 

Subject: svn commit: r336188 - head/usr.sbin/bhyve

Author: araujo
Date: Wed Jul 11 03:23:09 2018
New Revision: 336188
URL: https://svnweb.freebsd.org/changeset/base/336188

Log:
  Improve bhyve exit(3) error code.
  
  The bhyve(8) exit status indicates how the VM was terminated:
  
  0 rebooted
  1 powered off
  2 halted
  3 triple fault
  
  The problem is when we have wrappers around bhyve that parses the exit
  error code and gets an exit(1) for an error but interprets it as "powered 
off".
  So to mitigate this issue and makes it less error prone for third part
  applications, I have added a new exit code 4 that is "exited due to an error".
  
  For now the bhyve(8) exit status are:
  0 rebooted
  1 powered off
  2 halted
  3 triple fault
  4 exited due to an error
  
  Reviewed by:  @jhb
  MFC after:2 weeks.
  Sponsored by: iXsystems Inc.
  Differential Revision:https://reviews.freebsd.org/D16161

Modified:
  head/usr.sbin/bhyve/bhyve.8
  head/usr.sbin/bhyve/bhyverun.c
  head/usr.sbin/bhyve/dbgport.c
  head/usr.sbin/bhyve/fwctl.c
  head/usr.sbin/bhyve/mevent_test.c
  head/usr.sbin/bhyve/pci_e82545.c

Modified: head/usr.sbin/bhyve/bhyve.8
==
--- head/usr.sbin/bhyve/bhyve.8 Wed Jul 11 02:32:06 2018(r336187)
+++ head/usr.sbin/bhyve/bhyve.8 Wed Jul 11 03:23:09 2018(r336188)
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd Jul 05, 2018
+.Dd Jul 11, 2018
 .Dt BHYVE 8
 .Os
 .Sh NAME
@@ -520,6 +520,8 @@ powered off
 halted
 .It 3
 triple fault
+.It 4
+exited due to an error
 .El
 .Sh EXAMPLES
 If not using a boot ROM, the guest operating system must have been loaded with

Modified: head/usr.sbin/bhyve/bhyverun.c
==
--- head/usr.sbin/bhyve/bhyverun.c  Wed Jul 11 02:32:06 2018
(r336187)
+++ head/usr.sbin/bhyve/bhyverun.c  Wed Jul 11 03:23:09 2018
(r336188)
@@ -397,7 +397,7 @@ fbsdrun_deletecpu(struct vmctx *ctx, int vcpu)
 
if (!CPU_ISSET(vcpu, &cpumask)) {
fprintf(stderr, "Attempting to delete unknown cpu %d\n", vcpu);
-   exit(1);
+   exit(4);
}
 
CPU_CLR_ATOMIC(vcpu, &cpumask);
@@ -742,7 +742,7 @@ vm_loop(struct vmctx *ctx, int vcpu, uint64_t startrip
if (exitcode >= VM_EXITCODE_MAX || handler[exitcode] == NULL) {
fprintf(stderr, "vm_loop: unexpected exitcode 0x%x\n",
exitcode);
-   exit(1);
+   exit(4);
}
 
rc = (*handler[exitcode])(ctx, &vmexit[vcpu], &vcpu);
@@ -753,7 +753,7 @@ vm_loop(struct vmctx *ctx, int vcpu, uint64_t startrip
case VMEXIT_ABORT:
abort();
default:
-   exit(1);
+   exit(4);
}
}
fprintf(stderr, "vm_run error %d, errno %d\n", error, errno);
@@ -785,7 +785,7 @@ fbsdrun_set_capabilities(struct vmctx *ctx, int cpu)
err = vm_get_capability(ctx, cpu, VM_CAP_HALT_EXIT, &tmp);
if (err < 0) {
fprintf(stderr, "VM exit on HLT not supported\n");
-   exit(1);
+   exit(4);
}
vm_set_capability(ctx, cpu, VM_CAP_HALT_EXIT, 1);
if (cpu == BSP)
@@ -800,7 +800,7 @@ fbsdrun_set_capabilities(struct vmctx *ctx, int cpu)
if (err < 0) {
fprintf(stderr,
"SMP mux requested, no pause support\n");
-   exit(1);
+   exit(4);
}
vm_set_capability(ctx, cpu, VM_CAP_PAUSE_EXIT, 1);
if (cpu == BSP)
@@ -814,7 +814,7 @@ fbsdrun_set_capabilities(struct vmctx *ctx, int cpu)
 
if (err) {
fprintf(stderr, "Unable to set x2apic state (%d)\n", err);
-   exit(1);
+   exit(4);
}
 
vm_set_capability(ctx, cpu, VM_CAP_ENABLE_INVPCID, 1);
@@ -850,7 +850,7 @@ do_open(const char *vmname)
}
} else {
perror("vm_create");
-   exit(1);
+   exit(4);
}
} else {
if (!romboot) {
@@ -859,14 +859,14 @@ do_open(const char *vmname)
 * bootrom must be configured to boot it.
 */
f

Re: svn commit: r336348 - in head/sys: conf crypto/armv8 modules/armv8crypto

[Ravi Pokala]

-Original Message-
From:  on behalf of Andrew Turner 

Date: 2018-07-16, Monday at 08:39
To: , , 

Subject: svn commit: r336348 - in head/sys: conf crypto/armv8 
modules/armv8crypto

> Author: andrew
> Date: Mon Jul 16 15:39:33 2018
> New Revision: 336348
> URL: https://svnweb.freebsd.org/changeset/base/336348
> 
> Log:
>   Create an empty stdint.h for arm_neon.h to include.
>   
>   The armv8crypto module includes arm_neon.h for the compiler intrinsic
>   functions. This includes the userland stdint.h file that doesn't exist in
>   the kernel. Fix this by providing an empty stdint.h to be used when we
>   include arm_neon.h.
>   
>   Sponsored by:   DARPA, AFRL
>   Differential Revision:  https://reviews.freebsd.org/D16254

THANK YOU!!!

This one file was preventing being able to do tinderbox with just 
"UNIVERSE_TARGET=kernel-toolchain" followed by "-DMAKE_JUST_KERNELS". I've 
periodically mentioned this for like a year, but lacked the knowledge to fix it 
myself. :-)

-Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r336526 - head

[Ravi Pokala]

Hi Ian,

-Original Message-
From:  on behalf of Ian Lepore 

Date: 2018-07-19, Thursday at 17:44
To: , , 

Subject: svn commit: r336526 - head

> Author: ian
> Date: Fri Jul 20 00:44:04 2018
> New Revision: 336526
> URL: https://svnweb.freebsd.org/changeset/base/336526
> 
> Log:
>   Add ntpd to the list of users/groups to check before installing.
> 
> Modified:
>   head/Makefile.inc1

When trying to installworld:

ERROR: Required ntpd user is missing, see /usr/src/UPDATING.

But there is no UPDATING entry about this. (Also, shouldn't it be 
${SRCTOP}/UPDATING?)

Thanks,

Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r336526 - head

[Ravi Pokala]

-Original Message-
From:  on behalf of Ian Lepore 

Date: 2018-07-20, Friday at 10:38
To: Ravi Pokala , , 
, 
Subject: Re: svn commit: r336526 - head

> On Fri, 2018-07-20 at 09:56 -0700, Ravi Pokala wrote:
>> Hi Ian,
>> 
>> -Original Message-
>> From:  on behalf of Ian Lepore 
>> Date: 2018-07-19, Thursday at 17:44
>> To: , , 
>> Subject: svn commit: r336526 - head
>> 
>>> 
>>> Author: ian
>>> Date: Fri Jul 20 00:44:04 2018
>>> New Revision: 336526
>>> URL: https://svnweb.freebsd.org/changeset/base/336526
>>> 
>>> Log:
>>>   Add ntpd to the list of users/groups to check before installing.
>>> 
>>> Modified:
>>>   head/Makefile.inc1
>> When trying to installworld:
>> 
>> ERROR: Required ntpd user is missing, see /usr/src/UPDATING.
>> 
>> But there is no UPDATING entry about this. (Also, shouldn't it be 
>> ${SRCTOP}/UPDATING?)
>> 
>> Thanks,
>> 
>> Ravi (rpokala@)
> 
> I wondered about that too, when I accidentally stumbled across the
> CHECK_UIDS thing and realized I should add ntpd to it. I searched in
> UPDATING for some of the other things in the CHECK_UIDS list to see
> what had been said about such changes in the past, even searching
> through old-old svn history, and found nothing.
> 
> I finally settled on the thought that the reference to UPDATING was to
> the stuff at the bottom that never changes. In particular to the
> section around line 1595 that documents the instalkernel, reboot,
> mergemaster, installworld sequence. The mergemaster part should take
> care of the new userid, I guess.
> 
> -- Ian

Interesting. I was attempting the install via the `beinstall.sh' script. CCing 
will@, since he wrote it.

Thanks,

Ravi (rpokala@)


___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r336662 - in head: share/man/man4 sys/dev/jedec_ts

[Ravi Pokala]

Author: rpokala
Date: Tue Jul 24 08:15:02 2018
New Revision: 336662
URL: https://svnweb.freebsd.org/changeset/base/336662

Log:
  Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead
  
  jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
  jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
  instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
  the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
  fact that it is a superset of jedec_ts(4).
  
  This change will be MFCed to stable/11 and stable/10; the followup change
  to actually remove jedec_ts(4) from -HEAD will not.
  
  Reviewed by:  avg
  MFC after:1 week
  Relnotes: yes
  Differential Revision:https://reviews.freebsd.org/D16412

Modified:
  head/share/man/man4/jedec_dimm.4
  head/share/man/man4/jedec_ts.4
  head/sys/dev/jedec_ts/jedec_ts.c

Modified: head/share/man/man4/jedec_dimm.4
==
--- head/share/man/man4/jedec_dimm.4Tue Jul 24 05:09:50 2018
(r336661)
+++ head/share/man/man4/jedec_dimm.4Tue Jul 24 08:15:02 2018
(r336662)
@@ -163,6 +163,9 @@ dev.jedec_dimm.6.temp: 43.1C
 dev.jedec_dimm.6.type: DDR4
 .Ed
 .Sh COMPATIBILITY
+.Nm
+implements a superset of the functionality of
+.Xr jedec_ts 4 .
 Hints for
 .Xr jedec_ts 4
 can be mechanically converted for use with

Modified: head/share/man/man4/jedec_ts.4
==
--- head/share/man/man4/jedec_ts.4  Tue Jul 24 05:09:50 2018
(r336661)
+++ head/share/man/man4/jedec_ts.4  Tue Jul 24 08:15:02 2018
(r336662)
@@ -63,6 +63,18 @@ In
 .Cd hint.jedec_ts.7.at="smbus0"
 .Cd hint.jedec_ts.7.addr="0x3E"
 .Ed
+.Sh DEPRECATION NOTICE
+The
+.Nm
+driver is not present in
+.Fx 12.0
+and later.
+A superset of its functionality is available in the
+.Xr jedec_dimm 4
+driver.
+That driver's manpage includes instructions on updating
+.Pa /boot/device.hints
+accordingly.
 .Sh DESCRIPTION
 The
 .Nm

Modified: head/sys/dev/jedec_ts/jedec_ts.c
==
--- head/sys/dev/jedec_ts/jedec_ts.cTue Jul 24 05:09:50 2018
(r336661)
+++ head/sys/dev/jedec_ts/jedec_ts.cTue Jul 24 08:15:02 2018
(r336662)
@@ -247,6 +247,9 @@ ts_attach(device_t dev)
CTLTYPE_INT | CTLFLAG_RD | CTLFLAG_MPSAFE, dev, 0,
ts_temp_sysctl, "IK4", "Current temperature");
 
+   gone_in_dev(dev, 12,
+   "jedec_ts(4) driver; see COMPATIBILITY section of jedec_dimm(4)");
+
return (0);
 }
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"