Re: svn commit: r266553 - head/release/scripts

2014-05-28 Thread Warner Losh

On May 28, 2014, at 11:15 PM, Nathan Whitehorn  wrote:

> On 05/28/14 18:53, Konstantin Belousov wrote:
>> On Wed, May 28, 2014 at 01:53:28PM -0600, Warner Losh wrote:
>>> On May 28, 2014, at 9:47 AM, Konstantin Belousov  
>>> wrote:
>>> 
 On Wed, May 28, 2014 at 09:35:27AM -0600, Warner Losh wrote:
> On May 28, 2014, at 9:28 AM, Konstantin Belousov  
> wrote:
> 
>> On Wed, May 28, 2014 at 08:26:58AM -0600, Warner Losh wrote:
>>> Then we disagree on this point. However, the disagreement here is
>>> kinda foundational: to build a set of libraries or sys root, you have
>>> to have a MACHINE_ARCH to make it work. Even in our current system, we
>>> set MACHINE_ARCH to i386 or powerpc when building the 32-bit binaries
>>> (note: we don?t do this for mips). This means that if we do grow x32
>>> support, we?ll need to grow a MACHINE_ARCH for it. That?s my point:
>>> all ABIs have MACHINE_ARCH associated with them, and those are the
>>> names users are used to specifying, and are the ones that are the most
>>> natural for script writers to use. With nathan?s patches, we?re to the
>>> point where those are used, though there?s also the option of using
>>> the non-standard names if you want (e.g. amd64:32 instead of x32).
>>> 
>> I am not sure if this comment would add anything to the discussion,
>> but other build systems do not require MACHINE_ARCH.  In our terms,
>> other build systems are happy to build:
>> i386 binary when MACHINE is amd64 and CFLAGS contains -m32;
>> x32 binary when MACHINE is amd64 and CFLAGS contains -mx32.
>> 
>> For HEAD and stable/10 we finally reached the point where -m32 works,
>> on amd64; it worked on powerpc64 from inception, AFAIU Nathan. At least
>> this is true for dependencies limited to the base system, and not to the
>> ports (the later is since ports do not know about multiarch).
>> 
>> It is limitation of our build that we require MACHINE_ARCH to build
>> other natively supported ABI binary on the host. Ideally, the hacks that
>> treat lib32 build as the cross-compilation would go away eventually.
> I doubt it. The MACHINE_ARCH is used to select which files to build.
 Do I understand you right that the comment references e.g. a selection
 of arch-specific subdir in lib/libc or libexec/rtld-elf for inclusion
 into the build ? If yes, I cannot disagree with the statement.
>>> As far as I can tell, that?s the only reason we?re doing it..  But it is a 
>>> critically important reason...
>>> 
 My note was about our build system which currently requires
 full-fledged cross-build to even create i386 binary on amd64 vs. other
 builds which consider this as a (often minor) variations of the host
 target. Sure, some variances must be allowed, e.g. to select proper .S
 file for the ABI, but we do not need cross-build to get i386 on amd64.
>>> lib32 uses -m32 and some other flags to achieve its ends. So it doesn?t 
>>> create a full i386 compiler, etc. It just uses the amd64 one with special 
>>> flags/args. So I don?t think it requires a full-fledged cross-build 
>>> environment, or I misunderstand what you mean by that phrase.
>> We install the headers for the MACHINE_ARCH into the compat32 build tree,
>> and use them instead of the target MACHINE headers.  The fact that
>>  -m32 works as the cross-compiler just saves the build
>> time.
> 
> Ah, OK. That's probably pointless most of the time now. It was always 
> pointless on PowerPC and MIPS, since they share the same headers anyway, and 
> is probably also now unnecessary on x86 now that regular -m32 works. I don't 
> think ia64 builds lib32 (which would require a real cross-compiler).

Yea, this is an area that can likely be cleaned up from the original gross 
hacks that were necessary before -m32 actually worked.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: svn commit: r266553 - head/release/scripts

2014-05-28 Thread Nathan Whitehorn

On 05/28/14 18:53, Konstantin Belousov wrote:

On Wed, May 28, 2014 at 01:53:28PM -0600, Warner Losh wrote:

On May 28, 2014, at 9:47 AM, Konstantin Belousov  wrote:


On Wed, May 28, 2014 at 09:35:27AM -0600, Warner Losh wrote:

On May 28, 2014, at 9:28 AM, Konstantin Belousov  wrote:


On Wed, May 28, 2014 at 08:26:58AM -0600, Warner Losh wrote:

Then we disagree on this point. However, the disagreement here is
kinda foundational: to build a set of libraries or sys root, you have
to have a MACHINE_ARCH to make it work. Even in our current system, we
set MACHINE_ARCH to i386 or powerpc when building the 32-bit binaries
(note: we don?t do this for mips). This means that if we do grow x32
support, we?ll need to grow a MACHINE_ARCH for it. That?s my point:
all ABIs have MACHINE_ARCH associated with them, and those are the
names users are used to specifying, and are the ones that are the most
natural for script writers to use. With nathan?s patches, we?re to the
point where those are used, though there?s also the option of using
the non-standard names if you want (e.g. amd64:32 instead of x32).


I am not sure if this comment would add anything to the discussion,
but other build systems do not require MACHINE_ARCH.  In our terms,
other build systems are happy to build:
i386 binary when MACHINE is amd64 and CFLAGS contains -m32;
x32 binary when MACHINE is amd64 and CFLAGS contains -mx32.

For HEAD and stable/10 we finally reached the point where -m32 works,
on amd64; it worked on powerpc64 from inception, AFAIU Nathan. At least
this is true for dependencies limited to the base system, and not to the
ports (the later is since ports do not know about multiarch).

It is limitation of our build that we require MACHINE_ARCH to build
other natively supported ABI binary on the host. Ideally, the hacks that
treat lib32 build as the cross-compilation would go away eventually.

I doubt it. The MACHINE_ARCH is used to select which files to build.

Do I understand you right that the comment references e.g. a selection
of arch-specific subdir in lib/libc or libexec/rtld-elf for inclusion
into the build ? If yes, I cannot disagree with the statement.

As far as I can tell, that?s the only reason we?re doing it..  But it is a 
critically important reason...


My note was about our build system which currently requires
full-fledged cross-build to even create i386 binary on amd64 vs. other
builds which consider this as a (often minor) variations of the host
target. Sure, some variances must be allowed, e.g. to select proper .S
file for the ABI, but we do not need cross-build to get i386 on amd64.

lib32 uses -m32 and some other flags to achieve its ends. So it doesn?t create 
a full i386 compiler, etc. It just uses the amd64 one with special flags/args. 
So I don?t think it requires a full-fledged cross-build environment, or I 
misunderstand what you mean by that phrase.

We install the headers for the MACHINE_ARCH into the compat32 build tree,
and use them instead of the target MACHINE headers.  The fact that
 -m32 works as the cross-compiler just saves the build
time.


Ah, OK. That's probably pointless most of the time now. It was always 
pointless on PowerPC and MIPS, since they share the same headers anyway, 
and is probably also now unnecessary on x86 now that regular -m32 works. 
I don't think ia64 builds lib32 (which would require a real cross-compiler).

-Nathan

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


Re: svn commit: r266822 - head/sys/netipsec

2014-05-28 Thread Gleb Smirnoff
On Wed, May 28, 2014 at 11:01:20PM +, Bjoern A. Zeeb wrote:
B> Author: bz
B> Date: Wed May 28 23:01:20 2014
B> New Revision: 266822
B> URL: http://svnweb.freebsd.org/changeset/base/266822
B> 
B> Log:
B>   Use IPv4 statistics in ipsec4_process_packet() rather than the IPv6
B>   version.  This also unbreaks the NOINET6 builds after r266800.
B> 
B> Modified:
B>   head/sys/netipsec/ipsec_output.c
B> 
B> Modified: head/sys/netipsec/ipsec_output.c
B> 
==
B> --- head/sys/netipsec/ipsec_output.c Wed May 28 19:59:27 2014
(r266821)
B> +++ head/sys/netipsec/ipsec_output.c Wed May 28 23:01:20 2014
(r266822)
B> @@ -576,7 +576,7 @@ ipsec4_process_packet(
B>  DPRINTF(("%s: unsupported protocol family %u\n",
B>   __func__, dst->sa.sa_family));
B>  error = EPFNOSUPPORT;
B> -IPSEC6STAT_INC(ips_out_inval);
B> +IPSECSTAT_INC(ips_out_inval);
B>  goto bad;
B>  }
B>  error = (*sav->tdb_xform->xf_output)(m, isr, NULL, i, off);
B> @@ -739,4 +739,4 @@ bad:
B>  m_freem(m);
B>  return error;
B>  }
B> -#endif /*INET6*/
B> \ No newline at end of file
B> +#endif /*INET6*/

Is there any reason to keep the line '\ No newline at end of file' when
it is no longer at the end of the file?

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


Re: svn commit: r266806 - head/sys/netgraph

2014-05-28 Thread Gleb Smirnoff
On Wed, May 28, 2014 at 11:41:23PM +0800, Julian Elischer wrote:
J> On 5/28/14, 10:56 PM, Gleb Smirnoff wrote:
J> > On Wed, May 28, 2014 at 10:12:32PM +0800, Julian Elischer wrote:
J> > J> On 5/28/14, 9:15 PM, Gleb Smirnoff wrote:
J> > J> > Author: glebius
J> > J> > Date: Wed May 28 13:15:14 2014
J> > J> > New Revision: 266806
J> > J> > URL: http://svnweb.freebsd.org/changeset/base/266806
J> > J> >
J> > J> > Log:
J> > J> >Use M_WAITOK for the NGM_PIPE_SET_CFG control message. We expect 
it to
J> > J> >arrive from userland only.
J> > J> >
J> > J> >Submitted by:  Dmitry Luhtionov 
J> > J> what's to stop another node from generating it and sending it on?
J> > J> generally a message may come from anywhere.
J> > J> Just becasue YOU don't have module that
J> > J> sends messages to ng_pipe, doesn't mean there never will be..
J> > J> also there are cases when the locking may force a message to be
J> > J> delivered asynchronously.
J> >
J> > I know that. After resolving many issues with netgraph, I feel that
J> > our policy should be towards putting some invariants on what events
J> > SHOULD come from userland only and which events SHOULD be serviced
J> > without memory failures.
J> >
J> > Current paradigma that messages are fully symmetrical and can come
J> > from anywhere are quite a curious thought experiment. I liked that
J> > for a long time. But in practice if we want to build a robust software
J> > we should make more strict rules of using it.
J> >
J> > You could disagree, but if you try to fix this particular one liner
J> > in the paradigma of "messages come from anywhere", then you will end
J> > up with smth like 20 lines of code to this particular module. Next
J> > comes the need to fix any software or script that sends NGM_PIPE_SET_CFG,
J> > it now should be taught of dealing with ENOMEM. So, instead of one
J> > liner you will bury yourself under tons of work.
J> >
J> >
J> Then I suggest that we increment the protocol, and add support to messages
J> to say whether they come from user space.
J> and some providers only accept such messages.
J> 
J> I have lost track of the code so I don't know if my comment about
J> messages getting queued instead of delivered is still true.
J> However if it is, then a message could be delivered by a kernel agent 
J> even
J> if it is initiated by a userspace program.

I don't think we need to increment protocol. Does it change? Right now
we have a de facto standard, that some messages are expected from userland
only. It is not enforced, it is just a habit. We should just keep this
direction.

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


svn commit: r266828 - head/share/man/man5

2014-05-28 Thread Warren Block
Author: wblock (doc committer)
Date: Thu May 29 02:26:12 2014
New Revision: 266828
URL: http://svnweb.freebsd.org/changeset/base/266828

Log:
  Correct the description of characters allowed.  Based on pw_checkname in
  usr.sbin/pw/pw_user.c.  Modified version of patch submitted by
  venture37.
  
  PR:   docs/47594
  Submitted by: Fernando Schapachnik , venture37 

  Reviewed by:  allanjude, bcr, brueffer (on phabricator)
  MFC after:1 week

Modified:
  head/share/man/man5/passwd.5

Modified: head/share/man/man5/passwd.5
==
--- head/share/man/man5/passwd.5Thu May 29 01:42:22 2014
(r266827)
+++ head/share/man/man5/passwd.5Thu May 29 02:26:12 2014
(r266828)
@@ -125,19 +125,29 @@ Routines
 that manipulate these files will often return only one of the multiple
 entries, and that one by random selection.
 .Pp
-The login name must never begin with a hyphen
-.Pq Ql - ;
-also, it is strongly
-suggested that neither upper-case characters or dots
-.Pq Ql \&.
-be part
-of the name, as this tends to confuse mailers.
+The login name must not begin with a hyphen
+.Pq Ql \&- ,
+and cannot contain 8-bit characters, tabs or spaces, or any of these
+symbols:
+.Ql \&,:+&#%^\&(\&)!@~*?<>=|\e\\&/" .
+The dollar symbol
+.Pq Ql \&$
+is allowed only as the last character for use with Samba.
 No field may contain a
 colon
 .Pq Ql \&:
 as this has been used historically to separate the fields
 in the user database.
 .Pp
+Case is significant.
+Login names
+.Ql Lrrr
+and
+.Ql lrrr
+represent different users.
+Be aware of this when interoperating with systems that do not have
+case-sensitive login names.
+.Pp
 In the
 .Nm master.passwd
 file,
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r266553 - head/release/scripts

2014-05-28 Thread Konstantin Belousov
On Wed, May 28, 2014 at 01:53:28PM -0600, Warner Losh wrote:
> 
> On May 28, 2014, at 9:47 AM, Konstantin Belousov  wrote:
> 
> > On Wed, May 28, 2014 at 09:35:27AM -0600, Warner Losh wrote:
> >> 
> >> On May 28, 2014, at 9:28 AM, Konstantin Belousov  
> >> wrote:
> >> 
> >>> On Wed, May 28, 2014 at 08:26:58AM -0600, Warner Losh wrote:
>  
>  Then we disagree on this point. However, the disagreement here is
>  kinda foundational: to build a set of libraries or sys root, you have
>  to have a MACHINE_ARCH to make it work. Even in our current system, we
>  set MACHINE_ARCH to i386 or powerpc when building the 32-bit binaries
>  (note: we don?t do this for mips). This means that if we do grow x32
>  support, we?ll need to grow a MACHINE_ARCH for it. That?s my point:
>  all ABIs have MACHINE_ARCH associated with them, and those are the
>  names users are used to specifying, and are the ones that are the most
>  natural for script writers to use. With nathan?s patches, we?re to the
>  point where those are used, though there?s also the option of using
>  the non-standard names if you want (e.g. amd64:32 instead of x32).
>  
> >>> 
> >>> I am not sure if this comment would add anything to the discussion,
> >>> but other build systems do not require MACHINE_ARCH.  In our terms,
> >>> other build systems are happy to build:
> >>> i386 binary when MACHINE is amd64 and CFLAGS contains -m32;
> >>> x32 binary when MACHINE is amd64 and CFLAGS contains -mx32.
> >>> 
> >>> For HEAD and stable/10 we finally reached the point where -m32 works,
> >>> on amd64; it worked on powerpc64 from inception, AFAIU Nathan. At least
> >>> this is true for dependencies limited to the base system, and not to the
> >>> ports (the later is since ports do not know about multiarch).
> >>> 
> >>> It is limitation of our build that we require MACHINE_ARCH to build
> >>> other natively supported ABI binary on the host. Ideally, the hacks that
> >>> treat lib32 build as the cross-compilation would go away eventually.
> >> 
> >> I doubt it. The MACHINE_ARCH is used to select which files to build.
> > Do I understand you right that the comment references e.g. a selection
> > of arch-specific subdir in lib/libc or libexec/rtld-elf for inclusion
> > into the build ? If yes, I cannot disagree with the statement.
> 
> As far as I can tell, that?s the only reason we?re doing it..  But it is a 
> critically important reason...
> 
> > My note was about our build system which currently requires
> > full-fledged cross-build to even create i386 binary on amd64 vs. other
> > builds which consider this as a (often minor) variations of the host
> > target. Sure, some variances must be allowed, e.g. to select proper .S
> > file for the ABI, but we do not need cross-build to get i386 on amd64.
> 
> lib32 uses -m32 and some other flags to achieve its ends. So it doesn?t 
> create a full i386 compiler, etc. It just uses the amd64 one with special 
> flags/args. So I don?t think it requires a full-fledged cross-build 
> environment, or I misunderstand what you mean by that phrase.

We install the headers for the MACHINE_ARCH into the compat32 build tree,
and use them instead of the target MACHINE headers.  The fact that
 -m32 works as the cross-compiler just saves the build
time.

> 
> But none of this changes the fact that we have a unique MACHINE_ARCH value 
> per ABI.
> 
> Warner




pgpBW3gQ44lGv.pgp
Description: PGP signature


svn commit: r266827 - in head/sys: amd64/amd64 i386/i386 kern mips/mips powerpc/aim

2014-05-28 Thread Mark Johnston
Author: markj
Date: Thu May 29 01:42:22 2014
New Revision: 266827
URL: http://svnweb.freebsd.org/changeset/base/266827

Log:
  Commit the rest of the changes that were intended to be part of r266826.
  
  X-MFC-with:   r266826

Modified:
  head/sys/amd64/amd64/trap.c
  head/sys/i386/i386/trap.c
  head/sys/kern/kern_dtrace.c
  head/sys/mips/mips/trap.c
  head/sys/powerpc/aim/trap.c

Modified: head/sys/amd64/amd64/trap.c
==
--- head/sys/amd64/amd64/trap.c Thu May 29 01:41:19 2014(r266826)
+++ head/sys/amd64/amd64/trap.c Thu May 29 01:42:22 2014(r266827)
@@ -95,28 +95,6 @@ PMC_SOFT_DEFINE( , , page_fault, write);
 
 #ifdef KDTRACE_HOOKS
 #include 
-
-/*
- * This is a hook which is initialised by the dtrace module
- * to handle traps which might occur during DTrace probe
- * execution.
- */
-dtrace_trap_func_t dtrace_trap_func;
-
-dtrace_doubletrap_func_t   dtrace_doubletrap_func;
-
-/*
- * This is a hook which is initialised by the systrace module
- * when it is loaded. This keeps the DTrace syscall provider
- * implementation opaque. 
- */
-systrace_probe_func_t  systrace_probe_func;
-
-/*
- * These hooks are necessary for the pid and usdt providers.
- */
-dtrace_pid_probe_ptr_t dtrace_pid_probe_ptr;
-dtrace_return_probe_ptr_t  dtrace_return_probe_ptr;
 #endif
 
 extern void trap(struct trapframe *frame);

Modified: head/sys/i386/i386/trap.c
==
--- head/sys/i386/i386/trap.c   Thu May 29 01:41:19 2014(r266826)
+++ head/sys/i386/i386/trap.c   Thu May 29 01:42:22 2014(r266827)
@@ -104,28 +104,6 @@ PMC_SOFT_DEFINE( , , page_fault, write);
 
 #ifdef KDTRACE_HOOKS
 #include 
-
-/*
- * This is a hook which is initialised by the dtrace module
- * to handle traps which might occur during DTrace probe
- * execution.
- */
-dtrace_trap_func_t dtrace_trap_func;
-
-dtrace_doubletrap_func_t   dtrace_doubletrap_func;
-
-/*
- * This is a hook which is initialised by the systrace module
- * when it is loaded. This keeps the DTrace syscall provider
- * implementation opaque. 
- */
-systrace_probe_func_t  systrace_probe_func;
-
-/*
- * These hooks are necessary for the pid and usdt providers.
- */
-dtrace_pid_probe_ptr_t dtrace_pid_probe_ptr;
-dtrace_return_probe_ptr_t  dtrace_return_probe_ptr;
 #endif
 
 extern void trap(struct trapframe *frame);

Modified: head/sys/kern/kern_dtrace.c
==
--- head/sys/kern/kern_dtrace.c Thu May 29 01:41:19 2014(r266826)
+++ head/sys/kern/kern_dtrace.c Thu May 29 01:42:22 2014(r266827)
@@ -38,6 +38,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 
 #define KDTRACE_PROC_SIZE  64
 #defineKDTRACE_THREAD_SIZE 256
@@ -47,6 +48,14 @@ FEATURE(kdtrace_hooks,
 
 static MALLOC_DEFINE(M_KDTRACE, "kdtrace", "DTrace hooks");
 
+/* Hooks used in the machine-dependent trap handlers. */
+dtrace_trap_func_t dtrace_trap_func;
+dtrace_doubletrap_func_t   dtrace_doubletrap_func;
+dtrace_pid_probe_ptr_t dtrace_pid_probe_ptr;
+dtrace_return_probe_ptr_t  dtrace_return_probe_ptr;
+
+systrace_probe_func_t  systrace_probe_func;
+
 /* Return the DTrace process data size compiled in the kernel hooks. */
 size_t
 kdtrace_proc_size()

Modified: head/sys/mips/mips/trap.c
==
--- head/sys/mips/mips/trap.c   Thu May 29 01:41:19 2014(r266826)
+++ head/sys/mips/mips/trap.c   Thu May 29 01:42:22 2014(r266827)
@@ -93,28 +93,6 @@ __FBSDID("$FreeBSD$");
 
 #ifdef KDTRACE_HOOKS
 #include 
-
-/*
- * This is a hook which is initialised by the dtrace module
- * to handle traps which might occur during DTrace probe
- * execution.
- */
-dtrace_trap_func_t dtrace_trap_func;
-
-dtrace_doubletrap_func_t   dtrace_doubletrap_func;
-
-/*
- * This is a hook which is initialised by the systrace module
- * when it is loaded. This keeps the DTrace syscall provider
- * implementation opaque. 
- */
-systrace_probe_func_t  systrace_probe_func;
-
-/*
- * These hooks are necessary for the pid and usdt providers.
- */
-dtrace_pid_probe_ptr_t dtrace_pid_probe_ptr;
-dtrace_return_probe_ptr_t  dtrace_return_probe_ptr;
 #endif
 
 #ifdef TRAP_DEBUG

Modified: head/sys/powerpc/aim/trap.c
==
--- head/sys/powerpc/aim/trap.c Thu May 29 01:41:19 2014(r266826)
+++ head/sys/powerpc/aim/trap.c Thu May 29 01:42:22 2014(r266827)
@@ -95,27 +95,6 @@ struct powerpc_exception {
 #ifdef KDTRACE_HOOKS
 #include 
 
-/*
- * This is a hook which is initialised by the dtrace module
- * to handle traps which might occur during DTrace probe
- * execution.
- */
-dtrace_trap_func_t dtrace_trap_fu

svn commit: r266826 - head/sys/sys

2014-05-28 Thread Mark Johnston
Author: markj
Date: Thu May 29 01:41:19 2014
New Revision: 266826
URL: http://svnweb.freebsd.org/changeset/base/266826

Log:
  Move some duplicated hook definitions from machine-dependent files to
  kern_dtrace.c.
  
  Reviewed by:  rpaulo
  MFC after:1 week

Modified:
  head/sys/sys/dtrace_bsd.h

Modified: head/sys/sys/dtrace_bsd.h
==
--- head/sys/sys/dtrace_bsd.h   Thu May 29 01:01:54 2014(r266825)
+++ head/sys/sys/dtrace_bsd.h   Thu May 29 01:41:19 2014(r266826)
@@ -59,10 +59,12 @@ int dtrace_trap(struct trapframe *, u_in
 
 extern dtrace_trap_func_t  dtrace_trap_func;
 
-/* Used by the machine dependent trap() code. */
+/*
+ * A hook which removes active FBT probes before executing the double fault
+ * handler. We want to ensure that DTrace doesn't trigger another trap, which
+ * would result in a reset.
+ */
 typedef void (*dtrace_doubletrap_func_t)(void);
-
-/* Global variables in trap.c */
 extern dtrace_doubletrap_func_tdtrace_doubletrap_func;
 
 /* Pid provider hooks */
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r266822 - head/sys/netipsec

2014-05-28 Thread Bjoern A. Zeeb
Author: bz
Date: Wed May 28 23:01:20 2014
New Revision: 266822
URL: http://svnweb.freebsd.org/changeset/base/266822

Log:
  Use IPv4 statistics in ipsec4_process_packet() rather than the IPv6
  version.  This also unbreaks the NOINET6 builds after r266800.

Modified:
  head/sys/netipsec/ipsec_output.c

Modified: head/sys/netipsec/ipsec_output.c
==
--- head/sys/netipsec/ipsec_output.cWed May 28 19:59:27 2014
(r266821)
+++ head/sys/netipsec/ipsec_output.cWed May 28 23:01:20 2014
(r266822)
@@ -576,7 +576,7 @@ ipsec4_process_packet(
DPRINTF(("%s: unsupported protocol family %u\n",
 __func__, dst->sa.sa_family));
error = EPFNOSUPPORT;
-   IPSEC6STAT_INC(ips_out_inval);
+   IPSECSTAT_INC(ips_out_inval);
goto bad;
}
error = (*sav->tdb_xform->xf_output)(m, isr, NULL, i, off);
@@ -739,4 +739,4 @@ bad:
m_freem(m);
return error;
 }
-#endif /*INET6*/
\ No newline at end of file
+#endif /*INET6*/
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r266821 - head/sys/i386/conf

2014-05-28 Thread Marius Strobl
Author: marius
Date: Wed May 28 19:59:27 2014
New Revision: 266821
URL: http://svnweb.freebsd.org/changeset/base/266821

Log:
  - Actually, modules are built correctly when compiled along the kernel as
they then pick up an opt_global.h from KERNBUILDDIR having PAE defined.
Thus, build all modules by default except those which still really are
defective as of r266799.
  - Minor style cleanup.
  
  MFC after:1 week

Modified:
  head/sys/i386/conf/PAE

Modified: head/sys/i386/conf/PAE
==
--- head/sys/i386/conf/PAE  Wed May 28 19:58:00 2014(r266820)
+++ head/sys/i386/conf/PAE  Wed May 28 19:59:27 2014(r266821)
@@ -10,12 +10,8 @@ identPAE-GENERIC
 # To make a PAE kernel, the next option is needed
 optionsPAE # Physical Address Extensions Kernel
 
-# Don't build modules with this kernel config, since they are not built with
-# the correct options headers.
-makeoptionsNO_MODULES=yes
-
-# force isp firmware to fully loaded
-device ispfw
+# The following modules don't build with PAE enabled.
+makeoptionsWITHOUT_MODULES="ctl dpt hptmv ida malo mwl"
 
 # What follows is a list of drivers that are normally in GENERIC, but either
 # don't work or are untested with PAE.  Be very careful before enabling any
@@ -23,7 +19,6 @@ deviceispfw
 # address properly may cause data corruption when used in a machine with more
 # than 4 gigabytes of memory.
 
-
 nodevice   ahb
 nodevice   sym
 nodevice   trm
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r266820 - head/sys/i386/conf

2014-05-28 Thread Marius Strobl
Author: marius
Date: Wed May 28 19:58:00 2014
New Revision: 266820
URL: http://svnweb.freebsd.org/changeset/base/266820

Log:
  - Shrink the list of excluded modules to what actually still doesn't build
as of r266799.
  - Some style cleanups.
  
  MFC after:1 week

Modified:
  head/sys/i386/conf/XEN

Modified: head/sys/i386/conf/XEN
==
--- head/sys/i386/conf/XEN  Wed May 28 19:52:01 2014(r266819)
+++ head/sys/i386/conf/XEN  Wed May 28 19:58:00 2014(r266820)
@@ -7,11 +7,12 @@ cpu   I686_CPU
 ident  XEN
 
 makeoptionsDEBUG=-g
-makeoptionsWITHOUT_MODULES="aha ahb amd ctl cxgb dpt drm drm2 hptnr hptmv 
ida malo mpr mps mwl rdma sound sym trm xfs"
+
+# The following modules don't build with PAE and XEN enabled.
+makeoptionsWITHOUT_MODULES="ctl dpt drm drm2 hptmv ida malo mwl"
 
 optionsSCHED_ULE   # ULE scheduler
 optionsPREEMPTION  # Enable kernel thread preemption
-#options   SCHED_4BSD   
 
 optionsINET# InterNETworking
 optionsINET6   # IPv6 communications protocols
@@ -65,7 +66,6 @@ options   MCLSHIFT=12
 optionsSMP # Symmetric MultiProcessor Kernel
 device apic# I/O APIC
 
-
 #deviceatkbdc  # AT keyboard controller
 #deviceatkbd   # AT keyboard
 device psm # PS/2 mouse
@@ -90,4 +90,3 @@ options   AH_SUPPORT_AR5416
 # Be aware of the administrative consequences of enabling this!
 # Note that 'bpf' is required for DHCP.
 device bpf # Berkeley packet filter
-
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r266553 - head/release/scripts

2014-05-28 Thread Warner Losh

On May 28, 2014, at 9:47 AM, Konstantin Belousov  wrote:

> On Wed, May 28, 2014 at 09:35:27AM -0600, Warner Losh wrote:
>> 
>> On May 28, 2014, at 9:28 AM, Konstantin Belousov  wrote:
>> 
>>> On Wed, May 28, 2014 at 08:26:58AM -0600, Warner Losh wrote:
 
 Then we disagree on this point. However, the disagreement here is
 kinda foundational: to build a set of libraries or sys root, you have
 to have a MACHINE_ARCH to make it work. Even in our current system, we
 set MACHINE_ARCH to i386 or powerpc when building the 32-bit binaries
 (note: we don?t do this for mips). This means that if we do grow x32
 support, we?ll need to grow a MACHINE_ARCH for it. That?s my point:
 all ABIs have MACHINE_ARCH associated with them, and those are the
 names users are used to specifying, and are the ones that are the most
 natural for script writers to use. With nathan?s patches, we?re to the
 point where those are used, though there?s also the option of using
 the non-standard names if you want (e.g. amd64:32 instead of x32).
 
>>> 
>>> I am not sure if this comment would add anything to the discussion,
>>> but other build systems do not require MACHINE_ARCH.  In our terms,
>>> other build systems are happy to build:
>>> i386 binary when MACHINE is amd64 and CFLAGS contains -m32;
>>> x32 binary when MACHINE is amd64 and CFLAGS contains -mx32.
>>> 
>>> For HEAD and stable/10 we finally reached the point where -m32 works,
>>> on amd64; it worked on powerpc64 from inception, AFAIU Nathan. At least
>>> this is true for dependencies limited to the base system, and not to the
>>> ports (the later is since ports do not know about multiarch).
>>> 
>>> It is limitation of our build that we require MACHINE_ARCH to build
>>> other natively supported ABI binary on the host. Ideally, the hacks that
>>> treat lib32 build as the cross-compilation would go away eventually.
>> 
>> I doubt it. The MACHINE_ARCH is used to select which files to build.
> Do I understand you right that the comment references e.g. a selection
> of arch-specific subdir in lib/libc or libexec/rtld-elf for inclusion
> into the build ? If yes, I cannot disagree with the statement.

As far as I can tell, that’s the only reason we’re doing it..  But it is a 
critically important reason...

> My note was about our build system which currently requires
> full-fledged cross-build to even create i386 binary on amd64 vs. other
> builds which consider this as a (often minor) variations of the host
> target. Sure, some variances must be allowed, e.g. to select proper .S
> file for the ABI, but we do not need cross-build to get i386 on amd64.

lib32 uses -m32 and some other flags to achieve its ends. So it doesn’t create 
a full i386 compiler, etc. It just uses the amd64 one with special flags/args. 
So I don’t think it requires a full-fledged cross-build environment, or I 
misunderstand what you mean by that phrase.

But none of this changes the fact that we have a unique MACHINE_ARCH value per 
ABI.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail


svn commit: r266819 - head/sys

2014-05-28 Thread John Baldwin
Author: jhb
Date: Wed May 28 19:52:01 2014
New Revision: 266819
URL: http://svnweb.freebsd.org/changeset/base/266819

Log:
  Add a temporary hack to change the various non-build related special
  targets like 'cscope' and 'glimpse' to not depend on src.opts.mk or
  bsd.*.mk.
  
  Reviewed by:  imp

Modified:
  head/sys/Makefile

Modified: head/sys/Makefile
==
--- head/sys/Makefile   Wed May 28 19:05:46 2014(r266818)
+++ head/sys/Makefile   Wed May 28 19:52:01 2014(r266819)
@@ -1,11 +1,14 @@
 # $FreeBSD$
 
+.if !(make(cscope) || make(cscope-clean) || make(cscope-hook) || make(TAGS) || 
\
+make(glimpse) || make(glimpse-clean))
 .include 
 
 # The boot loader
 .if ${MK_BOOT} != "no"
 SUBDIR=boot
 .endif
+.endif
 
 # Directories to include in cscope name file and TAGS.
 CSCOPEDIRS=boot bsm cam cddl compat conf contrib crypto ddb dev fs gdb \
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r266814 - head/sys/kern

2014-05-28 Thread Don Lewis
Author: truckman
Date: Wed May 28 16:57:17 2014
New Revision: 266814
URL: http://svnweb.freebsd.org/changeset/base/266814

Log:
  Initialize r_flags the same way in all cases using a sanitized copy of
  flags that has several bits cleared. The RF_WANTED and RF_FIRSTSHARE
  bits are invalid in this context, and we want to defer setting RF_ACTIVE
  in r_flags until later.  This should make rman_get_flags() return
  the correct answer in all cases.
  
  Add a KASSERT() to catch callers which incorrectly pass the RF_WANTED
  or RF_FIRSTSHARE flags.
  
  Do a strict equality check on the share type bits of flags.  In
  particular, do an equality check on RF_PREFETCHABLE.  The previous
  code would allow one type of mismatch of RF_PREFETCHABLE but disallow
  the other type of mismatch.  Also, ignore the the RF_ALIGNMENT_MASK
  bits since alignment validity should be handled by the amask check.
  This field contains an integer value, but previous code did a strange
  bitwise comparison on it.
  
  Leave the original value of flags unmolested as a minor debug aid.
  
  Change the start+amask overflow check to a KASSERT() since it is just
  meant to catch a highly unlikely programming error in the caller.
  
  Reviewed by:  jhb
  MFC after:1 month

Modified:
  head/sys/kern/subr_rman.c

Modified: head/sys/kern/subr_rman.c
==
--- head/sys/kern/subr_rman.c   Wed May 28 16:50:18 2014(r266813)
+++ head/sys/kern/subr_rman.c   Wed May 28 16:57:17 2014(r266814)
@@ -435,12 +435,14 @@ rman_adjust_resource(struct resource *rr
return (0);
 }
 
+#defineSHARE_TYPE(f)   (f & (RF_SHAREABLE | RF_TIMESHARE | 
RF_PREFETCHABLE))
+
 struct resource *
 rman_reserve_resource_bound(struct rman *rm, u_long start, u_long end,
  u_long count, u_long bound,  u_int flags,
  struct device *dev)
 {
-   u_int   want_activate;
+   u_int   new_rflags;
struct  resource_i *r, *s, *rv;
u_long  rstart, rend, amask, bmask;
 
@@ -450,8 +452,10 @@ rman_reserve_resource_bound(struct rman 
   "length %#lx, flags %u, device %s\n", rm->rm_descr, start, end,
   count, flags,
   dev == NULL ? "" : device_get_nameunit(dev)));
-   want_activate = (flags & RF_ACTIVE);
-   flags &= ~RF_ACTIVE;
+   KASSERT((flags & (RF_WANTED | RF_FIRSTSHARE)) == 0,
+   ("invalid flags %#x", flags));
+   new_rflags = (flags & ~(RF_ACTIVE | RF_WANTED | RF_FIRSTSHARE)) |
+   RF_ALLOCATED;
 
mtx_lock(rm->rm_mtx);
 
@@ -466,10 +470,8 @@ rman_reserve_resource_bound(struct rman 
}
 
amask = (1ul << RF_ALIGNMENT(flags)) - 1;
-   if (start > ULONG_MAX - amask) {
-   DPRINTF(("start+amask would wrap around\n"));
-   goto out;
-   }
+   KASSERT(start <= ULONG_MAX - amask,
+   ("start (%#lx) + amask (%#lx) would wrap around", start, amask));
 
/* If bound is 0, bmask will also be 0 */
bmask = ~(bound - 1);
@@ -522,7 +524,7 @@ rman_reserve_resource_bound(struct rman 
if ((s->r_end - s->r_start + 1) == count) {
DPRINTF(("candidate region is entire chunk\n"));
rv = s;
-   rv->r_flags |= RF_ALLOCATED | flags;
+   rv->r_flags = new_rflags;
rv->r_dev = dev;
goto out;
}
@@ -542,7 +544,7 @@ rman_reserve_resource_bound(struct rman 
goto out;
rv->r_start = rstart;
rv->r_end = rstart + count - 1;
-   rv->r_flags = flags | RF_ALLOCATED;
+   rv->r_flags = new_rflags;
rv->r_dev = dev;
rv->r_rm = rm;
 
@@ -603,7 +605,7 @@ rman_reserve_resource_bound(struct rman 
goto out;
 
for (s = r; s && s->r_end <= end; s = TAILQ_NEXT(s, r_link)) {
-   if ((s->r_flags & flags) == flags &&
+   if (SHARE_TYPE(s->r_flags) == SHARE_TYPE(flags) &&
s->r_start >= start &&
(s->r_end - s->r_start + 1) == count &&
(s->r_start & amask) == 0 &&
@@ -613,8 +615,7 @@ rman_reserve_resource_bound(struct rman 
goto out;
rv->r_start = s->r_start;
rv->r_end = s->r_end;
-   rv->r_flags = s->r_flags &
-   (RF_ALLOCATED | RF_SHAREABLE | RF_TIMESHARE);
+   rv->r_flags = new_rflags;
rv->r_dev = dev;
rv->r_rm = rm;
if (s->r_sharehead == NULL) {
@@ -641,13 +642,12 @@ rman_reserve_resource_bound(struct rman 
   

svn commit: r266813 - head/lib/libcrypt

2014-05-28 Thread Hajimu UMEMOTO
Author: ume
Date: Wed May 28 16:50:18 2014
New Revision: 266813
URL: http://svnweb.freebsd.org/changeset/base/266813

Log:
  Don't break the legacy applications which set
  just 2 bytes to salt.
  
  MFC after:1 week

Modified:
  head/lib/libcrypt/crypt.c

Modified: head/lib/libcrypt/crypt.c
==
--- head/lib/libcrypt/crypt.c   Wed May 28 16:28:22 2014(r266812)
+++ head/lib/libcrypt/crypt.c   Wed May 28 16:50:18 2014(r266813)
@@ -104,12 +104,16 @@ char *
 crypt(const char *passwd, const char *salt)
 {
const struct crypt_format *cf;
+#ifdef HAS_DES
+   int len;
+#endif
 
for (cf = crypt_formats; cf->name != NULL; ++cf)
if (cf->magic != NULL && strstr(salt, cf->magic) == salt)
return (cf->func(passwd, salt));
 #ifdef HAS_DES
-   if (strlen(salt) == 13 && strspn(salt, DES_SALT_ALPHABET) == 13)
+   len = strlen(salt);
+   if ((len == 13 || len == 2) && strspn(salt, DES_SALT_ALPHABET) == len)
return (crypt_des(passwd, salt));
 #endif
return (crypt_format->func(passwd, salt));
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r266553 - head/release/scripts

2014-05-28 Thread Nathan Whitehorn

On 05/28/14 08:47, Konstantin Belousov wrote:

On Wed, May 28, 2014 at 09:35:27AM -0600, Warner Losh wrote:

On May 28, 2014, at 9:28 AM, Konstantin Belousov  wrote:


On Wed, May 28, 2014 at 08:26:58AM -0600, Warner Losh wrote:

Then we disagree on this point. However, the disagreement here is
kinda foundational: to build a set of libraries or sys root, you have
to have a MACHINE_ARCH to make it work. Even in our current system, we
set MACHINE_ARCH to i386 or powerpc when building the 32-bit binaries
(note: we don?t do this for mips). This means that if we do grow x32
support, we?ll need to grow a MACHINE_ARCH for it. That?s my point:
all ABIs have MACHINE_ARCH associated with them, and those are the
names users are used to specifying, and are the ones that are the most
natural for script writers to use. With nathan?s patches, we?re to the
point where those are used, though there?s also the option of using
the non-standard names if you want (e.g. amd64:32 instead of x32).


I am not sure if this comment would add anything to the discussion,
but other build systems do not require MACHINE_ARCH.  In our terms,
other build systems are happy to build:
i386 binary when MACHINE is amd64 and CFLAGS contains -m32;
x32 binary when MACHINE is amd64 and CFLAGS contains -mx32.

For HEAD and stable/10 we finally reached the point where -m32 works,
on amd64; it worked on powerpc64 from inception, AFAIU Nathan. At least
this is true for dependencies limited to the base system, and not to the
ports (the later is since ports do not know about multiarch).

It is limitation of our build that we require MACHINE_ARCH to build
other natively supported ABI binary on the host. Ideally, the hacks that
treat lib32 build as the cross-compilation would go away eventually.

I doubt it. The MACHINE_ARCH is used to select which files to build.

Do I understand you right that the comment references e.g. a selection
of arch-specific subdir in lib/libc or libexec/rtld-elf for inclusion
into the build ? If yes, I cannot disagree with the statement.

My note was about our build system which currently requires
full-fledged cross-build to even create i386 binary on amd64 vs. other
builds which consider this as a (often minor) variations of the host
target. Sure, some variances must be allowed, e.g. to select proper .S
file for the ABI, but we do not need cross-build to get i386 on amd64.


Does it actually do that? "Full cross-build" implies it builds a new 
compiler, at least to me, but it just builds with -m32 and changes 
MACHINE_ARCH.


In any case, I think we have gotten lots of issues crossed here. I'll 
try to separate them out:


1. We will not ever have mixed-and-matched x32 and amd64 packages on one 
system without a massive overhaul of ports, since you can't link x32 
binaries against amd64 libraries and vice versa. Handling that requires 
more dependency tracking and, at a minimum, something like 
/usr/local/lib-$MACHINE_ARCH. Maybe that's worth doing -- I don't know 
-- but it is very different from -fPIC and is an orthogonal discussion.


2. PowerPC is, as you note, arguably the most integrated 32/64-bit port 
we have, since it was originally specified as a 64-bit instruction set. 
32-bit PowerPC is much more analogous to something like x32 than to 
i386. And it still has a different MACHINE_ARCH, needs a different C 
library and RTLD (and not through #ifdef!), etc.


3. The whole discussion was originally about what we call packages. Do 
we use the same arbitray names that the base system and ports use, or do 
we use different arbitrary names? That I think has been resolved. I 
suspect the actual patches got lost in this very long thread, so I'll 
forward them to freebsd-ports@ shortly.

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


svn commit: r266812 - head/sys/dev/usb/controller

2014-05-28 Thread Hans Petter Selasky
Author: hselasky
Date: Wed May 28 16:28:22 2014
New Revision: 266812
URL: http://svnweb.freebsd.org/changeset/base/266812

Log:
  Fixes for ISP/SAF1761 host mode:
  - Make the USB hardware skip PTDs which are not allocated.
  - Peek host memory twice. Sometimes the PTD status is incorrectly
  returned as zero.
  - Ensure the host channel is always freed when software TD
  is completing.
  - Add correct configuration of interrupt polarity and type.
  - Set CERR to 2 for asynchronous traffic to avoid having to
  reactivate the PTD when a NAK token is received.
  - Fix detection of STALL PID.
  
  Sponsored by: DARPA, AFRL

Modified:
  head/sys/dev/usb/controller/saf1761_otg.c
  head/sys/dev/usb/controller/saf1761_otg_fdt.c
  head/sys/dev/usb/controller/saf1761_otg_reg.h

Modified: head/sys/dev/usb/controller/saf1761_otg.c
==
--- head/sys/dev/usb/controller/saf1761_otg.c   Wed May 28 15:24:30 2014
(r266811)
+++ head/sys/dev/usb/controller/saf1761_otg.c   Wed May 28 16:28:22 2014
(r266812)
@@ -252,25 +252,24 @@ saf1761_host_channel_free(struct saf1761
if (td->channel >= SOTG_HOST_CHANNEL_MAX)
return;
 
-   /* disable channel */
-   SAF1761_WRITE_LE_4(sc, SOTG_PTD(td->channel) + SOTG_PTD_DW3, 0);
-   SAF1761_WRITE_LE_4(sc, SOTG_PTD(td->channel) + SOTG_PTD_DW0, 0);
-
switch (td->ep_type) {
case UE_INTERRUPT:
x = td->channel - 32;
-   sc->sc_host_intr_map &= ~(1 << x);
td->channel = SOTG_HOST_CHANNEL_MAX;
+   sc->sc_host_intr_map &= ~(1 << x);
+   SAF1761_WRITE_LE_4(sc, SOTG_INT_PTD_SKIP_PTD, 
~sc->sc_host_intr_map);
break;
case UE_ISOCHRONOUS:
x = td->channel;
-   sc->sc_host_isoc_map &= ~(1 << x);
td->channel = SOTG_HOST_CHANNEL_MAX;
+   sc->sc_host_isoc_map &= ~(1 << x);
+   SAF1761_WRITE_LE_4(sc, SOTG_ISO_PTD_SKIP_PTD, 
~sc->sc_host_isoc_map);
break;
default:
x = td->channel - 64;
-   sc->sc_host_async_map &= ~(1 << x);
td->channel = SOTG_HOST_CHANNEL_MAX;
+   sc->sc_host_async_map &= ~(1 << x);
+   SAF1761_WRITE_LE_4(sc, SOTG_ATL_PTD_SKIP_PTD, 
~sc->sc_host_async_map);
break;
}
 }
@@ -401,19 +400,16 @@ saf1761_host_setup_tx(struct saf1761_otg
pdt_addr = SOTG_PTD(td->channel);
 
status = saf1761_peek_host_memory_le_4(sc, pdt_addr + 
SOTG_PTD_DW3);
+   if (status == 0)
+   status = saf1761_peek_host_memory_le_4(sc, pdt_addr + 
SOTG_PTD_DW3);
+
DPRINTFN(5, "STATUS=0x%08x\n", status);
 
if (status & SOTG_PTD_DW3_ACTIVE) {
goto busy;
} else if (status & SOTG_PTD_DW3_HALTED) {
-   td->error_stall = 1;
-   td->error_any = 1;
-   } else if (status & SOTG_PTD_DW3_ERRORS) {
td->error_any = 1;
}
-   count = (status & SOTG_PTD_DW3_XFER_COUNT);
-
-   saf1761_host_channel_free(sc, td);
goto complete;
}
if (saf1761_host_channel_alloc(sc, td))
@@ -435,7 +431,7 @@ saf1761_host_setup_tx(struct saf1761_otg
SAF1761_WRITE_LE_4(sc, pdt_addr + SOTG_PTD_DW5, 0);
SAF1761_WRITE_LE_4(sc, pdt_addr + SOTG_PTD_DW4, 0);
 
-   temp = SOTG_PTD_DW3_ACTIVE | (td->toggle << 25) | SOTG_PTD_DW3_CERR;
+   temp = SOTG_PTD_DW3_ACTIVE | (td->toggle << 25) | SOTG_PTD_DW3_CERR_3;
SAF1761_WRITE_LE_4(sc, pdt_addr + SOTG_PTD_DW3, temp);

temp = SOTG_HC_MEMORY_ADDR(SOTG_DATA_ADDR(td->channel)) << 8;
@@ -450,10 +446,14 @@ saf1761_host_setup_tx(struct saf1761_otg
SOTG_PTD_DW0_VALID;
SAF1761_WRITE_LE_4(sc, pdt_addr + SOTG_PTD_DW0, temp);
 
+   /* activate PTD */
+   SAF1761_WRITE_LE_4(sc, SOTG_ATL_PTD_SKIP_PTD, ~sc->sc_host_async_map);
+
td->toggle = 1;
 busy:
return (1); /* busy */
 complete:
+   saf1761_host_channel_free(sc, td);
return (0); /* complete */
 }
 
@@ -471,15 +471,16 @@ saf1761_host_bulk_data_rx(struct saf1761
pdt_addr = SOTG_PTD(td->channel);
 
status = saf1761_peek_host_memory_le_4(sc, pdt_addr + 
SOTG_PTD_DW3);
+   if (status == 0)
+   status = saf1761_peek_host_memory_le_4(sc, pdt_addr + 
SOTG_PTD_DW3);
+
DPRINTFN(5, "STATUS=0x%08x\n", status);
 
if (status & SOTG_PTD_DW3_ACTIVE) {
goto busy;
} else if (status & SOTG_PTD_DW3_HALTED) {
-   td->error_stall = 1;
-   td->error_any = 1;
-   goto complete;
-   } else if (status & SOTG_PT

Re: svn commit: r266553 - head/release/scripts

2014-05-28 Thread Konstantin Belousov
On Wed, May 28, 2014 at 09:35:27AM -0600, Warner Losh wrote:
> 
> On May 28, 2014, at 9:28 AM, Konstantin Belousov  wrote:
> 
> > On Wed, May 28, 2014 at 08:26:58AM -0600, Warner Losh wrote:
> >> 
> >> Then we disagree on this point. However, the disagreement here is
> >> kinda foundational: to build a set of libraries or sys root, you have
> >> to have a MACHINE_ARCH to make it work. Even in our current system, we
> >> set MACHINE_ARCH to i386 or powerpc when building the 32-bit binaries
> >> (note: we don?t do this for mips). This means that if we do grow x32
> >> support, we?ll need to grow a MACHINE_ARCH for it. That?s my point:
> >> all ABIs have MACHINE_ARCH associated with them, and those are the
> >> names users are used to specifying, and are the ones that are the most
> >> natural for script writers to use. With nathan?s patches, we?re to the
> >> point where those are used, though there?s also the option of using
> >> the non-standard names if you want (e.g. amd64:32 instead of x32).
> >> 
> > 
> > I am not sure if this comment would add anything to the discussion,
> > but other build systems do not require MACHINE_ARCH.  In our terms,
> > other build systems are happy to build:
> > i386 binary when MACHINE is amd64 and CFLAGS contains -m32;
> > x32 binary when MACHINE is amd64 and CFLAGS contains -mx32.
> > 
> > For HEAD and stable/10 we finally reached the point where -m32 works,
> > on amd64; it worked on powerpc64 from inception, AFAIU Nathan. At least
> > this is true for dependencies limited to the base system, and not to the
> > ports (the later is since ports do not know about multiarch).
> > 
> > It is limitation of our build that we require MACHINE_ARCH to build
> > other natively supported ABI binary on the host. Ideally, the hacks that
> > treat lib32 build as the cross-compilation would go away eventually.
> 
> I doubt it. The MACHINE_ARCH is used to select which files to build.
Do I understand you right that the comment references e.g. a selection
of arch-specific subdir in lib/libc or libexec/rtld-elf for inclusion
into the build ? If yes, I cannot disagree with the statement.

My note was about our build system which currently requires
full-fledged cross-build to even create i386 binary on amd64 vs. other
builds which consider this as a (often minor) variations of the host
target. Sure, some variances must be allowed, e.g. to select proper .S
file for the ABI, but we do not need cross-build to get i386 on amd64.


pgpByBEJWf8mu.pgp
Description: PGP signature


Re: svn commit: r266806 - head/sys/netgraph

2014-05-28 Thread Julian Elischer

On 5/28/14, 10:56 PM, Gleb Smirnoff wrote:

On Wed, May 28, 2014 at 10:12:32PM +0800, Julian Elischer wrote:
J> On 5/28/14, 9:15 PM, Gleb Smirnoff wrote:
J> > Author: glebius
J> > Date: Wed May 28 13:15:14 2014
J> > New Revision: 266806
J> > URL: http://svnweb.freebsd.org/changeset/base/266806
J> >
J> > Log:
J> >Use M_WAITOK for the NGM_PIPE_SET_CFG control message. We expect it to
J> >arrive from userland only.
J> >
J> >Submitted by: Dmitry Luhtionov 
J> what's to stop another node from generating it and sending it on?
J> generally a message may come from anywhere.
J> Just becasue YOU don't have module that
J> sends messages to ng_pipe, doesn't mean there never will be..
J> also there are cases when the locking may force a message to be
J> delivered asynchronously.

I know that. After resolving many issues with netgraph, I feel that
our policy should be towards putting some invariants on what events
SHOULD come from userland only and which events SHOULD be serviced
without memory failures.

Current paradigma that messages are fully symmetrical and can come
from anywhere are quite a curious thought experiment. I liked that
for a long time. But in practice if we want to build a robust software
we should make more strict rules of using it.

You could disagree, but if you try to fix this particular one liner
in the paradigma of "messages come from anywhere", then you will end
up with smth like 20 lines of code to this particular module. Next
comes the need to fix any software or script that sends NGM_PIPE_SET_CFG,
it now should be taught of dealing with ENOMEM. So, instead of one
liner you will bury yourself under tons of work.



Then I suggest that we increment the protocol, and add support to messages
to say whether they come from user space.
and some providers only accept such messages.

I have lost track of the code so I don't know if my comment about
messages getting queued instead of delivered is still true.
However if it is, then a message could be delivered by a kernel agent 
even

if it is initiated by a userspace program.


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


Re: svn commit: r266553 - head/release/scripts

2014-05-28 Thread Warner Losh

On May 28, 2014, at 9:28 AM, Konstantin Belousov  wrote:

> On Wed, May 28, 2014 at 08:26:58AM -0600, Warner Losh wrote:
>> 
>> Then we disagree on this point. However, the disagreement here is
>> kinda foundational: to build a set of libraries or sys root, you have
>> to have a MACHINE_ARCH to make it work. Even in our current system, we
>> set MACHINE_ARCH to i386 or powerpc when building the 32-bit binaries
>> (note: we don?t do this for mips). This means that if we do grow x32
>> support, we?ll need to grow a MACHINE_ARCH for it. That?s my point:
>> all ABIs have MACHINE_ARCH associated with them, and those are the
>> names users are used to specifying, and are the ones that are the most
>> natural for script writers to use. With nathan?s patches, we?re to the
>> point where those are used, though there?s also the option of using
>> the non-standard names if you want (e.g. amd64:32 instead of x32).
>> 
> 
> I am not sure if this comment would add anything to the discussion,
> but other build systems do not require MACHINE_ARCH.  In our terms,
> other build systems are happy to build:
> i386 binary when MACHINE is amd64 and CFLAGS contains -m32;
> x32 binary when MACHINE is amd64 and CFLAGS contains -mx32.
> 
> For HEAD and stable/10 we finally reached the point where -m32 works,
> on amd64; it worked on powerpc64 from inception, AFAIU Nathan. At least
> this is true for dependencies limited to the base system, and not to the
> ports (the later is since ports do not know about multiarch).
> 
> It is limitation of our build that we require MACHINE_ARCH to build
> other natively supported ABI binary on the host. Ideally, the hacks that
> treat lib32 build as the cross-compilation would go away eventually.

I doubt it. The MACHINE_ARCH is used to select which files to build.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: svn commit: r266553 - head/release/scripts

2014-05-28 Thread Konstantin Belousov
On Wed, May 28, 2014 at 08:26:58AM -0600, Warner Losh wrote:
> 
> Then we disagree on this point. However, the disagreement here is
> kinda foundational: to build a set of libraries or sys root, you have
> to have a MACHINE_ARCH to make it work. Even in our current system, we
> set MACHINE_ARCH to i386 or powerpc when building the 32-bit binaries
> (note: we don?t do this for mips). This means that if we do grow x32
> support, we?ll need to grow a MACHINE_ARCH for it. That?s my point:
> all ABIs have MACHINE_ARCH associated with them, and those are the
> names users are used to specifying, and are the ones that are the most
> natural for script writers to use. With nathan?s patches, we?re to the
> point where those are used, though there?s also the option of using
> the non-standard names if you want (e.g. amd64:32 instead of x32).
>

I am not sure if this comment would add anything to the discussion,
but other build systems do not require MACHINE_ARCH.  In our terms,
other build systems are happy to build:
i386 binary when MACHINE is amd64 and CFLAGS contains -m32;
x32 binary when MACHINE is amd64 and CFLAGS contains -mx32.

For HEAD and stable/10 we finally reached the point where -m32 works,
on amd64; it worked on powerpc64 from inception, AFAIU Nathan. At least
this is true for dependencies limited to the base system, and not to the
ports (the later is since ports do not know about multiarch).

It is limitation of our build that we require MACHINE_ARCH to build
other natively supported ABI binary on the host. Ideally, the hacks that
treat lib32 build as the cross-compilation would go away eventually.


pgpeySv5p9K4i.pgp
Description: PGP signature


Re: svn commit: r266806 - head/sys/netgraph

2014-05-28 Thread Gleb Smirnoff
On Wed, May 28, 2014 at 10:12:32PM +0800, Julian Elischer wrote:
J> On 5/28/14, 9:15 PM, Gleb Smirnoff wrote:
J> > Author: glebius
J> > Date: Wed May 28 13:15:14 2014
J> > New Revision: 266806
J> > URL: http://svnweb.freebsd.org/changeset/base/266806
J> >
J> > Log:
J> >Use M_WAITOK for the NGM_PIPE_SET_CFG control message. We expect it to
J> >arrive from userland only.
J> >
J> >Submitted by:   Dmitry Luhtionov 
J> what's to stop another node from generating it and sending it on?
J> generally a message may come from anywhere.
J> Just becasue YOU don't have module that
J> sends messages to ng_pipe, doesn't mean there never will be..
J> also there are cases when the locking may force a message to be 
J> delivered asynchronously.

I know that. After resolving many issues with netgraph, I feel that
our policy should be towards putting some invariants on what events
SHOULD come from userland only and which events SHOULD be serviced
without memory failures.

Current paradigma that messages are fully symmetrical and can come
from anywhere are quite a curious thought experiment. I liked that
for a long time. But in practice if we want to build a robust software
we should make more strict rules of using it.

You could disagree, but if you try to fix this particular one liner
in the paradigma of "messages come from anywhere", then you will end
up with smth like 20 lines of code to this particular module. Next
comes the need to fix any software or script that sends NGM_PIPE_SET_CFG,
it now should be taught of dealing with ENOMEM. So, instead of one
liner you will bury yourself under tons of work.


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


svn commit: r266808 - head/sys/dev/sound/pci

2014-05-28 Thread Marius Strobl
Author: marius
Date: Wed May 28 14:26:46 2014
New Revision: 266808
URL: http://svnweb.freebsd.org/changeset/base/266808

Log:
  Actually, just merge r233362 and do away with the unnecessary uint8_t
  pointer casting altogether.

Modified:
  head/sys/dev/sound/pci/emu10k1.c

Modified: head/sys/dev/sound/pci/emu10k1.c
==
--- head/sys/dev/sound/pci/emu10k1.cWed May 28 13:27:14 2014
(r266807)
+++ head/sys/dev/sound/pci/emu10k1.cWed May 28 14:26:46 2014
(r266808)
@@ -1378,7 +1378,7 @@ emu_memalloc(struct sc_info *sc, u_int32
ofs = 0;
for (idx = start; idx < start + blksz; idx++) {
mem->bmap[idx >> 3] |= 1 << (idx & 7);
-   tmp = (uintptr_t)((u_int8_t *)(uintptr_t)blk->buf_addr + ofs);
+   tmp = (uint32_t)(blk->buf_addr + ofs);
 #ifdef EMUDEBUG
printf("pte[%d] -> %x phys, %x virt\n", idx, tmp,
((u_int32_t)buf) + ofs);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r266553 - head/release/scripts

2014-05-28 Thread Warner Losh

On May 28, 2014, at 4:50 AM, Tijl Coosemans  wrote:

> On Tue, 27 May 2014 14:31:44 -0600 Warner Losh wrote:
>> On May 27, 2014, at 1:40 PM, Tijl Coosemans  wrote:
>>> On Tue, 27 May 2014 07:18:06 -0600 Warner Losh wrote:
 On May 27, 2014, at 1:36 AM, Tijl Coosemans  wrote:
> On Mon, 26 May 2014 16:31:21 -0600 Warner Losh wrote:
 So I?m still waiting for a use case that requires the new names. One has
 not been articulated, and I don?t think one actually exists.
>>> 
>>> Imagine you've built a system with MACHINE_ARCH amd64 and one with
>>> MACHINE_ARCH mips64.  Now you want to populate these systems with a list
>>> of packages for which you wrote a script.  These systems each support 2
>>> ABIs: a native 64-bit one (amd64 and mips64) and a native 32-bit one (x32
>>> and mipsn32).  Both are native in the sense that they make full use of the
>>> instruction set.  This is not like i386 on amd64 or mips o32 on mips64
>>> because those are more like compat shims that operate under special
>>> (crippled) cpu modes that nobody uses unless they're stuck with old code.
>>> Both our ABIs on the other hand are native and equally valid and which one
>>> to use for a particular package depends entirely on the use case.  If your
>>> use case requires more than 4G of address space you'll have to use the
>>> 64-bit package, otherwise you can use the 32-bit package which, depending
>>> on how pointer heavy the code is, may give a performance benefit.  You
>>> make this choice for each of the packages in your list and add that
>>> information to your script.
>> 
>> Long hypothetical, but so what? In such a case, you’d pick one of two
>> different MACHINE_ARCH values depending on the package. This this is a
>> fairly atypical use case, it would not be unreasonable for the person
>> wanting to do this to know the proper companion ABI. In both cases, you
>> have the choice of two other values to use. Which one you use will depend
>> on a variety of factors, and what might be right for one application may
>> be wrong for others.
>> 
>> And in both cases, there’s actually two choices: for amd64, you’d have
>> i386 and x32. Both of these are fine choices, and it would depend on the
>> workload which one is better (i386 has better toolchain support and
>> maturity, x32 offers some interesting theoretical wins, but doesn’t have
>> the same maturity). Same with mips64, you’d have two choices as well. In
>> both cases, you can’t just take uname/MACHINE_ARCH and slap :32 on the end.
> 
> As far as I can see nobody uses i386 on amd64 except in cases where you
> know you're dealing with i386 like an i386 jail, or you need to run an old
> i386 binary that you're stuck with, or with compat shims like Wine.  The
> choice of i386 is not comparable with the generic choice between ILP32 or
> LP64 on a 64-bit instruction set, which is why I'm ok with changing the
> "x86" in the pkg scheme to either "i386" or "amd64" like you are proposing.
> If pkg would keep using instruction set families like "x86" or "mips" then
> you could distinguish between old 32-bit, new 32-bit and new 64-bit using
> 3 generic suffixes to avoid lookup tables.  The pattern of an old 32-bit
> instruction set that got extended to 64-bit on which you can define a new
> 32-bit ABI is common to many instruction set families, but I'm ok with
> old 32-bit and new 64-bit having separate MACHINE_ARCH values.

OK. So we use MACHINE_ARCH for the pkg scheme. I’m glad we agree on this point. 
That will make adding support for pkg repos and multiple machine builds to 
nanobsd much easier.

>>> Now let's work with Nathan's patch which uses the following string to
>>> identify the pkg repository to fetch packages from:
>>> `uname -s`:`uname -r | cut -f 1 -d .`:`uname -p`
>>> 
>>> On our two systems that would be FreeBSD:11:amd64 and FreeBSD:11:mips64.
>>> Now if your script has to install the 32-bit version of a package how
>>> can it go from those two strings to FreeBSD:11:x32 or FreeBSD:11:mipsn32
>>> without a lookup table?
>> 
>> You couldn’t. Which is the whole reason I want to have them have a
>> standard name so you don’t need the lookup table for the common case.
>> This is an “off in the weeds” case, and optimizing for it doesn’t make
>> sense. Especially because in each case, you have two different 32-bit
>> ABIs to choose from. You’d have to have some kind of table in either
>> case. Also, the proper name for n32, in your current system, is
>> mips:32:n32, which (a) is wrong and (b) isn’t regular.
> 
> Well, it may not make sense to you and be off in the weeds, but it does
> to me.  Very few processes actually need more than 4G of virtual address
> space.  I cannot immediately find anything in /bin or /usr/bin for
> instance (maybe clang when compiling a very large C++ file?).
> 
> I'm not sure where you're getting mips:32:n32 from.  We're talking in the
> context of Nathan's patch here.

In the context of Nathan’s patch, mips:32:n32 is the “old” name that 

Re: svn commit: r266806 - head/sys/netgraph

2014-05-28 Thread Julian Elischer

On 5/28/14, 9:15 PM, Gleb Smirnoff wrote:

Author: glebius
Date: Wed May 28 13:15:14 2014
New Revision: 266806
URL: http://svnweb.freebsd.org/changeset/base/266806

Log:
   Use M_WAITOK for the NGM_PIPE_SET_CFG control message. We expect it to
   arrive from userland only.
   
   Submitted by:	Dmitry Luhtionov 

what's to stop another node from generating it and sending it on?
generally a message may come from anywhere.
Just becasue YOU don't have module that
sends messages to ng_pipe, doesn't mean there never will be..
also there are cases when the locking may force a message to be 
delivered asynchronously.





Modified:
   head/sys/netgraph/ng_pipe.c

Modified: head/sys/netgraph/ng_pipe.c
==
--- head/sys/netgraph/ng_pipe.c Wed May 28 13:06:53 2014(r266805)
+++ head/sys/netgraph/ng_pipe.c Wed May 28 13:15:14 2014(r266806)
@@ -471,7 +471,7 @@ parse_cfg(struct ng_pipe_hookcfg *curren
if (hinfo->ber_p == NULL)
hinfo->ber_p =
malloc((MAX_FSIZE + MAX_OHSIZE) * sizeof(uint64_t),
-   M_NG_PIPE, M_NOWAIT);
+   M_NG_PIPE, M_WAITOK);
current->ber = new->ber;
  
  		/*





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


svn commit: r266806 - head/sys/netgraph

2014-05-28 Thread Gleb Smirnoff
Author: glebius
Date: Wed May 28 13:15:14 2014
New Revision: 266806
URL: http://svnweb.freebsd.org/changeset/base/266806

Log:
  Use M_WAITOK for the NGM_PIPE_SET_CFG control message. We expect it to
  arrive from userland only.
  
  Submitted by: Dmitry Luhtionov 

Modified:
  head/sys/netgraph/ng_pipe.c

Modified: head/sys/netgraph/ng_pipe.c
==
--- head/sys/netgraph/ng_pipe.c Wed May 28 13:06:53 2014(r266805)
+++ head/sys/netgraph/ng_pipe.c Wed May 28 13:15:14 2014(r266806)
@@ -471,7 +471,7 @@ parse_cfg(struct ng_pipe_hookcfg *curren
if (hinfo->ber_p == NULL)
hinfo->ber_p =
malloc((MAX_FSIZE + MAX_OHSIZE) * sizeof(uint64_t),
-   M_NG_PIPE, M_NOWAIT);
+   M_NG_PIPE, M_WAITOK);
current->ber = new->ber;
 
/*
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r266803 - head/usr.sbin/usbdump

2014-05-28 Thread Hans Petter Selasky
Author: hselasky
Date: Wed May 28 12:58:37 2014
New Revision: 266803
URL: http://svnweb.freebsd.org/changeset/base/266803

Log:
  Remove nop.
  
  MFC after:1 week

Modified:
  head/usr.sbin/usbdump/usbdump.c

Modified: head/usr.sbin/usbdump/usbdump.c
==
--- head/usr.sbin/usbdump/usbdump.c Wed May 28 12:52:11 2014
(r266802)
+++ head/usr.sbin/usbdump/usbdump.c Wed May 28 12:58:37 2014
(r266803)
@@ -473,7 +473,6 @@ print_apacket(const struct header_32 *hd
 */
up->up_totlen = le32toh(up->up_totlen);
up->up_busunit = le32toh(up->up_busunit);
-   up->up_address = up->up_address;
up->up_flags = le32toh(up->up_flags);
up->up_status = le32toh(up->up_status);
up->up_error = le32toh(up->up_error);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r266798 - head/usr.sbin/usbdump

2014-05-28 Thread Hans Petter Selasky

On 05/28/14 14:49, Gleb Smirnoff wrote:

On Wed, May 28, 2014 at 12:27:42PM +, Hans Petter Selasky wrote:
H> Author: hselasky
H> Date: Wed May 28 12:27:41 2014
H> New Revision: 266798
H> URL: http://svnweb.freebsd.org/changeset/base/266798
H>
H> Log:
H>   Fix for big endian architectures. The "up_address" field is 8-bit and
H>   does not need byte swapping.
H>
H>   MFC after:  1 week

Do we need the assignment then? I'm surprised that compiler doesn't fail on 
that.



Right, fixed.

--HPS

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


Re: svn commit: r266798 - head/usr.sbin/usbdump

2014-05-28 Thread Gleb Smirnoff
On Wed, May 28, 2014 at 12:27:42PM +, Hans Petter Selasky wrote:
H> Author: hselasky
H> Date: Wed May 28 12:27:41 2014
H> New Revision: 266798
H> URL: http://svnweb.freebsd.org/changeset/base/266798
H> 
H> Log:
H>   Fix for big endian architectures. The "up_address" field is 8-bit and
H>   does not need byte swapping.
H>   
H>   MFC after: 1 week

Do we need the assignment then? I'm surprised that compiler doesn't fail on 
that.

H> Modified:
H>   head/usr.sbin/usbdump/usbdump.c
H> 
H> Modified: head/usr.sbin/usbdump/usbdump.c
H> 
==
H> --- head/usr.sbin/usbdump/usbdump.c  Wed May 28 11:30:37 2014
(r266797)
H> +++ head/usr.sbin/usbdump/usbdump.c  Wed May 28 12:27:41 2014
(r266798)
H> @@ -473,7 +473,7 @@ print_apacket(const struct header_32 *hd
H>   */
H>  up->up_totlen = le32toh(up->up_totlen);
H>  up->up_busunit = le32toh(up->up_busunit);
H> -up->up_address = le32toh(up->up_address);
H> +up->up_address = up->up_address;
H>  up->up_flags = le32toh(up->up_flags);
H>  up->up_status = le32toh(up->up_status);
H>  up->up_error = le32toh(up->up_error);

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


svn commit: r266800 - in head/sys: netinet6 netipsec

2014-05-28 Thread VANHULLEBUS Yvan
Author: vanhu
Date: Wed May 28 12:45:27 2014
New Revision: 266800
URL: http://svnweb.freebsd.org/changeset/base/266800

Log:
  Fixed IPv4-in-IPv6 and IPv6-in-IPv4 IPsec tunnels.
  For IPv6-in-IPv4, you may need to do the following command
  on the tunnel interface if it is configured as IPv4 only:
  ifconfig  inet6 -ifdisabled
  
  Code logic inspired from NetBSD.
  
  PR: kern/169438
  Submitted by: emeric.pou...@netasq.com
  Reviewed by: fabient, ae
  Obtained from: NETASQ

Modified:
  head/sys/netinet6/ip6_forward.c
  head/sys/netinet6/ip6_ipsec.c
  head/sys/netinet6/ip6_ipsec.h
  head/sys/netinet6/ip6_output.c
  head/sys/netinet6/ip6_var.h
  head/sys/netipsec/ipsec6.h
  head/sys/netipsec/ipsec_input.c
  head/sys/netipsec/ipsec_output.c
  head/sys/netipsec/xform_ipip.c

Modified: head/sys/netinet6/ip6_forward.c
==
--- head/sys/netinet6/ip6_forward.c Wed May 28 12:32:07 2014
(r266799)
+++ head/sys/netinet6/ip6_forward.c Wed May 28 12:45:27 2014
(r266800)
@@ -252,7 +252,6 @@ ip6_forward(struct mbuf *m, int srcrt)
 
 {
struct ipsecrequest *isr = NULL;
-   struct ipsec_output_state state;
 
/*
 * when the kernel forwards a packet, it is not proper to apply
@@ -285,18 +284,27 @@ ip6_forward(struct mbuf *m, int srcrt)
 *
 * IPv6 [ESP|AH] IPv6 [extension headers] payload
 */
-   bzero(&state, sizeof(state));
-   state.m = m;
-   state.ro = NULL;/* update at ipsec6_output_tunnel() */
-   state.dst = NULL;   /* update at ipsec6_output_tunnel() */
 
-   error = ipsec6_output_tunnel(&state, sp, 0);
+   /*
+* If we need to encapsulate the packet, do it here
+* ipsec6_proces_packet will send the packet using ip6_output
+*/
+   error = ipsec6_process_packet(m, sp->req);
 
-   m = state.m;
KEY_FREESP(&sp);
 
+   if (error == EJUSTRETURN) {
+   /*
+* We had a SP with a level of 'use' and no SA. We
+* will just continue to process the packet without
+* IPsec processing.
+*/
+   error = 0;
+   goto skip_ipsec;
+   }
+
if (error) {
-   /* mbuf is already reclaimed in ipsec6_output_tunnel. */
+   /* mbuf is already reclaimed in ipsec6_process_packet. */
switch (error) {
case EHOSTUNREACH:
case ENETUNREACH:
@@ -319,7 +327,6 @@ ip6_forward(struct mbuf *m, int srcrt)
m_freem(mcopy);
 #endif
}
-   m_freem(m);
return;
} else {
/*
@@ -331,25 +338,7 @@ ip6_forward(struct mbuf *m, int srcrt)
m = NULL;
goto freecopy;
}
-
-   if ((m != NULL) && (ip6 != mtod(m, struct ip6_hdr *)) ){
-   /*
-* now tunnel mode headers are added.  we are originating
-* packet instead of forwarding the packet.
-*/
-   ip6_output(m, NULL, NULL, IPV6_FORWARDING/*XXX*/, NULL, NULL,
-   NULL);
-   goto freecopy;
-   }
-
-   /* adjust pointer */
-   dst = (struct sockaddr_in6 *)state.dst;
-   rt = state.ro ? state.ro->ro_rt : NULL;
-   if (dst != NULL && rt != NULL)
-   ipsecrt = 1;
 }
-   if (ipsecrt)
-   goto skip_routing;
 skip_ipsec:
 #endif
 again:
@@ -372,9 +361,6 @@ again2:
goto bad;
}
rt = rin6.ro_rt;
-#ifdef IPSEC
-skip_routing:
-#endif
 
/*
 * Source scope check: if a packet can't be delivered to its

Modified: head/sys/netinet6/ip6_ipsec.c
==
--- head/sys/netinet6/ip6_ipsec.c   Wed May 28 12:32:07 2014
(r266799)
+++ head/sys/netinet6/ip6_ipsec.c   Wed May 28 12:45:27 2014
(r266800)
@@ -221,23 +221,22 @@ ip6_ipsec_input(struct mbuf *m, int nxt)
 
 int
 ip6_ipsec_output(struct mbuf **m, struct inpcb *inp, int *flags, int *error,
-struct ifnet **ifp, struct secpolicy **sp)
+struct ifnet **ifp)
 {
 #ifdef IPSEC
+   struct secpolicy *sp = NULL;
struct tdb_ident *tdbi;
struct m_tag *mtag;
/* XXX int s; */
-   if (sp == NULL)
-   return 1;
mtag = m_tag_find(*m, PACKET_TAG_IPSEC_PENDING_TDB, NULL);
if (mtag != NULL) {
tdbi = (struct tdb_ident *)(mtag + 1);
-   *sp = ipsec_getpolicy(tdbi, IPSEC_DIR_OUTBOUND);
-   if (*sp == NULL)
+   sp = ipsec_getpolicy(tdbi, IPSEC_DIR_OUTBOUND);
+   if (sp == NULL)
*error = -EINVAL;   /* force silent drop */
m_tag_delete(*m, mtag);
} else {
-   *sp = ipsec4_checkpolicy(*m, IPSEC_DIR_OUTBOUN

svn commit: r266799 - head/sys/dev/sound/pci

2014-05-28 Thread Marius Strobl
Author: marius
Date: Wed May 28 12:32:07 2014
New Revision: 266799
URL: http://svnweb.freebsd.org/changeset/base/266799

Log:
  Commit the right version of r266793.

Modified:
  head/sys/dev/sound/pci/emu10k1.c

Modified: head/sys/dev/sound/pci/emu10k1.c
==
--- head/sys/dev/sound/pci/emu10k1.cWed May 28 12:27:41 2014
(r266798)
+++ head/sys/dev/sound/pci/emu10k1.cWed May 28 12:32:07 2014
(r266799)
@@ -1378,7 +1378,7 @@ emu_memalloc(struct sc_info *sc, u_int32
ofs = 0;
for (idx = start; idx < start + blksz; idx++) {
mem->bmap[idx >> 3] |= 1 << (idx & 7);
-   tmp = (bus_addr_t)((u_int8_t *)(uintptr_t)blk->buf_addr + ofs);
+   tmp = (uintptr_t)((u_int8_t *)(uintptr_t)blk->buf_addr + ofs);
 #ifdef EMUDEBUG
printf("pte[%d] -> %x phys, %x virt\n", idx, tmp,
((u_int32_t)buf) + ofs);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r266798 - head/usr.sbin/usbdump

2014-05-28 Thread Hans Petter Selasky
Author: hselasky
Date: Wed May 28 12:27:41 2014
New Revision: 266798
URL: http://svnweb.freebsd.org/changeset/base/266798

Log:
  Fix for big endian architectures. The "up_address" field is 8-bit and
  does not need byte swapping.
  
  MFC after:1 week

Modified:
  head/usr.sbin/usbdump/usbdump.c

Modified: head/usr.sbin/usbdump/usbdump.c
==
--- head/usr.sbin/usbdump/usbdump.c Wed May 28 11:30:37 2014
(r266797)
+++ head/usr.sbin/usbdump/usbdump.c Wed May 28 12:27:41 2014
(r266798)
@@ -473,7 +473,7 @@ print_apacket(const struct header_32 *hd
 */
up->up_totlen = le32toh(up->up_totlen);
up->up_busunit = le32toh(up->up_busunit);
-   up->up_address = le32toh(up->up_address);
+   up->up_address = up->up_address;
up->up_flags = le32toh(up->up_flags);
up->up_status = le32toh(up->up_status);
up->up_error = le32toh(up->up_error);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r266553 - head/release/scripts

2014-05-28 Thread Tijl Coosemans
On Tue, 27 May 2014 14:31:44 -0600 Warner Losh wrote:
> On May 27, 2014, at 1:40 PM, Tijl Coosemans  wrote:
>> On Tue, 27 May 2014 07:18:06 -0600 Warner Losh wrote:
>>> On May 27, 2014, at 1:36 AM, Tijl Coosemans  wrote:
 On Mon, 26 May 2014 16:31:21 -0600 Warner Losh wrote:
>>> So I?m still waiting for a use case that requires the new names. One has
>>> not been articulated, and I don?t think one actually exists.
>> 
>> Imagine you've built a system with MACHINE_ARCH amd64 and one with
>> MACHINE_ARCH mips64.  Now you want to populate these systems with a list
>> of packages for which you wrote a script.  These systems each support 2
>> ABIs: a native 64-bit one (amd64 and mips64) and a native 32-bit one (x32
>> and mipsn32).  Both are native in the sense that they make full use of the
>> instruction set.  This is not like i386 on amd64 or mips o32 on mips64
>> because those are more like compat shims that operate under special
>> (crippled) cpu modes that nobody uses unless they're stuck with old code.
>> Both our ABIs on the other hand are native and equally valid and which one
>> to use for a particular package depends entirely on the use case.  If your
>> use case requires more than 4G of address space you'll have to use the
>> 64-bit package, otherwise you can use the 32-bit package which, depending
>> on how pointer heavy the code is, may give a performance benefit.  You
>> make this choice for each of the packages in your list and add that
>> information to your script.
> 
> Long hypothetical, but so what? In such a case, you’d pick one of two
> different MACHINE_ARCH values depending on the package. This this is a
> fairly atypical use case, it would not be unreasonable for the person
> wanting to do this to know the proper companion ABI. In both cases, you
> have the choice of two other values to use. Which one you use will depend
> on a variety of factors, and what might be right for one application may
> be wrong for others.
> 
> And in both cases, there’s actually two choices: for amd64, you’d have
> i386 and x32. Both of these are fine choices, and it would depend on the
> workload which one is better (i386 has better toolchain support and
> maturity, x32 offers some interesting theoretical wins, but doesn’t have
> the same maturity). Same with mips64, you’d have two choices as well. In
> both cases, you can’t just take uname/MACHINE_ARCH and slap :32 on the end.

As far as I can see nobody uses i386 on amd64 except in cases where you
know you're dealing with i386 like an i386 jail, or you need to run an old
i386 binary that you're stuck with, or with compat shims like Wine.  The
choice of i386 is not comparable with the generic choice between ILP32 or
LP64 on a 64-bit instruction set, which is why I'm ok with changing the
"x86" in the pkg scheme to either "i386" or "amd64" like you are proposing.
If pkg would keep using instruction set families like "x86" or "mips" then
you could distinguish between old 32-bit, new 32-bit and new 64-bit using
3 generic suffixes to avoid lookup tables.  The pattern of an old 32-bit
instruction set that got extended to 64-bit on which you can define a new
32-bit ABI is common to many instruction set families, but I'm ok with
old 32-bit and new 64-bit having separate MACHINE_ARCH values.
 
>> Now let's work with Nathan's patch which uses the following string to
>> identify the pkg repository to fetch packages from:
>> `uname -s`:`uname -r | cut -f 1 -d .`:`uname -p`
>> 
>> On our two systems that would be FreeBSD:11:amd64 and FreeBSD:11:mips64.
>> Now if your script has to install the 32-bit version of a package how
>> can it go from those two strings to FreeBSD:11:x32 or FreeBSD:11:mipsn32
>> without a lookup table?
>
> You couldn’t. Which is the whole reason I want to have them have a
> standard name so you don’t need the lookup table for the common case.
> This is an “off in the weeds” case, and optimizing for it doesn’t make
> sense. Especially because in each case, you have two different 32-bit
> ABIs to choose from. You’d have to have some kind of table in either
> case. Also, the proper name for n32, in your current system, is
> mips:32:n32, which (a) is wrong and (b) isn’t regular.

Well, it may not make sense to you and be off in the weeds, but it does
to me.  Very few processes actually need more than 4G of virtual address
space.  I cannot immediately find anything in /bin or /usr/bin for
instance (maybe clang when compiling a very large C++ file?).

I'm not sure where you're getting mips:32:n32 from.  We're talking in the
context of Nathan's patch here.

>>  I say, you can more easily indicate whether you
>> want the 32-bit or 64-bit package by appending :32 or :64 to the original
>> strings, so FreeBSD:11:amd64:32 and FreeBSD:11:mips64:32.
> 
> Except there’s no such thing as mips64:32 in the current system. There’s
> two different ABIs that could mean. It could be o32 or n32, with the same
> sort of trade offs. There’d need to be a person in th

Re: svn commit: r266757 - in head/sys: conf dev/cxgbe dev/cxgbe/common modules/cxgbe/if_cxgbe

2014-05-28 Thread Bjoern A. Zeeb

On 27 May 2014, at 18:18 , Navdeep Parhar  wrote:

> Author: np
> Date: Tue May 27 18:18:41 2014
> New Revision: 266757
> URL: http://svnweb.freebsd.org/changeset/base/266757
> 
> Log:
>  cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards.
>  Netmap gets its own hardware-assisted virtual interface and won't take
>  over or disrupt the "normal" interface in any way.  You can use both
>  simultaneously.
> 
>  For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl interface
>  (note the 'n' prefix) in the hardware to accompany each cxl
>  interface.  These two ifnet's per port share the same wire but really
>  are separate interfaces in the hardware and software.  Each gets its own
>  L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc.  You
>  should run netmap on the 'n' interfaces only, that's what they are for.
> 
>  With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port
>  of a T580 card.  2 port tx is at ~56Mpps total (28M + 28M) as of now.
>  Single port receive is at 33Mpps but this is very much a work in
>  progress.  I expect it to be closer to 40Mpps once done.  In any case
>  the current effort can already saturate multiple 10G ports of a T5 card
>  at the smallest legal packet size.  T4 gear is totally untested.
> 
>  trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef
>  881.952141 main [1621] interface is ncxl0
>  881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0
>  881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0
>  881.962540 main [1804] mapped 334980KB at 0x801dff000
>  Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus.
>  10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef)
>  881.962562 main [1882] Sending 512 packets every  0.0 s
>  881.962563 main [1884] Wait 2 secs for phy reset
>  884.088516 main [1886] Ready...
>  884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1
>  884.088607 sender_body [996] start
>  884.093246 sender_body [1064] drop copy
>  885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec)
>  886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec)
>  887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec)
>  888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec)
>  889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec)
>  890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec)
>  891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec)
>  892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec)
>  893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec)
>  894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec)
>  895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec)
>  896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec)
>  ...
> 
>  Relnotes:Yes
>  Sponsored by:Chelsio Communications.


Really nice :-)   Thanks a lot for getting it into the tree.


— 
Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983

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


svn commit: r266793 - head/sys/dev/sound/pci

2014-05-28 Thread Marius Strobl
Author: marius
Date: Wed May 28 09:01:35 2014
New Revision: 266793
URL: http://svnweb.freebsd.org/changeset/base/266793

Log:
  - Fix compilation with PAE support enabled by improving the casting of
physical addresses.
  - Nuke the unused softc of emujoy(4).
  - Use DEVMETHOD_END.
  - Use NULL instead of 0 for pointers.
  
  MFC after:3 days
  Sponsored by: Bally Wulff Games & Entertainment GmbH

Modified:
  head/sys/dev/sound/pci/emu10k1.c

Modified: head/sys/dev/sound/pci/emu10k1.c
==
--- head/sys/dev/sound/pci/emu10k1.cWed May 28 08:59:23 2014
(r266792)
+++ head/sys/dev/sound/pci/emu10k1.cWed May 28 09:01:35 2014
(r266793)
@@ -1378,7 +1378,7 @@ emu_memalloc(struct sc_info *sc, u_int32
ofs = 0;
for (idx = start; idx < start + blksz; idx++) {
mem->bmap[idx >> 3] |= 1 << (idx & 7);
-   tmp = (u_int32_t)(u_long)((u_int8_t *)blk->buf_addr + ofs);
+   tmp = (bus_addr_t)((u_int8_t *)(uintptr_t)blk->buf_addr + ofs);
 #ifdef EMUDEBUG
printf("pte[%d] -> %x phys, %x virt\n", idx, tmp,
((u_int32_t)buf) + ofs);
@@ -2182,7 +2182,7 @@ static device_method_t emu_methods[] = {
DEVMETHOD(device_attach,emu_pci_attach),
DEVMETHOD(device_detach,emu_pci_detach),
 
-   { 0, 0 }
+   DEVMETHOD_END
 };
 
 static driver_t emu_driver = {
@@ -2191,7 +2191,7 @@ static driver_t emu_driver = {
PCM_SOFTC_SIZE,
 };
 
-DRIVER_MODULE(snd_emu10k1, pci, emu_driver, pcm_devclass, 0, 0);
+DRIVER_MODULE(snd_emu10k1, pci, emu_driver, pcm_devclass, NULL, NULL);
 MODULE_DEPEND(snd_emu10k1, sound, SOUND_MINVER, SOUND_PREFVER, SOUND_MAXVER);
 MODULE_VERSION(snd_emu10k1, 1);
 MODULE_DEPEND(snd_emu10k1, midi, 1, 1, 1);
@@ -2220,12 +2220,14 @@ emujoy_pci_probe(device_t dev)
 static int
 emujoy_pci_attach(device_t dev)
 {
+
return 0;
 }
 
 static int
 emujoy_pci_detach(device_t dev)
 {
+
return 0;
 }
 
@@ -2234,16 +2236,15 @@ static device_method_t emujoy_methods[] 
DEVMETHOD(device_attach,emujoy_pci_attach),
DEVMETHOD(device_detach,emujoy_pci_detach),
 
-   { 0, 0 }
+   DEVMETHOD_END
 };
 
 static driver_t emujoy_driver = {
"emujoy",
emujoy_methods,
-   8,
+   1   /* no softc */
 };
 
 static devclass_t emujoy_devclass;
 
-DRIVER_MODULE(emujoy, pci, emujoy_driver, emujoy_devclass, 0, 0);
-
+DRIVER_MODULE(emujoy, pci, emujoy_driver, emujoy_devclass, NULL, NULL);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r266792 - head/sys/dev/drm2/radeon

2014-05-28 Thread Marius Strobl
Author: marius
Date: Wed May 28 08:59:23 2014
New Revision: 266792
URL: http://svnweb.freebsd.org/changeset/base/266792

Log:
  Fix DMA handling in radeon_dummy_page_init():
  - Based on actual usage and on what Linux does, dummy_page.addr should
contain the physical bus address of the dummy page rather than its
virtual one. As a side-effect, correcting this bug fixes compilation
with PAE support enabled by getting rid of an inappropriate cast.
  - Also based on actual usage of dummy_page.addr, theoretically Radeon
devices could do a maximum of 44-bit DMA. In reality, though, it is
more likely that they only support 32-bit DMA, at least that is what
radeon_gart_table_ram_alloc() sets up for, too. However, passing ~0
to drm_pci_alloc() as maxaddr parameter translates to 64-bit DMA on
amd64/64-bit machines. Thus, use BUS_SPACE_MAXSIZE_32BIT instead,
which the existing 32-bit DMA limits within the drm2 code spelled as
0x should also be changed to.
  
  Reviewed by:  dumbbell
  MFC after:  1 week
  Sponsored by:   Bally Wulff Games & Entertainment GmbH

Modified:
  head/sys/dev/drm2/radeon/radeon_device.c

Modified: head/sys/dev/drm2/radeon/radeon_device.c
==
--- head/sys/dev/drm2/radeon/radeon_device.cWed May 28 07:35:48 2014
(r266791)
+++ head/sys/dev/drm2/radeon/radeon_device.cWed May 28 08:59:23 2014
(r266792)
@@ -548,10 +548,10 @@ int radeon_dummy_page_init(struct radeon
if (rdev->dummy_page.dmah)
return 0;
rdev->dummy_page.dmah = drm_pci_alloc(rdev->ddev,
-   PAGE_SIZE, PAGE_SIZE, ~0);
+   PAGE_SIZE, PAGE_SIZE, BUS_SPACE_MAXSIZE_32BIT);
if (rdev->dummy_page.dmah == NULL)
return -ENOMEM;
-   rdev->dummy_page.addr = (dma_addr_t)rdev->dummy_page.dmah->vaddr;
+   rdev->dummy_page.addr = rdev->dummy_page.dmah->busaddr;
return 0;
 }
 
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"