svn commit: r312369 - head/sys/powerpc/aim

[Justin Hibbits]

Author: jhibbits
Date: Wed Jan 18 03:42:21 2017
New Revision: 312369
URL: https://svnweb.freebsd.org/changeset/base/312369

Log:
  Use the explicit expanded form of cmp.
  
  Clang apparently requires the explicit form of this instruction, and rejects
  uses which ignore the optional cmpD register.  This was the only use of the
  shorthand form of the instruction, so just fix it up to match the others.
  
  PR:   kern/215681
  Submitted by: Mark Millard
  Reported by:  Mark Millard 
  MFC after:2 weeks

Modified:
  head/sys/powerpc/aim/trap_subr32.S

Modified: head/sys/powerpc/aim/trap_subr32.S
==
--- head/sys/powerpc/aim/trap_subr32.S  Wed Jan 18 03:35:42 2017
(r312368)
+++ head/sys/powerpc/aim/trap_subr32.S  Wed Jan 18 03:42:21 2017
(r312369)
@@ -406,7 +406,7 @@ im0:
mtctr %r1   /* load counter */
 im1:
lwzu %r1, 8(%r2)/* get next pte */
-   cmp 0, %r1, %r3 /* see if found pte */
+   cmp 0, 0, %r1, %r3  /* see if found pte */
bdnzf 2, im1/* dec count br if cmp ne and if
 * count not zero */
bne instr_sec_hash  /* if not found set up second 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"

svn commit: r312368 - head/sys/dev/cxgbe/tom

[Navdeep Parhar]

Author: np
Date: Wed Jan 18 03:35:42 2017
New Revision: 312368
URL: https://svnweb.freebsd.org/changeset/base/312368

Log:
  cxgbe/tom: Fix a case where do_pass_accept_req wasn't properly restoring
  the VNET.  This should have been in r311949.
  
  MFC after:2 days

Modified:
  head/sys/dev/cxgbe/tom/t4_listen.c

Modified: head/sys/dev/cxgbe/tom/t4_listen.c
==
--- head/sys/dev/cxgbe/tom/t4_listen.c  Wed Jan 18 02:57:22 2017
(r312367)
+++ head/sys/dev/cxgbe/tom/t4_listen.c  Wed Jan 18 03:35:42 2017
(r312368)
@@ -1418,6 +1418,7 @@ found:
if (!(synqe->flags & TPF_SYNQE_EXPANDED))
send_reset_synqe(tod, synqe);
INP_WUNLOCK(inp);
+   CURVNET_RESTORE();
 
release_synqe(synqe);   /* extra hold */
return (__LINE__);
___
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: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Ngie Cooper (yaneurabeya)]

> On Jan 17, 2017, at 17:42, Daniel Eischen  wrote:
> 
> On Tue, 17 Jan 2017, Maxim Sobolev wrote:
> 
>> Also there is at least one thing that makes enum less desirable from the
>> point of view of application developer. Particularly it makes it impossible
>> to use preprocessor to do a conditional compilation, which is especially
>> important for the FreeBSD-specific options. With the "old" way, I can
>> easily have something like:
>> 
>> #if defined(SO_TS_CLOCK)
>> ...
>> setsockopt(SO_TS_CLOCK, ...);
>> #else
>> [do something else]
>> #endif
>> 
>> This does not work with enums for obvious reasons, one would need to resort
>> to using some kind of autoconfigure mechanism to figure out if the enum in
>> question is defined.
> 
> Great point, we (at $JOB) have code that this, and would break
> if changed to enums.

I’m not saying enums would be a bad idea, but it would require more 
work on the autoconf end as well, and would make testing for these symbols' 
support a little less straightforward.
Maybe a combination of #define’s for determining whether or not the 
support is present, i.e. for simple #ifdef folks (I would probably only use one 
though), and having a sample for testing for support in autoconf in some 
products would be beneficial?
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Daniel Eischen]

On Tue, 17 Jan 2017, Maxim Sobolev wrote:


Also there is at least one thing that makes enum less desirable from the
point of view of application developer. Particularly it makes it impossible
to use preprocessor to do a conditional compilation, which is especially
important for the FreeBSD-specific options. With the "old" way, I can
easily have something like:

#if defined(SO_TS_CLOCK)
...
setsockopt(SO_TS_CLOCK, ...);
#else
[do something else]
#endif

This does not work with enums for obvious reasons, one would need to resort
to using some kind of autoconfigure mechanism to figure out if the enum in
question is defined.


Great point, we (at $JOB) have code that this, and would break
if changed to enums.

--
DE
___
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: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Maxim Sobolev]

OK, guys, with all due respect I think I've heard enough to say that if
somebody feels like this has to be enum feel free to jump in and tweak it
out. As far as I understand there should be no user-visible differences
either way, so it's not like we are going to be locked with this way
forever. It's never too late to revise it (and it's FreeBSD-specific
interface as well). Requesting me to implement something that it is at
least a bit controversial and also something completely orthogonal to the
original functionality and which I have no idea how to do/test properly on
top of what's been done already is a bit overboard I would say.

In my view, if we are to convert set/getsockopt(2) to enums it has to do in
one shot and tested against large set of third-party software to make sure
it won't bring out some corner cases (i.e. some unhandled values in
switch() statements and the likes, C++ breakage, weird compilers, #ifdef
blocks etc). If some developer(s) feel #define is an old way no longer
relevant in 2017 the onus has to be on those to come up with a patch and go
though the heat of defending it against other set of developers who don't
share that opinion. Pushing me, who is largely ambivalent to either way, to
do it is not fair. It's like asking mechanic who works on fixing
your brakes to also paint your calipers for aesthetic reasons for the same
price. Not even to mention that the change in question has been on reviews
and received positive feedback from other developers working in the same
area (e.g. gnn) and none of the enum guys paid any attention until it hit
the tree.

Also there is at least one thing that makes enum less desirable from the
point of view of application developer. Particularly it makes it impossible
to use preprocessor to do a conditional compilation, which is especially
important for the FreeBSD-specific options. With the "old" way, I can
easily have something like:

#if defined(SO_TS_CLOCK)
...
setsockopt(SO_TS_CLOCK, ...);
#else
[do something else]
#endif

This does not work with enums for obvious reasons, one would need to resort
to using some kind of autoconfigure mechanism to figure out if the enum in
question is defined.

-Max

On Tue, Jan 17, 2017 at 3:52 PM, Ian Lepore  wrote:

> I actually don't agree that it's all good, but I also don't have the
> time to prove it's not (or prove myself wrong, which could certainly be
> the case).
>
> -- Ian
>
> On Tue, 2017-01-17 at 15:21 -0800, Conrad Meyer wrote:
> > Ian's potential objection has been met by Ben Kaduk and Eric van
> > Gyzen's responses.  It seems like an enum is just fine.  And I agree
> > with Gleb that it is preferable.
> >
> > Conrad
> >
> > On Tue, Jan 17, 2017 at 1:34 PM, Maxim Sobolev 
> > wrote:
> > >
> > > Well as other pointed out there are some concerns with using enums
> > > from C++
> > > and ABI prospective. So it looks to me that there is no general
> > > consensus on
> > > that direction.
> > >
> > > -Max
> > >
> > > On Tue, Jan 17, 2017 at 1:27 PM, Gleb Smirnoff  > > > wrote:
> > > >
> > > >
> > > > On Tue, Jan 17, 2017 at 08:40:50AM -0800, Maxim Sobolev wrote:
> > > > M> That being said, is there any other socket option value in
> > > > there
> > > > M> implemented as enum? I don't see anything obvious, so that I
> > > > am curious
> > > > if
> > > > M> it would stick out as an odd one in there. What do you think?
> > > >
> > > > Simply because 30 years ago the language didn't allow that, and
> > > > later
> > > > additions mimiced the older sockopts. We need to break this loop
> > > > :)
> > > >
> > > > --
> > > > Totus tuus, Glebius.
> > > >
>
>
___
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: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Ian Lepore]

I actually don't agree that it's all good, but I also don't have the
time to prove it's not (or prove myself wrong, which could certainly be
the case).

-- Ian

On Tue, 2017-01-17 at 15:21 -0800, Conrad Meyer wrote:
> Ian's potential objection has been met by Ben Kaduk and Eric van
> Gyzen's responses.  It seems like an enum is just fine.  And I agree
> with Gleb that it is preferable.
> 
> Conrad
> 
> On Tue, Jan 17, 2017 at 1:34 PM, Maxim Sobolev 
> wrote:
> > 
> > Well as other pointed out there are some concerns with using enums
> > from C++
> > and ABI prospective. So it looks to me that there is no general
> > consensus on
> > that direction.
> > 
> > -Max
> > 
> > On Tue, Jan 17, 2017 at 1:27 PM, Gleb Smirnoff  > > wrote:
> > > 
> > > 
> > > On Tue, Jan 17, 2017 at 08:40:50AM -0800, Maxim Sobolev wrote:
> > > M> That being said, is there any other socket option value in
> > > there
> > > M> implemented as enum? I don't see anything obvious, so that I
> > > am curious
> > > if
> > > M> it would stick out as an odd one in there. What do you think?
> > > 
> > > Simply because 30 years ago the language didn't allow that, and
> > > later
> > > additions mimiced the older sockopts. We need to break this loop
> > > :)
> > > 
> > > --
> > > Totus tuus, Glebius.
> > > 
___
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: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Conrad Meyer]

Ian's potential objection has been met by Ben Kaduk and Eric van
Gyzen's responses.  It seems like an enum is just fine.  And I agree
with Gleb that it is preferable.

Conrad

On Tue, Jan 17, 2017 at 1:34 PM, Maxim Sobolev  wrote:
> Well as other pointed out there are some concerns with using enums from C++
> and ABI prospective. So it looks to me that there is no general consensus on
> that direction.
>
> -Max
>
> On Tue, Jan 17, 2017 at 1:27 PM, Gleb Smirnoff  wrote:
>>
>> On Tue, Jan 17, 2017 at 08:40:50AM -0800, Maxim Sobolev wrote:
>> M> That being said, is there any other socket option value in there
>> M> implemented as enum? I don't see anything obvious, so that I am curious
>> if
>> M> it would stick out as an odd one in there. What do you think?
>>
>> Simply because 30 years ago the language didn't allow that, and later
>> additions mimiced the older sockopts. We need to break this loop :)
>>
>> --
>> Totus tuus, Glebius.
>>
>
___
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: r312355 - in head/sys: amd64/cloudabi32 amd64/cloudabi64 arm/cloudabi32 arm64/cloudabi64 compat/cloudabi compat/cloudabi32 compat/cloudabi64 i386/cloudabi32

[Ed Schouten]

Author: ed
Date: Tue Jan 17 22:05:52 2017
New Revision: 312355
URL: https://svnweb.freebsd.org/changeset/base/312355

Log:
  Catch up with changes to structure member names.
  
  Pointer/length pairs are now always named ${name} and ${name}_len.

Modified:
  head/sys/amd64/cloudabi32/cloudabi32_sysvec.c
  head/sys/amd64/cloudabi64/cloudabi64_sysvec.c
  head/sys/arm/cloudabi32/cloudabi32_sysvec.c
  head/sys/arm64/cloudabi64/cloudabi64_sysvec.c
  head/sys/compat/cloudabi/cloudabi_file.c
  head/sys/compat/cloudabi/cloudabi_mem.c
  head/sys/compat/cloudabi/cloudabi_proc.c
  head/sys/compat/cloudabi/cloudabi_random.c
  head/sys/compat/cloudabi/cloudabi_sock.c
  head/sys/compat/cloudabi32/cloudabi32_fd.c
  head/sys/compat/cloudabi32/cloudabi32_poll.c
  head/sys/compat/cloudabi32/cloudabi32_sock.c
  head/sys/compat/cloudabi32/cloudabi32_thread.c
  head/sys/compat/cloudabi64/cloudabi64_fd.c
  head/sys/compat/cloudabi64/cloudabi64_poll.c
  head/sys/compat/cloudabi64/cloudabi64_sock.c
  head/sys/compat/cloudabi64/cloudabi64_thread.c
  head/sys/i386/cloudabi32/cloudabi32_sysvec.c

Modified: head/sys/amd64/cloudabi32/cloudabi32_sysvec.c
==
--- head/sys/amd64/cloudabi32/cloudabi32_sysvec.c   Tue Jan 17 22:05:01 
2017(r312354)
+++ head/sys/amd64/cloudabi32/cloudabi32_sysvec.c   Tue Jan 17 22:05:52 
2017(r312355)
@@ -181,7 +181,7 @@ cloudabi32_thread_setregs(struct thread 
 
/* Perform standard register initialization. */
stack.ss_sp = TO_PTR(attr->stack);
-   stack.ss_size = attr->stack_size - sizeof(args);
+   stack.ss_size = attr->stack_len - sizeof(args);
cpu_set_upcall(td, TO_PTR(attr->entry_point), NULL, );
 
/*

Modified: head/sys/amd64/cloudabi64/cloudabi64_sysvec.c
==
--- head/sys/amd64/cloudabi64/cloudabi64_sysvec.c   Tue Jan 17 22:05:01 
2017(r312354)
+++ head/sys/amd64/cloudabi64/cloudabi64_sysvec.c   Tue Jan 17 22:05:52 
2017(r312355)
@@ -164,7 +164,7 @@ cloudabi64_thread_setregs(struct thread 
 * from the top of the stack to store a single element array,
 * containing a pointer to the TCB. %fs base will point to this.
 */
-   tcbptr = rounddown(attr->stack + attr->stack_size - sizeof(tcbptr),
+   tcbptr = rounddown(attr->stack + attr->stack_len - sizeof(tcbptr),
_Alignof(tcbptr));
error = copyout(, (void *)tcbptr, sizeof(tcb));
if (error != 0)

Modified: head/sys/arm/cloudabi32/cloudabi32_sysvec.c
==
--- head/sys/arm/cloudabi32/cloudabi32_sysvec.c Tue Jan 17 22:05:01 2017
(r312354)
+++ head/sys/arm/cloudabi32/cloudabi32_sysvec.c Tue Jan 17 22:05:52 2017
(r312355)
@@ -148,7 +148,7 @@ cloudabi32_thread_setregs(struct thread 
 
/* Perform standard register initialization. */
stack.ss_sp = TO_PTR(attr->stack);
-   stack.ss_size = attr->stack_size;
+   stack.ss_size = attr->stack_len;
cpu_set_upcall(td, TO_PTR(attr->entry_point), NULL, );
 
/*

Modified: head/sys/arm64/cloudabi64/cloudabi64_sysvec.c
==
--- head/sys/arm64/cloudabi64/cloudabi64_sysvec.c   Tue Jan 17 22:05:01 
2017(r312354)
+++ head/sys/arm64/cloudabi64/cloudabi64_sysvec.c   Tue Jan 17 22:05:52 
2017(r312355)
@@ -140,7 +140,7 @@ cloudabi64_thread_setregs(struct thread 
 
/* Perform standard register initialization. */
stack.ss_sp = TO_PTR(attr->stack);
-   stack.ss_size = attr->stack_size;
+   stack.ss_size = attr->stack_len;
cpu_set_upcall(td, TO_PTR(attr->entry_point), NULL, );
 
/*

Modified: head/sys/compat/cloudabi/cloudabi_file.c
==
--- head/sys/compat/cloudabi/cloudabi_file.cTue Jan 17 22:05:01 2017
(r312354)
+++ head/sys/compat/cloudabi/cloudabi_file.cTue Jan 17 22:05:52 2017
(r312355)
@@ -146,7 +146,7 @@ cloudabi_sys_file_create(struct thread *
char *path;
int error;
 
-   error = copyin_path(uap->path, uap->pathlen, );
+   error = copyin_path(uap->path, uap->path_len, );
if (error != 0)
return (error);
 
@@ -177,10 +177,10 @@ cloudabi_sys_file_link(struct thread *td
char *path1, *path2;
int error;
 
-   error = copyin_path(uap->path1, uap->path1len, );
+   error = copyin_path(uap->path1, uap->path1_len, );
if (error != 0)
return (error);
-   error = copyin_path(uap->path2, uap->path2len, );
+   error = copyin_path(uap->path2, uap->path2_len, );
if (error != 0) {
cloudabi_freestr(path1);
return (error);
@@ -261,7 +261,7 @@ 

svn commit: r312354 - in head/sys/compat: cloudabi32 cloudabi64

[Ed Schouten]

Author: ed
Date: Tue Jan 17 22:05:01 2017
New Revision: 312354
URL: https://svnweb.freebsd.org/changeset/base/312354

Log:
  Regenerate sources based on the system call tables.

Modified:
  head/sys/compat/cloudabi32/cloudabi32_proto.h
  head/sys/compat/cloudabi32/cloudabi32_syscall.h
  head/sys/compat/cloudabi32/cloudabi32_syscalls.c
  head/sys/compat/cloudabi32/cloudabi32_sysent.c
  head/sys/compat/cloudabi32/cloudabi32_systrace_args.c
  head/sys/compat/cloudabi64/cloudabi64_proto.h
  head/sys/compat/cloudabi64/cloudabi64_syscall.h
  head/sys/compat/cloudabi64/cloudabi64_syscalls.c
  head/sys/compat/cloudabi64/cloudabi64_sysent.c
  head/sys/compat/cloudabi64/cloudabi64_systrace_args.c

Modified: head/sys/compat/cloudabi32/cloudabi32_proto.h
==
--- head/sys/compat/cloudabi32/cloudabi32_proto.h   Tue Jan 17 22:03:08 
2017(r312353)
+++ head/sys/compat/cloudabi32/cloudabi32_proto.h   Tue Jan 17 22:05:01 
2017(r312354)
@@ -3,7 +3,7 @@
  *
  * DO NOT EDIT-- this file is automatically generated.
  * $FreeBSD$
- * created from FreeBSD: head/sys/contrib/cloudabi/syscalls32.master 304563 
2016-08-21 15:56:19Z ed 
+ * created from FreeBSD: head/sys/contrib/cloudabi/syscalls32.master 312353 
2017-01-17 22:03:08Z ed
  */
 
 #ifndef _CLOUDABI32_SYSPROTO_H_
@@ -63,20 +63,20 @@ struct cloudabi_sys_fd_dup_args {
 };
 struct cloudabi32_sys_fd_pread_args {
char fd_l_[PADL_(cloudabi_fd_t)]; cloudabi_fd_t fd; char 
fd_r_[PADR_(cloudabi_fd_t)];
-   char iov_l_[PADL_(const cloudabi32_iovec_t *)]; const 
cloudabi32_iovec_t * iov; char iov_r_[PADR_(const cloudabi32_iovec_t *)];
-   char iovcnt_l_[PADL_(size_t)]; size_t iovcnt; char 
iovcnt_r_[PADR_(size_t)];
+   char iovs_l_[PADL_(const cloudabi32_iovec_t *)]; const 
cloudabi32_iovec_t * iovs; char iovs_r_[PADR_(const cloudabi32_iovec_t *)];
+   char iovs_len_l_[PADL_(size_t)]; size_t iovs_len; char 
iovs_len_r_[PADR_(size_t)];
char offset_l_[PADL_(cloudabi_filesize_t)]; cloudabi_filesize_t offset; 
char offset_r_[PADR_(cloudabi_filesize_t)];
 };
 struct cloudabi32_sys_fd_pwrite_args {
char fd_l_[PADL_(cloudabi_fd_t)]; cloudabi_fd_t fd; char 
fd_r_[PADR_(cloudabi_fd_t)];
-   char iov_l_[PADL_(const cloudabi32_ciovec_t *)]; const 
cloudabi32_ciovec_t * iov; char iov_r_[PADR_(const cloudabi32_ciovec_t *)];
-   char iovcnt_l_[PADL_(size_t)]; size_t iovcnt; char 
iovcnt_r_[PADR_(size_t)];
+   char iovs_l_[PADL_(const cloudabi32_ciovec_t *)]; const 
cloudabi32_ciovec_t * iovs; char iovs_r_[PADR_(const cloudabi32_ciovec_t *)];
+   char iovs_len_l_[PADL_(size_t)]; size_t iovs_len; char 
iovs_len_r_[PADR_(size_t)];
char offset_l_[PADL_(cloudabi_filesize_t)]; cloudabi_filesize_t offset; 
char offset_r_[PADR_(cloudabi_filesize_t)];
 };
 struct cloudabi32_sys_fd_read_args {
char fd_l_[PADL_(cloudabi_fd_t)]; cloudabi_fd_t fd; char 
fd_r_[PADR_(cloudabi_fd_t)];
-   char iov_l_[PADL_(const cloudabi32_iovec_t *)]; const 
cloudabi32_iovec_t * iov; char iov_r_[PADR_(const cloudabi32_iovec_t *)];
-   char iovcnt_l_[PADL_(size_t)]; size_t iovcnt; char 
iovcnt_r_[PADR_(size_t)];
+   char iovs_l_[PADL_(const cloudabi32_iovec_t *)]; const 
cloudabi32_iovec_t * iovs; char iovs_r_[PADR_(const cloudabi32_iovec_t *)];
+   char iovs_len_l_[PADL_(size_t)]; size_t iovs_len; char 
iovs_len_r_[PADR_(size_t)];
 };
 struct cloudabi_sys_fd_replace_args {
char from_l_[PADL_(cloudabi_fd_t)]; cloudabi_fd_t from; char 
from_r_[PADR_(cloudabi_fd_t)];
@@ -101,8 +101,8 @@ struct cloudabi_sys_fd_sync_args {
 };
 struct cloudabi32_sys_fd_write_args {
char fd_l_[PADL_(cloudabi_fd_t)]; cloudabi_fd_t fd; char 
fd_r_[PADR_(cloudabi_fd_t)];
-   char iov_l_[PADL_(const cloudabi32_ciovec_t *)]; const 
cloudabi32_ciovec_t * iov; char iov_r_[PADR_(const cloudabi32_ciovec_t *)];
-   char iovcnt_l_[PADL_(size_t)]; size_t iovcnt; char 
iovcnt_r_[PADR_(size_t)];
+   char iovs_l_[PADL_(const cloudabi32_ciovec_t *)]; const 
cloudabi32_ciovec_t * iovs; char iovs_r_[PADR_(const cloudabi32_ciovec_t *)];
+   char iovs_len_l_[PADL_(size_t)]; size_t iovs_len; char 
iovs_len_r_[PADR_(size_t)];
 };
 struct cloudabi_sys_file_advise_args {
char fd_l_[PADL_(cloudabi_fd_t)]; cloudabi_fd_t fd; char 
fd_r_[PADR_(cloudabi_fd_t)];
@@ -118,44 +118,44 @@ struct cloudabi_sys_file_allocate_args {
 struct cloudabi_sys_file_create_args {
char fd_l_[PADL_(cloudabi_fd_t)]; cloudabi_fd_t fd; char 
fd_r_[PADR_(cloudabi_fd_t)];
char path_l_[PADL_(const char *)]; const char * path; char 
path_r_[PADR_(const char *)];
-   char pathlen_l_[PADL_(size_t)]; size_t pathlen; char 
pathlen_r_[PADR_(size_t)];
+   char path_len_l_[PADL_(size_t)]; size_t path_len; char 
path_len_r_[PADR_(size_t)];
char type_l_[PADL_(cloudabi_filetype_t)]; cloudabi_filetype_t type; 
char type_r_[PADR_(cloudabi_filetype_t)];
 };
 struct 

svn commit: r312353 - head/sys/contrib/cloudabi

[Ed Schouten]

Author: ed
Date: Tue Jan 17 22:03:08 2017
New Revision: 312353
URL: https://svnweb.freebsd.org/changeset/base/312353

Log:
  Sync in the latest CloudABI generated source files.
  
  Languages like C++17 and Go provide direct support for slice types:
  pointer/length pairs. The CloudABI generator now has more complete for
  this, meaning that for the C binding, pointer/length pairs now use an
  automatic naming scheme of ${name} and ${name}_len.
  
  Apart from this change and some reformatting, the ABI definitions are
  identical. Binary compatibility is preserved entirely.

Modified:
  head/sys/contrib/cloudabi/cloudabi32_types.h
  head/sys/contrib/cloudabi/cloudabi64_types.h
  head/sys/contrib/cloudabi/cloudabi_types_common.h
  head/sys/contrib/cloudabi/syscalls32.master
  head/sys/contrib/cloudabi/syscalls64.master

Modified: head/sys/contrib/cloudabi/cloudabi32_types.h
==
--- head/sys/contrib/cloudabi/cloudabi32_types.hTue Jan 17 22:02:22 
2017(r312352)
+++ head/sys/contrib/cloudabi/cloudabi32_types.hTue Jan 17 22:03:08 
2017(r312353)
@@ -44,11 +44,11 @@ _Static_assert(sizeof(cloudabi32_auxv_t)
 _Static_assert(_Alignof(cloudabi32_auxv_t) == 4, "Incorrect layout");
 
 typedef struct {
-  _Alignas(4) uint32_t iov_base;
-  _Alignas(4) uint32_t iov_len;
+  _Alignas(4) uint32_t buf;
+  _Alignas(4) uint32_t buf_len;
 } cloudabi32_ciovec_t;
-_Static_assert(offsetof(cloudabi32_ciovec_t, iov_base) == 0, "Incorrect 
layout");
-_Static_assert(offsetof(cloudabi32_ciovec_t, iov_len) == 4, "Incorrect 
layout");
+_Static_assert(offsetof(cloudabi32_ciovec_t, buf) == 0, "Incorrect layout");
+_Static_assert(offsetof(cloudabi32_ciovec_t, buf_len) == 4, "Incorrect 
layout");
 _Static_assert(sizeof(cloudabi32_ciovec_t) == 8, "Incorrect layout");
 _Static_assert(_Alignof(cloudabi32_ciovec_t) == 4, "Incorrect layout");
 
@@ -94,11 +94,11 @@ _Static_assert(sizeof(cloudabi32_event_t
 _Static_assert(_Alignof(cloudabi32_event_t) == 8, "Incorrect layout");
 
 typedef struct {
-  _Alignas(4) uint32_t iov_base;
-  _Alignas(4) uint32_t iov_len;
+  _Alignas(4) uint32_t buf;
+  _Alignas(4) uint32_t buf_len;
 } cloudabi32_iovec_t;
-_Static_assert(offsetof(cloudabi32_iovec_t, iov_base) == 0, "Incorrect 
layout");
-_Static_assert(offsetof(cloudabi32_iovec_t, iov_len) == 4, "Incorrect layout");
+_Static_assert(offsetof(cloudabi32_iovec_t, buf) == 0, "Incorrect layout");
+_Static_assert(offsetof(cloudabi32_iovec_t, buf_len) == 4, "Incorrect layout");
 _Static_assert(sizeof(cloudabi32_iovec_t) == 8, "Incorrect layout");
 _Static_assert(_Alignof(cloudabi32_iovec_t) == 4, "Incorrect layout");
 
@@ -106,30 +106,30 @@ typedef void cloudabi32_processentry_t(u
 
 typedef struct {
   _Alignas(4) uint32_t ri_data;
-  _Alignas(4) uint32_t ri_datalen;
+  _Alignas(4) uint32_t ri_data_len;
   _Alignas(4) uint32_t ri_fds;
-  _Alignas(4) uint32_t ri_fdslen;
+  _Alignas(4) uint32_t ri_fds_len;
   _Alignas(2) cloudabi_msgflags_t ri_flags;
 } cloudabi32_recv_in_t;
 _Static_assert(offsetof(cloudabi32_recv_in_t, ri_data) == 0, "Incorrect 
layout");
-_Static_assert(offsetof(cloudabi32_recv_in_t, ri_datalen) == 4, "Incorrect 
layout");
+_Static_assert(offsetof(cloudabi32_recv_in_t, ri_data_len) == 4, "Incorrect 
layout");
 _Static_assert(offsetof(cloudabi32_recv_in_t, ri_fds) == 8, "Incorrect 
layout");
-_Static_assert(offsetof(cloudabi32_recv_in_t, ri_fdslen) == 12, "Incorrect 
layout");
+_Static_assert(offsetof(cloudabi32_recv_in_t, ri_fds_len) == 12, "Incorrect 
layout");
 _Static_assert(offsetof(cloudabi32_recv_in_t, ri_flags) == 16, "Incorrect 
layout");
 _Static_assert(sizeof(cloudabi32_recv_in_t) == 20, "Incorrect layout");
 _Static_assert(_Alignof(cloudabi32_recv_in_t) == 4, "Incorrect layout");
 
 typedef struct {
   _Alignas(4) uint32_t si_data;
-  _Alignas(4) uint32_t si_datalen;
+  _Alignas(4) uint32_t si_data_len;
   _Alignas(4) uint32_t si_fds;
-  _Alignas(4) uint32_t si_fdslen;
+  _Alignas(4) uint32_t si_fds_len;
   _Alignas(2) cloudabi_msgflags_t si_flags;
 } cloudabi32_send_in_t;
 _Static_assert(offsetof(cloudabi32_send_in_t, si_data) == 0, "Incorrect 
layout");
-_Static_assert(offsetof(cloudabi32_send_in_t, si_datalen) == 4, "Incorrect 
layout");
+_Static_assert(offsetof(cloudabi32_send_in_t, si_data_len) == 4, "Incorrect 
layout");
 _Static_assert(offsetof(cloudabi32_send_in_t, si_fds) == 8, "Incorrect 
layout");
-_Static_assert(offsetof(cloudabi32_send_in_t, si_fdslen) == 12, "Incorrect 
layout");
+_Static_assert(offsetof(cloudabi32_send_in_t, si_fds_len) == 12, "Incorrect 
layout");
 _Static_assert(offsetof(cloudabi32_send_in_t, si_flags) == 16, "Incorrect 
layout");
 _Static_assert(sizeof(cloudabi32_send_in_t) == 20, "Incorrect layout");
 _Static_assert(_Alignof(cloudabi32_send_in_t) == 4, "Incorrect layout");
@@ -219,12 +219,12 @@ _Static_assert(_Alignof(cloudabi32_recv_
 typedef struct {
   _Alignas(4) uint32_t entry_point;
   

Re: svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Maxim Sobolev]

Well as other pointed out there are some concerns with using enums from C++
and ABI prospective. So it looks to me that there is no general consensus
on that direction.

-Max

On Tue, Jan 17, 2017 at 1:27 PM, Gleb Smirnoff  wrote:

> On Tue, Jan 17, 2017 at 08:40:50AM -0800, Maxim Sobolev wrote:
> M> That being said, is there any other socket option value in there
> M> implemented as enum? I don't see anything obvious, so that I am curious
> if
> M> it would stick out as an odd one in there. What do you think?
>
> Simply because 30 years ago the language didn't allow that, and later
> additions mimiced the older sockopts. We need to break this loop :)
>
> --
> Totus tuus, Glebius.
>
>
___
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: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Gleb Smirnoff]

On Tue, Jan 17, 2017 at 08:40:50AM -0800, Maxim Sobolev wrote:
M> That being said, is there any other socket option value in there
M> implemented as enum? I don't see anything obvious, so that I am curious if
M> it would stick out as an odd one in there. What do you think?

Simply because 30 years ago the language didn't allow that, and later
additions mimiced the older sockopts. We need to break this loop :)

-- 
Totus tuus, Glebius.
___
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: r312350 - head/sys/conf

[Bryan Drewery]

Author: bdrewery
Date: Tue Jan 17 21:12:21 2017
New Revision: 312350
URL: https://svnweb.freebsd.org/changeset/base/312350

Log:
  Don't compute MPATH during install.
  
  This saves time when building over NFS.  Nothing should be building during
  this phase anyhow.
  
  Sponsored by: Dell EMC Isilon

Modified:
  head/sys/conf/kern.pre.mk

Modified: head/sys/conf/kern.pre.mk
==
--- head/sys/conf/kern.pre.mk   Tue Jan 17 19:19:29 2017(r312349)
+++ head/sys/conf/kern.pre.mk   Tue Jan 17 21:12:21 2017(r312350)
@@ -192,7 +192,7 @@ SYSTEM_LD_TAIL= @${OBJCOPY} --strip-symb
 SYSTEM_DEP+= ${LDSCRIPT}
 
 # Calculate path for .m files early, if needed.
-.if !defined(NO_MODULES) && !defined(__MPATH)
+.if !defined(NO_MODULES) && !defined(__MPATH) && !make(install)
 __MPATH!=find ${S:tA}/ -name \*_if.m
 .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: r312236 - head/sys/net80211

[Andriy Gapon]

On 15/01/2017 22:43, Adrian Chadd wrote:
> On 15 January 2017 at 11:56, Ian Lepore  wrote:
> 
>>
>> What is the point of the !! in these macros?  The expressions already
>> have boolean type (even in C++ where it matters) due to the ==.
>>  Removing the !! would also make one level of parens redundant.
> 
> It's just a habit i picked up from linux-land. That way it really is
> only 1 or 0, so things like debugging output and such make easier
> sense.

Well, that habit is useful when applied to results of bit-wise operations.
It does nothing but obfuscating the code when applied to results of logical
operations.  Which is the case here.
And even with the bit-wise operation we have a FreeBSD idiom of comparing the
result with zero using != 0.  More verbose, but also more stylish.

> It's also fixed a handful of bugs in the past (but I can't think of
> exact cases right now) - primarily where other code expected 1 or 0
> (for things like shifts into protocol fields) and the macro returns 0
> or ${LARGEVAL}.


-- 
Andriy Gapon
___
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: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Eric van Gyzen]

On 01/17/2017 11:48, Benjamin Kaduk wrote:
> On Tue, Jan 17, 2017 at 10:57 AM, Ian Lepore  > wrote:
> 
> In my experience, enums are a superior way to define integer constants
> (compared to #define), but they are pure poison as variable types in
> APIs and structures because their size is a compiler implementation
> choice.
> 
> 
> Well, to some extent. For example, the amd64 sysV ABI says that enum
> types are signed fourbyte, with a footnote that "C++ and some
> implementations of C permit enums larger than an int. The underlying
> type is bumped to an unsigned int, long int or unsigned long int, in
> that order."

And in C++11 and later, you can specify the exact type:

enum color
#if defined(__cplusplus) && __cplusplus >= 201103L
: int
#endif
{
blue,
...

Eric
___
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: r312348 - head/sys/cam/ctl

[Alexander Motin]

Author: mav
Date: Tue Jan 17 18:32:47 2017
New Revision: 312348
URL: https://svnweb.freebsd.org/changeset/base/312348

Log:
  Remove writing 'residual' field of struct ctl_scsiio.
  
  This field has no practical use and never readed.  Initiators already
  receive respective residual size from frontends.  Removed field had
  different semantics, which looks useless, and was never passed through
  by any frontend.
  
  While there, fix kern_data_resid field support in case of HA, missed in
  r312291.
  
  MFC after:13 days

Modified:
  head/sys/cam/ctl/ctl.c
  head/sys/cam/ctl/ctl_io.h
  head/sys/cam/ctl/ctl_tpc.c

Modified: head/sys/cam/ctl/ctl.c
==
--- head/sys/cam/ctl/ctl.c  Tue Jan 17 18:04:13 2017(r312347)
+++ head/sys/cam/ctl/ctl.c  Tue Jan 17 18:32:47 2017(r312348)
@@ -696,8 +696,6 @@ ctl_ha_done(union ctl_io *io)
msg.scsi.tag_num = io->scsiio.tag_num;
msg.scsi.tag_type = io->scsiio.tag_type;
msg.scsi.sense_len = io->scsiio.sense_len;
-   msg.scsi.sense_residual = io->scsiio.sense_residual;
-   msg.scsi.residual = io->scsiio.residual;
memcpy(_data, >scsiio.sense_data,
io->scsiio.sense_len);
ctl_ha_msg_send(CTL_HA_CHAN_CTL, ,
@@ -725,8 +723,6 @@ ctl_isc_handler_finish_xfer(struct ctl_s
ctsio->io_hdr.status = msg_info->hdr.status;
ctsio->scsi_status = msg_info->scsi.scsi_status;
ctsio->sense_len = msg_info->scsi.sense_len;
-   ctsio->sense_residual = msg_info->scsi.sense_residual;
-   ctsio->residual = msg_info->scsi.residual;
memcpy(>sense_data, _info->scsi.sense_data,
   msg_info->scsi.sense_len);
ctl_enqueue_isc((union ctl_io *)ctsio);
@@ -1495,13 +1491,12 @@ ctl_isc_event_handler(ctl_ha_channel cha
io->io_hdr.msg_type = CTL_MSG_DATAMOVE_DONE;
io->io_hdr.flags &= ~CTL_FLAG_DMA_INPROG;
io->io_hdr.flags |= CTL_FLAG_IO_ACTIVE;
-   io->io_hdr.port_status = msg->scsi.fetd_status;
-   io->scsiio.residual = msg->scsi.residual;
+   io->io_hdr.port_status = msg->scsi.port_status;
+   io->scsiio.kern_data_resid = msg->scsi.kern_data_resid;
if (msg->hdr.status != CTL_STATUS_NONE) {
io->io_hdr.status = msg->hdr.status;
io->scsiio.scsi_status = msg->scsi.scsi_status;
io->scsiio.sense_len = msg->scsi.sense_len;
-   io->scsiio.sense_residual 
=msg->scsi.sense_residual;
memcpy(>scsiio.sense_data,
>scsi.sense_data,
msg->scsi.sense_len);
@@ -6498,15 +6493,8 @@ ctl_mode_sense(struct ctl_scsiio *ctsio)
ctsio->kern_data_ptr = malloc(total_len, M_CTL, M_WAITOK | M_ZERO);
ctsio->kern_sg_entries = 0;
ctsio->kern_rel_offset = 0;
-   if (total_len < alloc_len) {
-   ctsio->residual = alloc_len - total_len;
-   ctsio->kern_data_len = total_len;
-   ctsio->kern_total_len = total_len;
-   } else {
-   ctsio->residual = 0;
-   ctsio->kern_data_len = alloc_len;
-   ctsio->kern_total_len = alloc_len;
-   }
+   ctsio->kern_data_len = min(total_len, alloc_len);
+   ctsio->kern_total_len = ctsio->kern_data_len;
 
switch (ctsio->cdb[0]) {
case MODE_SENSE_6: {
@@ -6850,15 +6838,8 @@ ctl_log_sense(struct ctl_scsiio *ctsio)
ctsio->kern_data_ptr = malloc(total_len, M_CTL, M_WAITOK | M_ZERO);
ctsio->kern_sg_entries = 0;
ctsio->kern_rel_offset = 0;
-   if (total_len < alloc_len) {
-   ctsio->residual = alloc_len - total_len;
-   ctsio->kern_data_len = total_len;
-   ctsio->kern_total_len = total_len;
-   } else {
-   ctsio->residual = 0;
-   ctsio->kern_data_len = alloc_len;
-   ctsio->kern_total_len = alloc_len;
-   }
+   ctsio->kern_data_len = min(total_len, alloc_len);
+   ctsio->kern_total_len = ctsio->kern_data_len;
 
header = (struct scsi_log_header *)ctsio->kern_data_ptr;
header->page = page_index->page_code;
@@ -6913,7 +6894,6 @@ ctl_read_capacity(struct ctl_scsiio *cts
 
ctsio->kern_data_ptr = malloc(sizeof(*data), M_CTL, M_WAITOK | M_ZERO);
data = (struct scsi_read_capacity_data *)ctsio->kern_data_ptr;
-   ctsio->residual = 0;
ctsio->kern_data_len = sizeof(*data);
ctsio->kern_total_len = sizeof(*data);
ctsio->kern_rel_offset = 0;
@@ -6971,18 +6951,10 @@ ctl_read_capacity_16(struct ctl_scsiio *
 
ctsio->kern_data_ptr = malloc(sizeof(*data), 

svn commit: r312347 - head/sys/boot/fdt/dts/arm

[Luiz Otavio O Souza]

Author: loos
Date: Tue Jan 17 18:04:13 2017
New Revision: 312347
URL: https://svnweb.freebsd.org/changeset/base/312347

Log:
  The write-protect is not wired on uFW, disable it to allow writes to SD
  card.
  
  Sponsored by: Rubicon Communications, LLC (Netgate)

Modified:
  head/sys/boot/fdt/dts/arm/ufw.dts

Modified: head/sys/boot/fdt/dts/arm/ufw.dts
==
--- head/sys/boot/fdt/dts/arm/ufw.dts   Tue Jan 17 17:41:14 2017
(r312346)
+++ head/sys/boot/fdt/dts/arm/ufw.dts   Tue Jan 17 18:04:13 2017
(r312347)
@@ -278,6 +278,7 @@
pinctrl-0 = <_pins>;
bus-width = <4>;
non-removable;
+   wp-disable;
status = "okay";
 };
 
___
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: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Benjamin Kaduk]

On Tue, Jan 17, 2017 at 10:57 AM, Ian Lepore  wrote:

> In my experience, enums are a superior way to define integer constants
> (compared to #define), but they are pure poison as variable types in
> APIs and structures because their size is a compiler implementation
> choice.
>

Well, to some extent. For example, the amd64 sysV ABI says that enum types
are signed fourbyte, with a footnote that "C++ and some implementations of
C permit enums larger than an int. The underlying type is bumped to an
unsigned int, long int or unsigned long int, in that order."

-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"

svn commit: r312346 - head/sys/dev/sdhci

[Luiz Otavio O Souza]

Author: loos
Date: Tue Jan 17 17:41:14 2017
New Revision: 312346
URL: https://svnweb.freebsd.org/changeset/base/312346

Log:
  Set the the wp_disabled flag when asked to.
  
  While here, add the missing new line.
  
  MFC after:3 days
  Sponsored by: Rubicon Communications, LLC (Netgate)

Modified:
  head/sys/dev/sdhci/sdhci_fdt_gpio.c

Modified: head/sys/dev/sdhci/sdhci_fdt_gpio.c
==
--- head/sys/dev/sdhci/sdhci_fdt_gpio.c Tue Jan 17 16:20:21 2017
(r312345)
+++ head/sys/dev/sdhci/sdhci_fdt_gpio.c Tue Jan 17 17:41:14 2017
(r312346)
@@ -90,7 +90,7 @@ cd_setup(struct sdhci_fdt_gpio *gpio, ph
gpio->slot->opt |= SDHCI_NON_REMOVABLE;
gpio->cd_disabled = true;
if (bootverbose)
-   device_printf(dev, "Non-removable media");
+   device_printf(dev, "Non-removable media\n");
return;
}
 
@@ -177,8 +177,12 @@ wp_setup(struct sdhci_fdt_gpio *gpio, ph
 
dev = gpio->dev;
 
-   if (OF_hasprop(node, "wp-disable"))
+   if (OF_hasprop(node, "wp-disable")) {
+   gpio->wp_disabled = true;
+   if (bootverbose)
+   device_printf(dev, "Write protect disabled\n");
return;
+   }
 
if (gpio_pin_get_by_ofw_property(dev, node, "wp-gpios", >wp_pin))
return;
___
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: r312205 - in head/sys: kern net

[Hans Petter Selasky]

On 01/17/17 16:04, John Baldwin wrote:

Then it gives a much slower boot by

hanging for almost a minute waiting for USB or something.


Hi,

This might be related to a bug in the timer init which I've observed too.

Can you show output from:

vmstat -i

When the booting is slow?

--HPS
___
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: r312205 - in head/sys: kern net

[John Baldwin]

On Tuesday, January 17, 2017 12:02:49 PM Bruce Evans wrote:
> On Mon, 16 Jan 2017, John Baldwin wrote:
> 
> > On Sunday, January 15, 2017 12:50:10 AM Sean Bruno wrote:
> >> ...
> >> Log:
> >>   Fix hangs in a uniprocessor configuration (qemu, virtualbox, real hw).
> >>
> >>   sys/net/iflib.c:
> >> Add ctx to filter_info and don't skpi interrupt early on unless we're 
> >> on an
> >> SMP system
> >
> > On an SMP system with EARLY_AP_STARTUP (default on x86) this code should
> > never see smp_started as false anyway, so these checks should likely just
> > be conditional on EARLY_AP_STARTUP (since that option will eventually go
> > away).
> 
> Ifdefs on EARLY_AP_STARTUP give strange results for the UP case (at least
> for SMP with 1 CPU).  First, the ifdef in sys/kernel.h moves SI_SUB_SMP
> from late to early, although the CPU initialization order has not changed
> when there is only 1 CPU.  Then everything that uses SI_SUB_SMP is
> reordered, and bugs in the new order show up even in the UP case.

Most of the things that used to use SI_SUB_SMP no longer do (there is now
a SI_SUB_LAST that many of those things use).

> sys/gtaskqueue.h uses a complicated combination of EARLY_AP_STARTUP and
> SI_SUB ifdefs to try to get the order right.  I think the last commit to
> it helps for the UP case but harms for the SMP case (both for the
> !EARLY_AP_STARTUP case).  Its code is simpler for the EARLY_AP_STARTUP
> case.  In the !EARLY_AP_STARTUP case, it has to split up the initialization
> to delay calculations depending on the number of CPUs until after SMP
> has started.  The last commit to it seems to have turned the split into
> nonsense by removing the delay.  But in the UP case, the split is not
> really necessary and removing the delay should help.
> 
> EARLY_AP_STARTUP works badly here.  It doesn't give a much faster startup
> for the early part of the boot.  Then it gives a much slower boot by
> hanging for almost a minute waiting for USB or something.  Starting all
> the CPUs early also unimproves debugging by interleaving the boot messages
> a bit.  I use colorized console messages (with the color indexed by the
> CPU).  This makes interleaved messages quite readable and gives interesting
> patterns when multiple CPUs are running.

The interleaving I am aware of is from USB which starts its own kthreads
during attach directly rather than using config_intrhook like other drivers
which do bus exploration later in boot (e.g. all the SCSI devices).  I tried
to describe this to Hans but will probably just come up with a patch to change
USB to use config_intrhook which might help.

-- 
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: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Ian Lepore]

In my experience, enums are a superior way to define integer constants
(compared to #define), but they are pure poison as variable types in
APIs and structures because their size is a compiler implementation
choice.

-- Ian

On Tue, 2017-01-17 at 08:40 -0800, Maxim Sobolev wrote:
> That being said, is there any other socket option value in there
> implemented as enum? I don't see anything obvious, so that I am
> curious if
> it would stick out as an odd one in there. What do you think?
> 
> -Max
> 
> On Tue, Jan 17, 2017 at 6:22 AM, Maxim Sobolev 
> wrote:
> 
> > 
> > Of course it's possible. Do you guys want me to amend that patch?
> > 
> > -Max
> > 
> > On Mon, Jan 16, 2017 at 10:52 PM, Gleb Smirnoff  > g>
> > wrote:
> > 
> > > 
> > >   Hi!
> > > 
> > > On Mon, Jan 16, 2017 at 05:46:38PM +, Maxim Sobolev wrote:
> > > M> Author: sobomax
> > > M> Date: Mon Jan 16 17:46:38 2017
> > > M> New Revision: 312296
> > > M> URL: https://svnweb.freebsd.org/changeset/base/312296
> > > M>
> > > M> Log:
> > > M>   Add a new socket option SO_TS_CLOCK to pick from several
> > > different
> > > clock
> > > M>   sources to return timestamps when SO_TIMESTAMP is enabled.
> > > Two
> > > additional
> > > M>   clock sources are:
> > > M>
> > > M>   o nanosecond resolution realtime clock (equivalent of
> > > CLOCK_REALTIME);
> > > M>   o nanosecond resolution monotonic clock (equivalent of
> > > CLOCK_MONOTONIC).
> > > M>
> > > M>   In addition to this, this option provides unified interface
> > > to get
> > > bintime
> > > M>   (equivalent of using SO_BINTIME), except it also supported
> > > with IPv6
> > > where
> > > M>   SO_BINTIME has never been supported. The long term plan is
> > > to
> > > depreciate
> > > M>   SO_BINTIME and move everything to using SO_TS_CLOCK.
> > > M>
> > > M>   Idea for this enhancement has been briefly discussed on the
> > > Net
> > > session
> > > M>   during dev summit in Ottawa last June and the general input
> > > was
> > > positive.
> > > M>
> > > M>   This change is believed to benefit network
> > > benchmarks/profiling as
> > > well
> > > M>   as other scenarios where precise time of arrival measurement
> > > is
> > > necessary.
> > > M>
> > > M>   There are two regression test cases as part of this commit:
> > > one
> > > extends unix
> > > M>   domain test code (unix_cmsg) to test new SCM_XXX types and
> > > another
> > > one
> > > M>   implementis totally new test case which exchanges UDP
> > > packets
> > > between two
> > > M>   processes using both conventional methods (i.e. calling
> > > clock_gettime(2)
> > > M>   before recv(2) and after send(2)), as well as using
> > > setsockopt()+recv() in
> > > M>   receive path. The resulting delays are checked for sanity
> > > for all
> > > supported
> > > M>   clock types.
> > > M>
> > > M>   Reviewed by:adrian, gnn
> > > M>   Differential Revision:  https://reviews.freebsd.org/D9171
> > > 
> > > Is it possible to declare possible values as a enum and make
> > > so_ts_clock
> > > fields of that enum type?
> > > 
> > > --
> > > Totus tuus, Glebius.
> > > 
> > > 
___
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: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Maxim Sobolev]

That being said, is there any other socket option value in there
implemented as enum? I don't see anything obvious, so that I am curious if
it would stick out as an odd one in there. What do you think?

-Max

On Tue, Jan 17, 2017 at 6:22 AM, Maxim Sobolev  wrote:

> Of course it's possible. Do you guys want me to amend that patch?
>
> -Max
>
> On Mon, Jan 16, 2017 at 10:52 PM, Gleb Smirnoff 
> wrote:
>
>>   Hi!
>>
>> On Mon, Jan 16, 2017 at 05:46:38PM +, Maxim Sobolev wrote:
>> M> Author: sobomax
>> M> Date: Mon Jan 16 17:46:38 2017
>> M> New Revision: 312296
>> M> URL: https://svnweb.freebsd.org/changeset/base/312296
>> M>
>> M> Log:
>> M>   Add a new socket option SO_TS_CLOCK to pick from several different
>> clock
>> M>   sources to return timestamps when SO_TIMESTAMP is enabled. Two
>> additional
>> M>   clock sources are:
>> M>
>> M>   o nanosecond resolution realtime clock (equivalent of
>> CLOCK_REALTIME);
>> M>   o nanosecond resolution monotonic clock (equivalent of
>> CLOCK_MONOTONIC).
>> M>
>> M>   In addition to this, this option provides unified interface to get
>> bintime
>> M>   (equivalent of using SO_BINTIME), except it also supported with IPv6
>> where
>> M>   SO_BINTIME has never been supported. The long term plan is to
>> depreciate
>> M>   SO_BINTIME and move everything to using SO_TS_CLOCK.
>> M>
>> M>   Idea for this enhancement has been briefly discussed on the Net
>> session
>> M>   during dev summit in Ottawa last June and the general input was
>> positive.
>> M>
>> M>   This change is believed to benefit network benchmarks/profiling as
>> well
>> M>   as other scenarios where precise time of arrival measurement is
>> necessary.
>> M>
>> M>   There are two regression test cases as part of this commit: one
>> extends unix
>> M>   domain test code (unix_cmsg) to test new SCM_XXX types and another
>> one
>> M>   implementis totally new test case which exchanges UDP packets
>> between two
>> M>   processes using both conventional methods (i.e. calling
>> clock_gettime(2)
>> M>   before recv(2) and after send(2)), as well as using
>> setsockopt()+recv() in
>> M>   receive path. The resulting delays are checked for sanity for all
>> supported
>> M>   clock types.
>> M>
>> M>   Reviewed by:adrian, gnn
>> M>   Differential Revision:  https://reviews.freebsd.org/D9171
>>
>> Is it possible to declare possible values as a enum and make so_ts_clock
>> fields of that enum type?
>>
>> --
>> Totus tuus, Glebius.
>>
>>
>
___
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: r311952 - head/sys/ddb

[Bruce Evans]

On Mon, 16 Jan 2017, Julian Elischer wrote:


On 16/01/2017 11:53 AM, Bruce Evans wrote:

On Sun, 15 Jan 2017, Adrian Chadd wrote:


hah, i took this, then life got in the way. :)

Bruce - what do you think of
https://bz-attachments.freebsd.org/attachment.cgi?id=138881 ?


Also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184987 .

I think it is hard to read and review since it is not in the mail.
After fetching it and quoting it:


review it in the review page and just send a link in the email.. that's what 
it's for.


That's what is hard to read and harder to review.

Bruce
___
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: r312344 - in head/sys/cam: ata scsi

[Sean Bruno]

Author: sbruno
Date: Tue Jan 17 14:52:48 2017
New Revision: 312344
URL: https://svnweb.freebsd.org/changeset/base/312344

Log:
  Add 4k quirk for Micron 5100 and Intel S3610 SSDs
  
  Submitted by: Jason Wolfe 
  MFH:  1 week
  Sponsored by: Limelight Networks
  Differential Revision:https://reviews.freebsd.org/D9209

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

Modified: head/sys/cam/ata/ata_da.c
==
--- head/sys/cam/ata/ata_da.c   Tue Jan 17 14:13:14 2017(r312343)
+++ head/sys/cam/ata/ata_da.c   Tue Jan 17 14:52:48 2017(r312344)
@@ -513,6 +513,14 @@ static struct ada_quirk_entry ada_quirk_
},
{
/*
+* Intel S3610 Series SSDs
+* 4k optimised & trim only works in 4k requests + 4k aligned
+*/
+   { T_DIRECT, SIP_MEDIA_FIXED, "*", "INTEL SSDSC2BX*", "*" },
+   /*quirks*/ADA_Q_4K
+   },
+   {
+   /*
 * Intel X25-M Series SSDs
 * 4k optimised & trim only works in 4k requests + 4k aligned
 */
@@ -569,6 +577,14 @@ static struct ada_quirk_entry ada_quirk_
},
{
/*
+* Micron 5100 SSDs
+* 4k optimised & trim only works in 4k requests + 4k aligned
+*/
+   { T_DIRECT, SIP_MEDIA_FIXED, "*", "Micron 5100 MTFDDAK*", "*" },
+   /*quirks*/ADA_Q_4K
+   },
+   {
+   /*
 * OCZ Agility 2 SSDs
 * 4k optimised & trim only works in 4k requests + 4k aligned
 */

Modified: head/sys/cam/scsi/scsi_da.c
==
--- head/sys/cam/scsi/scsi_da.c Tue Jan 17 14:13:14 2017(r312343)
+++ head/sys/cam/scsi/scsi_da.c Tue Jan 17 14:52:48 2017(r312344)
@@ -829,6 +829,11 @@ static struct da_quirk_entry da_quirk_ta
/*quirks*/DA_Q_4K
},
{
+   /* Micron Advanced Format (4k) drives */
+   { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "Micron 5100 MTFDDAK*", "*" 
},
+   /*quirks*/DA_Q_4K
+   },
+   {
/* Samsung Advanced Format (4k) drives */
{ T_DIRECT, SIP_MEDIA_FIXED, "ATA", "SAMSUNG HD155UI*", "*" },
/*quirks*/DA_Q_4K
@@ -1151,6 +1156,14 @@ static struct da_quirk_entry da_quirk_ta
},
{
/*
+* Intel S3610 Series SSDs
+* 4k optimised & trim only works in 4k requests + 4k aligned
+*/
+   { T_DIRECT, SIP_MEDIA_FIXED, "ATA", "INTEL SSDSC2BX*", "*" },
+   /*quirks*/DA_Q_4K
+   },
+   {
+   /*
 * Intel X25-M Series SSDs
 * 4k optimised & trim only works in 4k requests + 4k aligned
 */
___
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: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Maxim Sobolev]

Of course it's possible. Do you guys want me to amend that patch?

-Max

On Mon, Jan 16, 2017 at 10:52 PM, Gleb Smirnoff  wrote:

>   Hi!
>
> On Mon, Jan 16, 2017 at 05:46:38PM +, Maxim Sobolev wrote:
> M> Author: sobomax
> M> Date: Mon Jan 16 17:46:38 2017
> M> New Revision: 312296
> M> URL: https://svnweb.freebsd.org/changeset/base/312296
> M>
> M> Log:
> M>   Add a new socket option SO_TS_CLOCK to pick from several different
> clock
> M>   sources to return timestamps when SO_TIMESTAMP is enabled. Two
> additional
> M>   clock sources are:
> M>
> M>   o nanosecond resolution realtime clock (equivalent of CLOCK_REALTIME);
> M>   o nanosecond resolution monotonic clock (equivalent of
> CLOCK_MONOTONIC).
> M>
> M>   In addition to this, this option provides unified interface to get
> bintime
> M>   (equivalent of using SO_BINTIME), except it also supported with IPv6
> where
> M>   SO_BINTIME has never been supported. The long term plan is to
> depreciate
> M>   SO_BINTIME and move everything to using SO_TS_CLOCK.
> M>
> M>   Idea for this enhancement has been briefly discussed on the Net
> session
> M>   during dev summit in Ottawa last June and the general input was
> positive.
> M>
> M>   This change is believed to benefit network benchmarks/profiling as
> well
> M>   as other scenarios where precise time of arrival measurement is
> necessary.
> M>
> M>   There are two regression test cases as part of this commit: one
> extends unix
> M>   domain test code (unix_cmsg) to test new SCM_XXX types and another one
> M>   implementis totally new test case which exchanges UDP packets between
> two
> M>   processes using both conventional methods (i.e. calling
> clock_gettime(2)
> M>   before recv(2) and after send(2)), as well as using
> setsockopt()+recv() in
> M>   receive path. The resulting delays are checked for sanity for all
> supported
> M>   clock types.
> M>
> M>   Reviewed by:adrian, gnn
> M>   Differential Revision:  https://reviews.freebsd.org/D9171
>
> Is it possible to declare possible values as a enum and make so_ts_clock
> fields of that enum type?
>
> --
> Totus tuus, Glebius.
>
>
___
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: r312343 - head/sys/cam/ctl

[Alexander Motin]

Author: mav
Date: Tue Jan 17 14:13:14 2017
New Revision: 312343
URL: https://svnweb.freebsd.org/changeset/base/312343

Log:
  Improve error message on duplicate iSCSI port.
  
  MFC after:2 weeks

Modified:
  head/sys/cam/ctl/ctl_frontend_iscsi.c

Modified: head/sys/cam/ctl/ctl_frontend_iscsi.c
==
--- head/sys/cam/ctl/ctl_frontend_iscsi.c   Tue Jan 17 12:43:55 2017
(r312342)
+++ head/sys/cam/ctl/ctl_frontend_iscsi.c   Tue Jan 17 14:13:14 2017
(r312343)
@@ -2084,7 +2084,8 @@ cfiscsi_ioctl_port_create(struct ctl_req
if (ct->ct_state == CFISCSI_TARGET_STATE_ACTIVE) {
req->status = CTL_LUN_ERROR;
snprintf(req->error_str, sizeof(req->error_str),
-   "target \"%s\" already exists", target);
+   "target \"%s\" for portal group tag %u already exists",
+   target, tag);
cfiscsi_target_release(ct);
ctl_free_opts();
return;
___
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: r312341 - head/sys/netpfil/ipfw

[Andrey V. Elsukov]

Author: ae
Date: Tue Jan 17 10:50:28 2017
New Revision: 312341
URL: https://svnweb.freebsd.org/changeset/base/312341

Log:
  Initialize IPFW static rules rmlock with RM_RECURSE flag.
  
  This lock was replaced from rwlock in r272840. But unlike rwlock, rmlock
  doesn't allow recursion on rm_rlock(), so at this time fix this with
  RM_RECURSE flag. Later we need to change ipfw to avoid such recursions.
  
  PR:   216171
  Reported by:  Eugene Grosbein
  MFC after:1 week

Modified:
  head/sys/netpfil/ipfw/ip_fw_private.h

Modified: head/sys/netpfil/ipfw/ip_fw_private.h
==
--- head/sys/netpfil/ipfw/ip_fw_private.h   Tue Jan 17 10:34:31 2017
(r312340)
+++ head/sys/netpfil/ipfw/ip_fw_private.h   Tue Jan 17 10:50:28 2017
(r312341)
@@ -414,7 +414,7 @@ struct ipfw_ifc {
 #defineIPFW_PF_RUNLOCK(p)  IPFW_RUNLOCK(p)
 #else /* FreeBSD */
 #defineIPFW_LOCK_INIT(_chain) do { \
-   rm_init(&(_chain)->rwmtx, "IPFW static rules"); \
+   rm_init_flags(&(_chain)->rwmtx, "IPFW static rules", RM_RECURSE); \
rw_init(&(_chain)->uh_lock, "IPFW UH lock");\
} while (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"

svn commit: r312338 - in head: share/man/man4 sys/dev/sound/usb sys/dev/usb sys/dev/usb/quirk

[Hans Petter Selasky]

Author: hselasky
Date: Tue Jan 17 08:15:10 2017
New Revision: 312338
URL: https://svnweb.freebsd.org/changeset/base/312338

Log:
  Add USB audio support for S/PDIF output with C-Media CM6206 devices.
  
  Submitted by: Julien Nadeau 
  PR:   216131
  MFC after:1 week

Modified:
  head/share/man/man4/usb_quirk.4
  head/sys/dev/sound/usb/uaudio.c
  head/sys/dev/usb/quirk/usb_quirk.c
  head/sys/dev/usb/quirk/usb_quirk.h
  head/sys/dev/usb/usbdevs

Modified: head/share/man/man4/usb_quirk.4
==
--- head/share/man/man4/usb_quirk.4 Tue Jan 17 07:43:37 2017
(r312337)
+++ head/share/man/man4/usb_quirk.4 Tue Jan 17 08:15:10 2017
(r312338)
@@ -16,7 +16,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd April 4, 2016
+.Dd January 17, 2017
 .Dt USB_QUIRK 4
 .Os
 .Sh NAME
@@ -52,6 +52,10 @@ input is async despite claim of adaptive
 do not adjust for fractional samples
 .It UQ_AU_NO_XU
 audio device has broken extension unit
+.It UQ_AU_VENDOR_CLASS
+audio device uses vendor class to identify itself
+.It UQ_AU_SET_SPDIF_CM6206
+audio device needs special programming to enable S/PDIF audio output
 .It UQ_BAD_ADC
 bad audio spec version number
 .It UQ_BAD_AUDIO

Modified: head/sys/dev/sound/usb/uaudio.c
==
--- head/sys/dev/sound/usb/uaudio.c Tue Jan 17 07:43:37 2017
(r312337)
+++ head/sys/dev/sound/usb/uaudio.c Tue Jan 17 08:15:10 2017
(r312338)
@@ -337,6 +337,11 @@ struct uaudio_hid {
uint8_t mute_id;
 };
 
+#defineUAUDIO_SPDIF_OUT0x01/* Enable S/PDIF output */
+#defineUAUDIO_SPDIF_OUT_48K0x02/* Out sample rate = 48K */
+#defineUAUDIO_SPDIF_OUT_96K0x04/* Out sample rate = 96K */
+#defineUAUDIO_SPDIF_IN_MIX 0x10/* Input mix enable */
+
 struct uaudio_softc {
struct sbuf sc_sndstat;
struct sndcard_func sc_sndcard_func;
@@ -354,6 +359,7 @@ struct uaudio_softc {
struct usb_xfer *sc_mixer_xfer[1];
struct uaudio_mixer_node *sc_mixer_root;
struct uaudio_mixer_node *sc_mixer_curr;
+   int (*sc_set_spdif_fn) (struct uaudio_softc *, int);
 
uint32_t sc_mix_info;
uint32_t sc_recsrc_info;
@@ -885,6 +891,46 @@ uaudio_probe(device_t dev)
return (ENXIO);
 }
 
+/*
+ * Set Cmedia CM6206 S/PDIF settings
+ * Source: CM6206 Datasheet v2.3.
+ */
+static int
+uaudio_set_spdif_cm6206(struct uaudio_softc *sc, int flags)
+{
+   uint8_t cmd[2][4] = {
+   {0x20, 0x20, 0x00, 0},
+   {0x20, 0x30, 0x02, 1}
+   };
+   int i;
+
+   if (flags & UAUDIO_SPDIF_OUT)
+   cmd[1][1] = 0x00;
+   else
+   cmd[1][1] = 0x02;
+
+   if (flags & UAUDIO_SPDIF_OUT_96K)
+   cmd[0][1] = 0x60;   /* 96K: 3'b110 */
+
+   if (flags & UAUDIO_SPDIF_IN_MIX)
+   cmd[1][1] = 0x03;   /* SPDIFMIX */
+
+   for (i = 0; i < 2; i++) {
+   if (usbd_req_set_report(sc->sc_udev, NULL,
+   cmd[i], sizeof(cmd[0]),
+   sc->sc_mixer_iface_index, UHID_OUTPUT_REPORT, 0) != 0) {
+   return (ENXIO);
+   }
+   }
+   return (0);
+}
+
+static int
+uaudio_set_spdif_dummy(struct uaudio_softc *sc, int flags)
+{
+   return (0);
+}
+
 static int
 uaudio_attach(device_t dev)
 {
@@ -919,6 +965,12 @@ uaudio_attach(device_t dev)
if (usb_test_quirk(uaa, UQ_AU_VENDOR_CLASS))
sc->sc_uq_au_vendor_class = 1;
 
+   /* set S/PDIF function */
+   if (usb_test_quirk(uaa, UQ_AU_SET_SPDIF_CM6206))
+   sc->sc_set_spdif_fn = uaudio_set_spdif_cm6206;
+   else
+   sc->sc_set_spdif_fn = uaudio_set_spdif_dummy;
+
umidi_init(dev);
 
device_set_usb_desc(dev);
@@ -1055,6 +1107,11 @@ uaudio_attach(device_t dev)
/* reload all mixer settings */
uaudio_mixer_reload_all(sc);
 
+   /* enable S/PDIF output, if any */
+   if (sc->sc_set_spdif_fn(sc,
+   UAUDIO_SPDIF_OUT | UAUDIO_SPDIF_OUT_48K) != 0) {
+   device_printf(dev, "Failed to enable S/PDIF at 48K\n");
+   }
return (0); /* success */
 
 detach:
@@ -1139,6 +1196,9 @@ uaudio_detach_sub(device_t dev)
struct uaudio_softc *sc = device_get_softc(device_get_parent(dev));
int error = 0;
 
+   /* disable S/PDIF output, if any */
+   (void) sc->sc_set_spdif_fn(sc, 0);
+
 repeat:
if (sc->sc_pcm_registered) {
error = pcm_unregister(dev);

Modified: head/sys/dev/usb/quirk/usb_quirk.c
==
--- head/sys/dev/usb/quirk/usb_quirk.c  Tue Jan 17 07:43:37 2017
(r312337)
+++ head/sys/dev/usb/quirk/usb_quirk.c  Tue Jan 17 08:15:10 2017