Re: svn commit: r266553 - head/release/scripts
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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"
