svn commit: r266732 - head/share/man/man4
Author: kevlo Date: Tue May 27 06:35:36 2014 New Revision: 266732 URL: http://svnweb.freebsd.org/changeset/base/266732 Log: Xr bktr.4 Modified: head/share/man/man4/iicbus.4 Modified: head/share/man/man4/iicbus.4 == --- head/share/man/man4/iicbus.4Tue May 27 04:59:53 2014 (r266731) +++ head/share/man/man4/iicbus.4Tue May 27 06:35:36 2014 (r266732) @@ -104,6 +104,7 @@ Some I2C interfaces are available: .It Sy bktr Ta "Brooktree848 video chipset, hardware and software master-only interface" .El .Sh SEE ALSO +.Xr bktr 4 , .Xr iicbb 4 , .Xr lpbb 4 , .Xr pcf 4 ___ 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: r266731 - in head: contrib/subversion contrib/subversion/subversion/include contrib/subversion/subversion/include/private contrib/subversion/subversion/libsvn_client contrib/subversion/...
Author: peter Date: Tue May 27 04:59:53 2014 New Revision: 266731 URL: http://svnweb.freebsd.org/changeset/base/266731 Log: Merge svn-1.8.8 -> 1.8.9 Modified: head/contrib/subversion/CHANGES head/contrib/subversion/NOTICE head/contrib/subversion/build-outputs.mk head/contrib/subversion/configure head/contrib/subversion/configure.ac head/contrib/subversion/subversion/include/private/svn_cache.h head/contrib/subversion/subversion/include/private/svn_dep_compat.h head/contrib/subversion/subversion/include/svn_version.h head/contrib/subversion/subversion/libsvn_client/commit_util.c head/contrib/subversion/subversion/libsvn_client/export.c head/contrib/subversion/subversion/libsvn_client/merge.c head/contrib/subversion/subversion/libsvn_client/prop_commands.c head/contrib/subversion/subversion/libsvn_delta/svndiff.c head/contrib/subversion/subversion/libsvn_fs_fs/fs.c head/contrib/subversion/subversion/libsvn_fs_fs/fs.h head/contrib/subversion/subversion/libsvn_fs_fs/rep-cache-db.h head/contrib/subversion/subversion/libsvn_ra_serf/getlocks.c head/contrib/subversion/subversion/libsvn_ra_serf/inherited_props.c head/contrib/subversion/subversion/libsvn_ra_serf/locks.c head/contrib/subversion/subversion/libsvn_ra_serf/log.c head/contrib/subversion/subversion/libsvn_ra_serf/update.c head/contrib/subversion/subversion/libsvn_ra_svn/protocol head/contrib/subversion/subversion/libsvn_repos/dump.c head/contrib/subversion/subversion/libsvn_repos/fs-wrap.c head/contrib/subversion/subversion/libsvn_subr/cache-memcache.c head/contrib/subversion/subversion/libsvn_subr/config_file.c head/contrib/subversion/subversion/libsvn_subr/internal_statements.h head/contrib/subversion/subversion/libsvn_subr/io.c head/contrib/subversion/subversion/libsvn_subr/prompt.c head/contrib/subversion/subversion/libsvn_subr/sysinfo.c head/contrib/subversion/subversion/libsvn_subr/version.c head/contrib/subversion/subversion/libsvn_wc/status.c head/contrib/subversion/subversion/libsvn_wc/wc-checks.h head/contrib/subversion/subversion/libsvn_wc/wc-metadata.h head/contrib/subversion/subversion/libsvn_wc/wc-metadata.sql head/contrib/subversion/subversion/libsvn_wc/wc-queries.h head/contrib/subversion/subversion/libsvn_wc/wc-queries.sql head/contrib/subversion/subversion/libsvn_wc/wc_db.c head/contrib/subversion/subversion/libsvn_wc/wc_db.h head/contrib/subversion/subversion/libsvn_wc/wc_db_wcroot.c head/contrib/subversion/subversion/svn/conflict-callbacks.c head/contrib/subversion/subversion/svndumpfilter/svndumpfilter.c head/contrib/subversion/subversion/svnrdump/util.c head/contrib/subversion/subversion/svnserve/serve.c head/usr.bin/svn/svn_private_config.h Directory Properties: head/contrib/subversion/ (props changed) Modified: head/contrib/subversion/CHANGES == --- head/contrib/subversion/CHANGES Tue May 27 04:56:06 2014 (r266730) +++ head/contrib/subversion/CHANGES Tue May 27 04:59:53 2014 (r266731) @@ -1,3 +1,70 @@ +Version 1.8.9 +(07 May 2014, from /branches/1.8.x) +http://svn.apache.org/repos/asf/subversion/tags/1.8.9 + + User-visible changes: + - Client-side bugfixes: +* log: use proper peg revision over DAV (r1568872) +* upgrade: allow upgrading from 1.7 with exclusive locks (r1572102 et al) +* proplist: resolve inconsitent inherited property results (r1575270 et al) +* increase minimal timestamp sleep from 1ms to 10ms (r1581305 et al) +* merge: automatic merge confused by subtree merge (issue #4481) +* propget: report proper error on invalid revision for url (r1586255) +* commit: fix an assertion when committing a deleted descendant + (r1571747, r1571787, r1571795) +* merge: resolve segfault when '--force' merges a directory delete + (r1577812, r1577813, r1579429) +* resolve: prevent interactive conflict resolution when nothing has been + done to resolve the conflict (r1577294) +* update: fix locks lost from wc with pre-1.6.17 servers (issue #4412) +* merge: honor the 'preserved-conflict-file-exts' setting (r1577151) +* list: fix '--verbose' against older servers (r159) +* unlock: fix ability to remove locks with timeouts (r1579588) +* copy: fix 'svn copy URL WC' on relocated working copies + (r1580626, r1580650) +* export: allow file externals to be exported (issue #4427) +* move: fix working copy db inconsistency in cert scenarios (issue #4437) +* commit: fix an issue where mixed revision copy with non copy descendants + that shadow a not present node couldn't be committed (r1518942 et al) +* delete: properly remove move_to info when the node in its original + location is removed (r1538812 et al) +* status; fix an issue where output would vary based on if the target + was the node itself or its parent (r1544597 et al) + + - Serv
svn commit: r266728 - in head/contrib/serf: . auth
Author: peter
Date: Tue May 27 04:52:32 2014
New Revision: 266728
URL: http://svnweb.freebsd.org/changeset/base/266728
Log:
Update serf 1.3.4 -> 1.3.5
Modified:
head/contrib/serf/CHANGES
head/contrib/serf/auth/auth.c
head/contrib/serf/auth/auth_spnego.c
head/contrib/serf/outgoing.c
head/contrib/serf/serf.h
head/contrib/serf/ssltunnel.c
Directory Properties:
head/contrib/serf/ (props changed)
Modified: head/contrib/serf/CHANGES
==
--- head/contrib/serf/CHANGES Tue May 27 04:39:23 2014(r266727)
+++ head/contrib/serf/CHANGES Tue May 27 04:52:32 2014(r266728)
@@ -1,4 +1,11 @@
-Serf 1.3.4 [2014-02-08, from /tags/1.3.4, r]
+Serf 1.3.5 [2014-04-27, from /tags/1.3.5, r]
+ Fix issue #125: no reverse lookup during Negotiate authentication for
proxies.
+ Fix a crash caused by incorrect reuse of the ssltunnel CONNECT request
(r2316)
+ Cancel request if response parsing failed + authn callback set (r2319)
+ Update the expired certificates in the test suite.
+
+
+Serf 1.3.4 [2014-02-08, from /tags/1.3.4, r2310]
Fix issue #119: Endless loop during ssl tunnel setup with Negotiate authn
Fix issue #123: Can't setup ssl tunnel which sends Connection close header
Fix a race condition when initializing OpenSSL from multiple threads (r2263)
Modified: head/contrib/serf/auth/auth.c
==
--- head/contrib/serf/auth/auth.c Tue May 27 04:39:23 2014
(r266727)
+++ head/contrib/serf/auth/auth.c Tue May 27 04:52:32 2014
(r266728)
@@ -408,6 +408,7 @@ apr_status_t serf__handle_auth_response(
consider the reponse body as invalid and discard it. */
status = discard_body(response);
*consumed_response = 1;
+
if (!APR_STATUS_IS_EOF(status)) {
return status;
}
Modified: head/contrib/serf/auth/auth_spnego.c
==
--- head/contrib/serf/auth/auth_spnego.cTue May 27 04:39:23 2014
(r266727)
+++ head/contrib/serf/auth/auth_spnego.cTue May 27 04:52:32 2014
(r266728)
@@ -335,8 +335,7 @@ do_auth(peer_t peer,
&tmp, &tmp_len,
gss_info);
} else {
-char *proxy_host;
-apr_getnameinfo(&proxy_host, conn->ctx->proxy_address, 0);
+char *proxy_host = conn->ctx->proxy_address->hostname;
status = gss_api_get_credentials(conn,
token, token_len, proxy_host,
&tmp, &tmp_len,
Modified: head/contrib/serf/outgoing.c
==
--- head/contrib/serf/outgoing.cTue May 27 04:39:23 2014
(r266727)
+++ head/contrib/serf/outgoing.cTue May 27 04:52:32 2014
(r266728)
@@ -916,21 +916,22 @@ static apr_status_t handle_response(serf
* themselves by not registering credential callbacks.
*/
if (request->conn->ctx->cred_cb) {
- status = serf__handle_auth_response(&consumed_response,
- request,
- request->resp_bkt,
- request->handler_baton,
- pool);
-
- /* If there was an error reading the response (maybe there wasn't
- enough data available), don't bother passing the response to the
- application.
-
- If the authentication was tried, but failed, pass the response
- to the application, maybe it can do better. */
- if (status) {
- return status;
- }
+status = serf__handle_auth_response(&consumed_response,
+request,
+request->resp_bkt,
+request->handler_baton,
+pool);
+
+if (SERF_BUCKET_READ_ERROR(status)) {
+/* Report the request as 'died'/'cancelled' to the application */
+(void)(*request->handler)(request,
+ NULL,
+ request->handler_baton,
+ pool);
+}
+
+if (status)
+return status;
}
if (!consumed_response) {
Modified: head/contrib/serf/serf.h
==
--- head/contrib/serf/serf.hTue May 27 04:39:23 2014(r266727)
+++ head/contrib/serf/serf.hTue May 27 04:52:32 2014(r266728)
@@ -1062,7 +1062,7 @@ void serf_debug__bucket_alloc_check(
/* Version info */
#define SERF_MAJOR_
svn commit: r266725 - head/lib/libc/string
Author: allanjude (doc committer) Date: Tue May 27 04:30:56 2014 New Revision: 266725 URL: http://svnweb.freebsd.org/changeset/base/266725 Log: Emphasis on 'do not' and 'complement' in the strcspn(3) Replace literal parentheses with .Po/.Pc Approved by: wblock (mentor) Modified: head/lib/libc/string/strspn.3 Modified: head/lib/libc/string/strspn.3 == --- head/lib/libc/string/strspn.3 Tue May 27 04:26:22 2014 (r266724) +++ head/lib/libc/string/strspn.3 Tue May 27 04:30:56 2014 (r266725) @@ -71,13 +71,14 @@ spans the initial part of the null-termi .Fa s as long as the characters from .Fa s -do not occur in the null-terminated string +.Sy do not +occur in the null-terminated string .Fa charset -(it -spans the -.Em complement +.Po it spans the +.Sy complement of -.Fa charset ) . +.Fa charset +.Pc . In other words, it computes the string array index of the first character of .Fa s ___ 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: r266724 - in head: sys/amd64/include sys/amd64/vmm usr.sbin/bhyve
Author: neel
Date: Tue May 27 04:26:22 2014
New Revision: 266724
URL: http://svnweb.freebsd.org/changeset/base/266724
Log:
Add segment protection and limits violation checks in vie_calculate_gla()
for 32-bit x86 guests.
Tested using ins/outs executed in a FreeBSD/i386 guest.
Modified:
head/sys/amd64/include/vmm.h
head/sys/amd64/include/vmm_instruction_emul.h
head/sys/amd64/vmm/vmm_instruction_emul.c
head/sys/amd64/vmm/vmm_ioport.c
head/usr.sbin/bhyve/inout.c
Modified: head/sys/amd64/include/vmm.h
==
--- head/sys/amd64/include/vmm.hTue May 27 02:00:43 2014
(r266723)
+++ head/sys/amd64/include/vmm.hTue May 27 04:26:22 2014
(r266724)
@@ -321,6 +321,11 @@ struct seg_desc {
uint32_tlimit;
uint32_taccess;
};
+#defineSEG_DESC_TYPE(desc) ((desc)->access & 0x001f)
+#defineSEG_DESC_PRESENT(desc) ((desc)->access & 0x0080)
+#defineSEG_DESC_DEF32(desc)((desc)->access & 0x4000)
+#defineSEG_DESC_GRANULARITY(desc) ((desc)->access & 0x8000)
+#defineSEG_DESC_UNUSABLE(desc) ((desc)->access & 0x1)
enum vm_cpu_mode {
CPU_MODE_COMPATIBILITY, /* IA-32E mode (CS.L = 0) */
Modified: head/sys/amd64/include/vmm_instruction_emul.h
==
--- head/sys/amd64/include/vmm_instruction_emul.h Tue May 27 02:00:43
2014(r266723)
+++ head/sys/amd64/include/vmm_instruction_emul.h Tue May 27 04:26:22
2014(r266724)
@@ -29,6 +29,8 @@
#ifndef_VMM_INSTRUCTION_EMUL_H_
#define_VMM_INSTRUCTION_EMUL_H_
+#include
+
/*
* Callback functions to read and write memory regions.
*/
@@ -67,8 +69,9 @@ int vie_canonical_check(enum vm_cpu_mode
uint64_t vie_size2mask(int size);
-int vie_calculate_gla(enum vm_cpu_mode cpu_mode, int addrsize,
-enum vm_reg_name seg, struct seg_desc *desc, uint64_t off, uint64_t *gla);
+int vie_calculate_gla(enum vm_cpu_mode cpu_mode, enum vm_reg_name seg,
+struct seg_desc *desc, uint64_t off, int length, int addrsize, int prot,
+uint64_t *gla);
#ifdef _KERNEL
/*
Modified: head/sys/amd64/vmm/vmm_instruction_emul.c
==
--- head/sys/amd64/vmm/vmm_instruction_emul.c Tue May 27 02:00:43 2014
(r266723)
+++ head/sys/amd64/vmm/vmm_instruction_emul.c Tue May 27 04:26:22 2014
(r266724)
@@ -608,16 +608,92 @@ vie_size2mask(int size)
}
int
-vie_calculate_gla(enum vm_cpu_mode cpu_mode, int addrsize, enum vm_reg_name
seg,
-struct seg_desc *desc, uint64_t offset, uint64_t *gla)
+vie_calculate_gla(enum vm_cpu_mode cpu_mode, enum vm_reg_name seg,
+struct seg_desc *desc, uint64_t offset, int length, int addrsize,
+int prot, uint64_t *gla)
{
- uint64_t segbase;
- int glasize;
+ uint64_t low_limit, high_limit, segbase;
+ int glasize, type;
KASSERT(seg >= VM_REG_GUEST_ES && seg <= VM_REG_GUEST_GS,
("%s: invalid segment %d", __func__, seg));
+ KASSERT(length == 1 || length == 2 || length == 4 || length == 8,
+ ("%s: invalid operand size %d", __func__, length));
+ KASSERT((prot & ~(PROT_READ | PROT_WRITE)) == 0,
+ ("%s: invalid prot %#x", __func__, prot));
- glasize = (cpu_mode == CPU_MODE_64BIT) ? 8 : 4;
+ if (cpu_mode == CPU_MODE_64BIT) {
+ KASSERT(addrsize == 4 || addrsize == 8, ("%s: invalid address "
+ "size %d for cpu_mode %d", __func__, addrsize, cpu_mode));
+ glasize = 8;
+ } else {
+ KASSERT(addrsize == 2 || addrsize == 4, ("%s: invalid address "
+ "size %d for cpu mode %d", __func__, addrsize, cpu_mode));
+ glasize = 4;
+ /*
+* If the segment selector is loaded with a NULL selector
+* then the descriptor is unusable and attempting to use
+* it results in a #GP(0).
+*/
+ if (SEG_DESC_UNUSABLE(desc))
+ return (-1);
+
+ /*
+* The processor generates a #NP exception when a segment
+* register is loaded with a selector that points to a
+* descriptor that is not present. If this was the case then
+* it would have been checked before the VM-exit.
+*/
+ KASSERT(SEG_DESC_PRESENT(desc), ("segment %d not present: %#x",
+ seg, desc->access));
+
+ /*
+* The descriptor type must indicate a code/data segment.
+*/
+ type = SEG_DESC_TYPE(desc);
+ KASSERT(type >= 16 && type <= 31, ("segment %d has invalid "
+ "descriptor type %#
svn commit: r266723 - head/sys/sys
Author: markj Date: Tue May 27 02:00:43 2014 New Revision: 266723 URL: http://svnweb.freebsd.org/changeset/base/266723 Log: Garbage-collect a couple of unused identifiers. MFC after:3 days Modified: head/sys/sys/dtrace_bsd.h Modified: head/sys/sys/dtrace_bsd.h == --- head/sys/sys/dtrace_bsd.h Tue May 27 01:58:05 2014(r266722) +++ head/sys/sys/dtrace_bsd.h Tue May 27 02:00:43 2014(r266723) @@ -60,11 +60,9 @@ int dtrace_trap(struct trapframe *, u_in extern dtrace_trap_func_t dtrace_trap_func; /* Used by the machine dependent trap() code. */ -typedefint (*dtrace_invop_func_t)(uintptr_t, uintptr_t *, uintptr_t); typedef void (*dtrace_doubletrap_func_t)(void); /* Global variables in trap.c */ -extern dtrace_invop_func_t dtrace_invop_func; 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"
Re: svn commit: r264912 - in head: share/man/man4 sys/conf sys/contrib/dev/urtwn sys/dev/usb sys/dev/usb/wlan sys/modules/usb/urtwnfw sys/modules/usb/urtwnfw/urtwnrtl8188eu
On Tue, May 27, 2014 at 04:03:05AM +0800, Buganini wrote: > > I think this accidentally removed > URTWN_DEV(ASUS, USBN10NANO), Fixed in r266721. Thanks for pointing that out. ___ 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: r266721 - head/sys/dev/usb/wlan
Author: kevlo Date: Tue May 27 01:47:23 2014 New Revision: 266721 URL: http://svnweb.freebsd.org/changeset/base/266721 Log: Remove r264317 by accident. Spotted by: Kuan-Chung Chiu Modified: head/sys/dev/usb/wlan/if_urtwn.c Modified: head/sys/dev/usb/wlan/if_urtwn.c == --- head/sys/dev/usb/wlan/if_urtwn.cMon May 26 23:47:57 2014 (r266720) +++ head/sys/dev/usb/wlan/if_urtwn.cTue May 27 01:47:23 2014 (r266721) @@ -96,6 +96,7 @@ static const STRUCT_USB_HOST_ID urtwn_de URTWN_DEV(ABOCOM, RTL8188CU_2), URTWN_DEV(ABOCOM, RTL8192CU), URTWN_DEV(ASUS, RTL8192CU), + URTWN_DEV(ASUS, USBN10NANO), URTWN_DEV(AZUREWAVE,RTL8188CE_1), URTWN_DEV(AZUREWAVE,RTL8188CE_2), URTWN_DEV(AZUREWAVE,RTL8188CU), ___ 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/26/14 16:02, dte...@freebsd.org wrote: -Original Message- From: owner-src-committ...@freebsd.org [mailto:owner-src- committ...@freebsd.org] On Behalf Of Nathan Whitehorn Sent: Monday, May 26, 2014 7:40 AM To: Tijl Coosemans; Warner Losh Cc: Ian Lepore; Baptiste Daroussin; svn-src-head@freebsd.org; Glen Barber; svn-src-...@freebsd.org; src-committ...@freebsd.org Subject: Re: svn commit: r266553 - head/release/scripts On 05/26/14 02:35, Tijl Coosemans wrote: On Sat, 24 May 2014 19:00:18 -0600 Warner Losh wrote: On May 24, 2014, at 5:53 PM, Warner Losh wrote: On May 24, 2014, at 5:13 PM, Tijl Coosemans wrote: There isn't necessarily any chroot environment. There's one kernel, two equally valid ABIs (ILP32 and LP64) and any binary like uname might use either of them. If uname -p returns a different result depending on which of these two ABIs it was compiled for that could be a problem for any script that uses it. Well, it depends on what you want to do with the script, eh? If you want to know the ABI of the native binary uname, that?s one thing. But if you want to know the supported ABIs, you are doing it wrong by using uname. You should be using sysctl kern.supported_abi. That will tell you all the ABIs that you can install packages for on this machine, which is what you really want to know. So I?m having trouble connecting the dots between this and what you are saying here. I still am absolutely flabbergasted why the MACHINE_ARCH names aren?t necessary and sufficient for packaging. I?ve yet to see any coherent reason to not use them. Why do I care that they match? Good question. When I was doing FreeNAS, I looked at integrating pkgng into nanobsd. At the time this was quite difficult because every single architecture name was different between pkgng and MACHINE_ARCH. This would mean I?d have to drag around a huge table to know how to translate one to the other (there was no simple regex either, and things like mipsn32 wouldn?t have fit into the scheme at the time). I would very much like us to see us keep these names in sync and avoid large translation tables that are difficult to maintain. Now, do you need to get it from uname -p? No. If you want to parse elf files to get it, that?s fine, so long as the names map directly to the MACHINE_ARCH names that we?ve been using for years. They completely describe the universe of supported platforms. Are they perfect? No, around the edge there may be an odd-ball that?s possible to build, but is unsupported and likely doesn?t work at all. Have we learned from these mistakes? Yes. Anything that?s actively supported has a proper name. This name is needed, btw, so that any machine can self-host, a nice feature of the /usr/src system. ABI consists of the following elements: - OS - OS ABI version (major version number in FreeBSD) - instruction set - programming model (ILP32 or LP64) - byte order (little/big endian) These are almost orthogonal dimensions in the sense that almost any combination is possible. (A combination that isn't possible is a 32-bit instruction set with LP64.) What you are asking for now is to combine two dimensions into one and combination in this case means multiplication so if you have 3 instruction sets and 2 programming models, the combined dimension needs 6 different values. You need to make the case for why you think this is a good idea. For the past 20 years we got away with this because on every installation of FreeBSD we only used one programming model at a time. This is still the case for byte order of course. What I'm saying is to keep the option open for installations with multiple programming models, where most binaries could use ILP32 and only the ones that actually need a 64-bit address space use LP64. You query the instruction set using uname and the programming models using getconf. I suppose you could replace the "x86" in the pkg scheme with i386/amd64, but then you'd still be talking about i386:32, amd64:32 and amd64:64 instead of x86:32, x86:x32 and x86:64. No. We support multiple "models" now and have for ten years. That's what MACHINE_ARCH is for: it defines the choice of the last three things you list above. Specifically, a shared value of MACHINE_ARCH guarantees and OS version guarantees, in FreeBSD-land, complete binary compatibility of executables. Kernels support multiple ones, in general (e.g. i386 binaries on amd64, powerpc binaries on powerpc64). They may support more in the future (x32 on amd64, potentially even cross-endian binaries). We have a nice flexible scheme in FreeBSD for supporting this. If you want to find out the list of the things the installed kernel can run, check the kern.supported_archs sysctl. Simple. These strings are just as expressive as the ones in pkg. They are the standard. They're what external build systems test against, what the src, doc, and ports trees use to define what to do universally. It's what users and code expect. The wheel we'v
RE: svn commit: r266553 - head/release/scripts
> -Original Message- > From: owner-src-committ...@freebsd.org [mailto:owner-src- > committ...@freebsd.org] On Behalf Of Nathan Whitehorn > Sent: Monday, May 26, 2014 7:40 AM > To: Tijl Coosemans; Warner Losh > Cc: Ian Lepore; Baptiste Daroussin; svn-src-head@freebsd.org; Glen Barber; > svn-src-...@freebsd.org; src-committ...@freebsd.org > Subject: Re: svn commit: r266553 - head/release/scripts > > On 05/26/14 02:35, Tijl Coosemans wrote: > > On Sat, 24 May 2014 19:00:18 -0600 Warner Losh wrote: > >> On May 24, 2014, at 5:53 PM, Warner Losh wrote: > >>> On May 24, 2014, at 5:13 PM, Tijl Coosemans wrote: > There isn't necessarily any chroot environment. There's one > kernel, two equally valid ABIs (ILP32 and LP64) and any binary like > uname might use either of them. If uname -p returns a different > result depending on which of these two ABIs it was compiled for > that could be a problem for any script that uses it. > >>> Well, it depends on what you want to do with the script, eh? If you > >>> want to know the ABI of the native binary uname, that?s one thing. > >>> But if you want to know the supported ABIs, you are doing it wrong by > using uname. > >>> You should be using sysctl kern.supported_abi. That will tell you > >>> all the ABIs that you can install packages for on this machine, > >>> which is what you really want to know. So I?m having trouble > >>> connecting the dots between this and what you are saying here. > >>> > >>> I still am absolutely flabbergasted why the MACHINE_ARCH names > >>> aren?t necessary and sufficient for packaging. I?ve yet to see any > >>> coherent reason to not use them. > >> Why do I care that they match? Good question. When I was doing > >> FreeNAS, I looked at integrating pkgng into nanobsd. At the time this > >> was quite difficult because every single architecture name was > >> different between pkgng and MACHINE_ARCH. This would mean I?d have > >> to drag around a huge table to know how to translate one to the other > >> (there was no simple regex either, and things like mipsn32 wouldn?t > >> have fit into the scheme at the time). I would very much like us to > >> see us keep these names in sync and avoid large translation tables that > are difficult to maintain. > >> > >> Now, do you need to get it from uname -p? No. If you want to parse > >> elf files to get it, that?s fine, so long as the names map directly > >> to the MACHINE_ARCH names that we?ve been using for years. They > >> completely describe the universe of supported platforms. Are they > >> perfect? No, around the edge there may be an odd-ball that?s possible > >> to build, but is unsupported and likely doesn?t work at all. Have we > >> learned from these mistakes? Yes. Anything that?s actively supported > >> has a proper name. This name is needed, btw, so that any machine can > >> self-host, a nice feature of the /usr/src system. > > ABI consists of the following elements: > > > > - OS > > - OS ABI version (major version number in FreeBSD) > > - instruction set > > - programming model (ILP32 or LP64) > > - byte order (little/big endian) > > > > These are almost orthogonal dimensions in the sense that almost any > > combination is possible. (A combination that isn't possible is a > > 32-bit instruction set with LP64.) > > > > What you are asking for now is to combine two dimensions into one and > > combination in this case means multiplication so if you have 3 > > instruction sets and 2 programming models, the combined dimension > > needs > > 6 different values. You need to make the case for why you think this > > is a good idea. For the past 20 years we got away with this because > > on every installation of FreeBSD we only used one programming model at > > a time. This is still the case for byte order of course. > > > > What I'm saying is to keep the option open for installations with > > multiple programming models, where most binaries could use ILP32 and > > only the ones that actually need a 64-bit address space use LP64. > > You query the instruction set using uname and the programming models > > using getconf. > > > > I suppose you could replace the "x86" in the pkg scheme with > > i386/amd64, but then you'd still be talking about i386:32, amd64:32 > > and amd64:64 instead of x86:32, x86:x32 and x86:64. > > > > No. We support multiple "models" now and have for ten years. That's what > MACHINE_ARCH is for: it defines the choice of the last three things you list > above. Specifically, a shared value of MACHINE_ARCH guarantees and OS > version guarantees, in FreeBSD-land, complete binary compatibility of > executables. Kernels support multiple ones, in general (e.g. i386 binaries on > amd64, powerpc binaries on powerpc64). They may support more in the > future (x32 on amd64, potentially even cross-endian binaries). We have a > nice flexible scheme in FreeBSD for supporting this. If you want to find out > the list of the things the installed kernel can run,
Re: svn commit: r266553 - head/release/scripts
On May 26, 2014, at 4:18 PM, Tijl Coosemans wrote: > On Mon, 26 May 2014 09:53:57 -0600 Warner Losh wrote: >> On May 26, 2014, at 8:39 AM, Nathan Whitehorn wrote: >>> On 05/26/14 02:35, Tijl Coosemans wrote: On Sat, 24 May 2014 19:00:18 -0600 Warner Losh wrote: > On May 24, 2014, at 5:53 PM, Warner Losh wrote: >> On May 24, 2014, at 5:13 PM, Tijl Coosemans wrote: >>> There isn't necessarily any chroot environment. There's one kernel, >>> two equally valid ABIs (ILP32 and LP64) and any binary like uname might >>> use either of them. If uname -p returns a different result depending on >>> which of these two ABIs it was compiled for that could be a problem for >>> any script that uses it. >> Well, it depends on what you want to do with the script, eh? If you want >> to know the ABI of the native binary uname, that’s one thing. But if you >> want to know the supported ABIs, you are doing it wrong by using uname. >> You should be using sysctl kern.supported_abi. That will tell you all the >> ABIs that you can install packages for on this machine, which is what you >> really want to know. So I’m having trouble connecting the dots between >> this and what you are saying here. >> >> I still am absolutely flabbergasted why the MACHINE_ARCH names aren’t >> necessary and sufficient for packaging. I’ve yet to see any coherent >> reason to not use them. > Why do I care that they match? Good question. When I was doing FreeNAS, I > looked at integrating pkgng into nanobsd. At the time this was quite > difficult because every single architecture name was different between > pkgng and MACHINE_ARCH. This would mean I’d have to drag around a huge > table to know how to translate one to the other (there was no simple regex > either, and things like mipsn32 wouldn’t have fit into the scheme at the > time). I would very much like us to see us keep these names in sync and > avoid large translation tables that are difficult to maintain. > > Now, do you need to get it from uname -p? No. If you want to parse elf > files to get it, that’s fine, so long as the names map directly to the > MACHINE_ARCH names that we’ve been using for years. They completely > describe the universe of supported platforms. Are they perfect? No, around > the edge there may be an odd-ball that’s possible to build, but is > unsupported and likely doesn’t work at all. Have we learned from these > mistakes? Yes. Anything that’s actively supported has a proper name. This > name is needed, btw, so that any machine can self-host, a nice feature of > the /usr/src system. ABI consists of the following elements: - OS - OS ABI version (major version number in FreeBSD) >> >> These two are encoded in FreeBSD and major version. There’s no problem >> encoding these in the package architecture string. They are easily >> scriptable and totally obvious to FreeBSD users and pose no problems. >> Nobody is opposed to these, and actually they are rather a good idea. >> - instruction set - programming model (ILP32 or LP64) - byte order (little/big endian) >> >> These three are encoded in MACHINE_ARCH and have been for quite some >> time. And you forgot several things as well: register conventions, >> calling conventions, stack alignment, struct alignment, pointer >> conversion conventions, address space layout, page size constraints, >> etc. There are simply far too many to try to break down like you are >> trying to do. And that’s even before we get into shared library >> conventions... > > I didn't forget them, I just restricted it to the elements that came up > so far. All these extra elements are like byte order: you use only one > of each per combination of the first four fields so they can be discarded. > Things like calling conventions and register use can be considered part > of the programming model. The amd64 programming models that matter to > FreeBSD (both ILP32 and LP64) are documented in the System V Application > Binary Interface AMD64 Architecture Processor Supplement. Well yes and no. n32 and n64 have vastly different register conventions than o32. But we’re talking about something that’s off in the weeds. It doesn’t matter. It also doesn’t address my basic thesis “MACHINE_ARCH is enough” which you’ve not shown a coherent example of where it isn’t. These are almost orthogonal dimensions in the sense that almost any combination is possible. (A combination that isn't possible is a 32-bit instruction set with LP64.) >> >> All of these items are encoded in MACHINE_ARACH and have been for at >> least a decade. There’s no new argument here. If they were actually >> orthogonal, then that would be one thing. But they aren’t. They are all >> closely interrelated and we only support a vanishingly small number of >> possible conventions. Combinatorical
Re: svn commit: r266553 - head/release/scripts
On Mon, 26 May 2014 09:53:57 -0600 Warner Losh wrote: > On May 26, 2014, at 8:39 AM, Nathan Whitehorn wrote: >> On 05/26/14 02:35, Tijl Coosemans wrote: >>> On Sat, 24 May 2014 19:00:18 -0600 Warner Losh wrote: On May 24, 2014, at 5:53 PM, Warner Losh wrote: > On May 24, 2014, at 5:13 PM, Tijl Coosemans wrote: >> There isn't necessarily any chroot environment. There's one kernel, >> two equally valid ABIs (ILP32 and LP64) and any binary like uname might >> use either of them. If uname -p returns a different result depending on >> which of these two ABIs it was compiled for that could be a problem for >> any script that uses it. > Well, it depends on what you want to do with the script, eh? If you want > to know the ABI of the native binary uname, that’s one thing. But if you > want to know the supported ABIs, you are doing it wrong by using uname. > You should be using sysctl kern.supported_abi. That will tell you all the > ABIs that you can install packages for on this machine, which is what you > really want to know. So I’m having trouble connecting the dots between > this and what you are saying here. > > I still am absolutely flabbergasted why the MACHINE_ARCH names aren’t > necessary and sufficient for packaging. I’ve yet to see any coherent > reason to not use them. Why do I care that they match? Good question. When I was doing FreeNAS, I looked at integrating pkgng into nanobsd. At the time this was quite difficult because every single architecture name was different between pkgng and MACHINE_ARCH. This would mean I’d have to drag around a huge table to know how to translate one to the other (there was no simple regex either, and things like mipsn32 wouldn’t have fit into the scheme at the time). I would very much like us to see us keep these names in sync and avoid large translation tables that are difficult to maintain. Now, do you need to get it from uname -p? No. If you want to parse elf files to get it, that’s fine, so long as the names map directly to the MACHINE_ARCH names that we’ve been using for years. They completely describe the universe of supported platforms. Are they perfect? No, around the edge there may be an odd-ball that’s possible to build, but is unsupported and likely doesn’t work at all. Have we learned from these mistakes? Yes. Anything that’s actively supported has a proper name. This name is needed, btw, so that any machine can self-host, a nice feature of the /usr/src system. >>> ABI consists of the following elements: >>> >>> - OS >>> - OS ABI version (major version number in FreeBSD) > > These two are encoded in FreeBSD and major version. There’s no problem > encoding these in the package architecture string. They are easily > scriptable and totally obvious to FreeBSD users and pose no problems. > Nobody is opposed to these, and actually they are rather a good idea. > >>> - instruction set >>> - programming model (ILP32 or LP64) >>> - byte order (little/big endian) > > These three are encoded in MACHINE_ARCH and have been for quite some > time. And you forgot several things as well: register conventions, > calling conventions, stack alignment, struct alignment, pointer > conversion conventions, address space layout, page size constraints, > etc. There are simply far too many to try to break down like you are > trying to do. And that’s even before we get into shared library > conventions... I didn't forget them, I just restricted it to the elements that came up so far. All these extra elements are like byte order: you use only one of each per combination of the first four fields so they can be discarded. Things like calling conventions and register use can be considered part of the programming model. The amd64 programming models that matter to FreeBSD (both ILP32 and LP64) are documented in the System V Application Binary Interface AMD64 Architecture Processor Supplement. >>> These are almost orthogonal dimensions in the sense that almost any >>> combination is possible. (A combination that isn't possible is a >>> 32-bit instruction set with LP64.) > > All of these items are encoded in MACHINE_ARACH and have been for at > least a decade. There’s no new argument here. If they were actually > orthogonal, then that would be one thing. But they aren’t. They are all > closely interrelated and we only support a vanishingly small number of > possible conventions. Combinatorically, it can be hundreds. Practically, > it is usually only a handful. > >>> What you are asking for now is to combine two dimensions into one and >>> combination in this case means multiplication so if you have 3 >>> instruction sets and 2 programming models, the combined dimension needs >>> 6 different values. You need to make the case for why you think this >>> is a good idea. > > Because uanme has to be 6 different things s
Re: svn commit: r264912 - in head: share/man/man4 sys/conf sys/contrib/dev/urtwn sys/dev/usb sys/dev/usb/wlan sys/modules/usb/urtwnfw sys/modules/usb/urtwnfw/urtwnrtl8188eu
I think this accidentally removed
URTWN_DEV(ASUS, USBN10NANO),
2014-04-25 16:01 GMT+08:00 Kevin Lo :
> Author: kevlo
> Date: Fri Apr 25 08:01:22 2014
> New Revision: 264912
> URL: http://svnweb.freebsd.org/changeset/base/264912
>
> Log:
> Add preliminary support for the Realtek RTL8188EUS and RTL8188ETV chipsets.
>
> Committed over the TP-LINK TL-WN725N v2 (RTL8188EUS) on amd64 with WPA.
>
> Added:
> head/sys/contrib/dev/urtwn/urtwn-rtl8188eufw.fw.uu
> head/sys/modules/usb/urtwnfw/urtwnrtl8188eu/
> head/sys/modules/usb/urtwnfw/urtwnrtl8188eu/Makefile (contents, props
> changed)
> Modified:
> head/share/man/man4/urtwn.4
> head/share/man/man4/urtwnfw.4
> head/sys/conf/files
> head/sys/dev/usb/usbdevs
> head/sys/dev/usb/wlan/if_urtwn.c
> head/sys/dev/usb/wlan/if_urtwnreg.h
> head/sys/modules/usb/urtwnfw/Makefile
>
> Modified: head/share/man/man4/urtwn.4
> ==
> --- head/share/man/man4/urtwn.4 Fri Apr 25 04:49:27 2014(r264911)
> +++ head/share/man/man4/urtwn.4 Fri Apr 25 08:01:22 2014(r264912)
> @@ -14,12 +14,12 @@
> .\"
> .\" $FreeBSD$
> .\"
> -.Dd October 31, 2013
> +.Dd April 25, 2014
> .Dt URTWN 4
> .Os
> .Sh NAME
> .Nm urtwn
> -.Nd Realtek RTL8188CU/RTL8192CU USB IEEE 802.11b/g/n wireless network device
> +.Nd Realtek RTL8188CU/RTL8188EU/RTL8192CU USB IEEE 802.11b/g/n wireless
> network device
> .Sh SYNOPSIS
> To compile this driver into the kernel,
> place the following lines in your
> @@ -50,11 +50,11 @@ legal.realtek.license_ack=1
> The
> .Nm
> driver supports USB 2.0 wireless network devices based on Realtek
> -RTL8188CUS, RTL8188CE-VAU, RTL8188RU and RTL8192CU chipsets.
> +RTL8188CUS, RTL8188CE-VAU, RTL8188EUS, RTL8188RU and RTL8192CU chipsets.
> .Pp
> -The RTL8188CUS is a highly integrated 802.11n adapter that combines
> -a MAC, a 1T1R capable baseband and an RF in a single chip.
> -It operates in the 2GHz spectrum only.
> +The RTL8188CUS and RTL8188EUS are highly integrated 802.11n adapter that
> +combine a MAC, a 1T1R capable baseband and an RF in a single chip.
> +They operate in the 2GHz spectrum only.
> The RTL8188RU is a high-power variant of the RTL8188CUS.
> The RTL8188CE-VAU is a PCI Express Mini Card adapter that attaches
> to the USB interface.
> @@ -90,6 +90,8 @@ The following adapters should work:
> .It Netgear WNA1000M
> .It Realtek RTL8192CU
> .It Realtek RTL8188CUS
> +.It TP-LINK TL-WN723N v3
> +.It TP-LINK TL-WN725N v2
> .El
> .Sh EXAMPLES
> Join an existing BSS network (i.e., connect to an access point):
>
> Modified: head/share/man/man4/urtwnfw.4
> ==
> --- head/share/man/man4/urtwnfw.4 Fri Apr 25 04:49:27 2014
> (r264911)
> +++ head/share/man/man4/urtwnfw.4 Fri Apr 25 08:01:22 2014
> (r264912)
> @@ -22,7 +22,7 @@
> .\"
> .\" $FreeBSD$
> .\"
> -.Dd October 31, 2013
> +.Dd April 25, 2014
> .Dt URTWNFW 4
> .Os
> .Sh NAME
> @@ -42,6 +42,7 @@ of the following:
> .Bd -ragged -offset indent
> .Cd "device urtwn-rtl8192cfwT"
> .Cd "device urtwn-rtl8192cfwU"
> +.Cd "device urtwn-rtl8188eufw"
> .Ed
> .Pp
> Alternatively, to load the driver as a
> @@ -50,10 +51,11 @@ module at boot time, place the following
> .Bd -literal -offset indent
> urtwn-rtl8192cfwT_load="YES"
> urtwn-rtl8192cfwU_load="YES"
> +urtwn-rtl8188eufw_load="YES"
> .Ed
> .Sh DESCRIPTION
> This module provides access to firmware sets for the
> -Realtek RTL8188CUS, RTL8188CE-VAU, RTL8188RU and RTL8192CU
> +Realtek RTL8188CUS, RTL8188CE-VAU, RTL8188EUS, RTL8188RU and RTL8192CU
> chip based USB WiFi adapters.
> It may be
> statically linked into the kernel, or loaded as a module.
>
> Modified: head/sys/conf/files
> ==
> --- head/sys/conf/files Fri Apr 25 04:49:27 2014(r264911)
> +++ head/sys/conf/files Fri Apr 25 08:01:22 2014(r264912)
> @@ -2373,6 +2373,20 @@ dev/usb/wlan/if_upgt.c optional upgt
> dev/usb/wlan/if_ural.c optional ural
> dev/usb/wlan/if_urtw.c optional urtw
> dev/usb/wlan/if_urtwn.coptional urtwn
> +urtwn-rtl8188eufw.coptional urtwn-rtl8188eufw | urtwnfw\
> + compile-with"${AWK} -f $S/tools/fw_stub.awk
> urtwn-rtl8188eufw.fw:urtwn-rtl8188eufw:111 -murtwn-rtl8188eufw -c${.TARGET}" \
> + no-implicit-rule before-depend local\
> + clean "urtwn-rtl8188eufw.c"
> +urtwn-rtl8188eufw.fwo optional urtwn-rtl8188eufw | urtwnfw\
> + dependency "urtwn-rtl8188eufw.fw" \
> + compile-with"${NORMAL_FWO}" \
> + no-implicit-rule\
> + clean "urtwn-rtl8188eufw.fwo"
> +urtwn-rtl8188eufw.fw
svn commit: r266709 - head/share/man/man4
Author: brueffer Date: Mon May 26 19:02:34 2014 New Revision: 266709 URL: http://svnweb.freebsd.org/changeset/base/266709 Log: Language cleanup. Reviewed by: mav, bcr, wblock MFC after:1 week Modified: head/share/man/man4/attimer.4 Modified: head/share/man/man4/attimer.4 == --- head/share/man/man4/attimer.4 Mon May 26 18:21:08 2014 (r266708) +++ head/share/man/man4/attimer.4 Mon May 26 19:02:34 2014 (r266709) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd September 14, 2010 +.Dd May 26, 2014 .Dt ATTIMER 4 .Os .Sh NAME @@ -37,38 +37,48 @@ The following tunables are settable from .Xr loader 8 : .Bl -ohang .It Va hint.attimer. Ns Ar X Ns Va .clock -controls event timers functionality support. Setting to 0, disables it. -Default value is 1. +controls support for the event timer functionality. +Setting this value to +.Dv 0 +disables it. +The default value is +.Dv 1 . .It Va hint.attimer. Ns Ar X Ns Va .timecounter -controls time counter functionality support. Setting to 0, disables it. -Default value is 1. +controls support for the time counter functionality. +Setting this value to +.Dv 0 +disables it. +The default value is +.Dv 1 . .It Va hw.i8254.freq -allows to override default counter frequency. -The same value is also available in run-time via +allows overriding the default counter frequency. +The same value is also available at run-time via the .Va machdep.i8254_freq sysctl. .El .Sh DESCRIPTION This driver uses i8254 Programmable Interval Timer (AT Timer) hardware -to supply kernel with one time counter and one event timer, and generate -sound tones for system speaker. +to supply the kernel with one timecounter and one event timer, and to generate +sound tones for the system speaker. This hardware includes three channels. -Each channel includes 16bit counter, counting down with known, +Each channel includes a 16 bit counter which decreases with a known, platform-dependent frequency. Counters can operate in several different modes, including periodic and one-shot. -Output of each channel has platform-defined wiring: one channel is wired +The output of each channel has platform-defined wiring: one channel is wired to the interrupt controller and may be used as event timer, one channel is -wired to speaker and used to generate sound tones, and one timer is reserved +wired to the speaker and used to generate sound tones, and one timer is reserved for platform purposes. .Pp -Driver uses single hardware channel to provide both time counter and event +The +.Nm +driver uses a single hardware channel to provide both time counter and event timer functionality. -To make it possible, respective counter must be running in periodic more. -As result, one-shot event timer mode supported only when time counter +To make this possible, the respective counter must be running in periodic mode. +As a result, the one-shot event timer mode is supported only when time counter functionality is disabled. .Pp -Event timer provided by the driver is irrelevant to CPU power states. +The event timer provided by the driver is irrelevant to CPU power states. .Sh SEE ALSO .Xr apic 4 , .Xr atrtc 4 , ___ 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: r266708 - in head: lib/libvmmapi usr.sbin/bhyve
Author: neel
Date: Mon May 26 18:21:08 2014
New Revision: 266708
URL: http://svnweb.freebsd.org/changeset/base/266708
Log:
Fix issue with restarting an "insb/insw/insl" instruction because of a page
fault on the destination buffer.
Prior to this change a page fault would be detected in vm_copyout(). This
was done after the I/O port access was done. If the I/O port access had
side-effects (e.g. reading the uart FIFO) then restarting the instruction
would result in incorrect behavior.
Fix this by validating the guest linear address before doing the I/O port
emulation. If the validation results in a page fault exception being injected
into the guest then the instruction can now be restarted without any
side-effects.
Modified:
head/lib/libvmmapi/vmmapi.c
head/lib/libvmmapi/vmmapi.h
head/usr.sbin/bhyve/inout.c
Modified: head/lib/libvmmapi/vmmapi.c
==
--- head/lib/libvmmapi/vmmapi.c Mon May 26 18:02:36 2014(r266707)
+++ head/lib/libvmmapi/vmmapi.c Mon May 26 18:21:08 2014(r266708)
@@ -33,6 +33,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
@@ -940,7 +941,7 @@ vm_get_hpet_capabilities(struct vmctx *c
}
static int
-vm_gla2gpa(struct vmctx *ctx, int vcpu, struct vm_guest_paging *paging,
+gla2gpa(struct vmctx *ctx, int vcpu, struct vm_guest_paging *paging,
uint64_t gla, int prot, int *fault, uint64_t *gpa)
{
struct vm_gla2gpa gg;
@@ -965,18 +966,20 @@ vm_gla2gpa(struct vmctx *ctx, int vcpu,
#endif
int
-vm_copyin(struct vmctx *ctx, int vcpu, struct vm_guest_paging *paging,
-uint64_t gla, void *vp, size_t len)
+vm_gla2gpa(struct vmctx *ctx, int vcpu, struct vm_guest_paging *paging,
+uint64_t gla, size_t len, int prot, struct iovec *iov, int iovcnt)
{
- char *dst;
- const char *src;
uint64_t gpa;
- int error, fault, n, off;
+ int error, fault, i, n, off;
+
+ for (i = 0; i < iovcnt; i++) {
+ iov[i].iov_base = 0;
+ iov[i].iov_len = 0;
+ }
- dst = vp;
while (len) {
- error = vm_gla2gpa(ctx, vcpu, paging, gla, PROT_READ,
- &fault, &gpa);
+ assert(iovcnt > 0);
+ error = gla2gpa(ctx, vcpu, paging, gla, prot, &fault, &gpa);
if (error)
return (-1);
if (fault)
@@ -984,42 +987,59 @@ vm_copyin(struct vmctx *ctx, int vcpu, s
off = gpa & PAGE_MASK;
n = min(len, PAGE_SIZE - off);
- src = vm_map_gpa(ctx, gpa, n);
- bcopy(src, dst, n);
+
+ iov->iov_base = (void *)gpa;
+ iov->iov_len = n;
+ iov++;
+ iovcnt--;
gla += n;
- dst += n;
len -= n;
}
return (0);
}
-int
-vm_copyout(struct vmctx *ctx, int vcpu, struct vm_guest_paging *paging,
-const void *vp, uint64_t gla, size_t len)
+void
+vm_copyin(struct vmctx *ctx, int vcpu, struct iovec *iov, void *vp, size_t len)
{
- uint64_t gpa;
+ const char *src;
char *dst;
+ uint64_t gpa;
+ size_t n;
+
+ dst = vp;
+ while (len) {
+ assert(iov->iov_len);
+ gpa = (uint64_t)iov->iov_base;
+ n = min(len, iov->iov_len);
+ src = vm_map_gpa(ctx, gpa, n);
+ bcopy(src, dst, n);
+
+ iov++;
+ dst += n;
+ len -= n;
+ }
+}
+
+void
+vm_copyout(struct vmctx *ctx, int vcpu, const void *vp, struct iovec *iov,
+size_t len)
+{
const char *src;
- int error, fault, n, off;
+ char *dst;
+ uint64_t gpa;
+ size_t n;
src = vp;
while (len) {
- error = vm_gla2gpa(ctx, vcpu, paging, gla, PROT_WRITE,
- &fault, &gpa);
- if (error)
- return (-1);
- if (fault)
- return (1);
-
- off = gpa & PAGE_MASK;
- n = min(len, PAGE_SIZE - off);
+ assert(iov->iov_len);
+ gpa = (uint64_t)iov->iov_base;
+ n = min(len, iov->iov_len);
dst = vm_map_gpa(ctx, gpa, n);
bcopy(src, dst, n);
- gla += n;
+ iov++;
src += n;
len -= n;
}
- return (0);
}
Modified: head/lib/libvmmapi/vmmapi.h
==
--- head/lib/libvmmapi/vmmapi.h Mon May 26 18:02:36 2014(r266707)
+++ head/lib/libvmmapi/vmmapi.h Mon May 26 18:21:08 2014(r266708)
@@ -29,6 +29,7 @@
#ifndef _VMMAPI_H_
#define_VMMAPI_H_
+struct iovec;
struct vmctx;
enum x2apic_state;
@@ -109,10 +110,17 @@ int vm_set_x2apic_stat
svn commit: r266707 - head/sys/arm/ti
Author: andrew
Date: Mon May 26 18:02:36 2014
New Revision: 266707
URL: http://svnweb.freebsd.org/changeset/base/266707
Log:
Rework the Ti GPIO driver to work on multiple SoCs. At the moment it could
work with OMAP4 and AM335x without needing to recompile.
Reviewed by: loos
Modified:
head/sys/arm/ti/ti_gpio.c
Modified: head/sys/arm/ti/ti_gpio.c
==
--- head/sys/arm/ti/ti_gpio.c Mon May 26 17:06:56 2014(r266706)
+++ head/sys/arm/ti/ti_gpio.c Mon May 26 18:02:36 2014(r266707)
@@ -56,6 +56,7 @@ __FBSDID("$FreeBSD$");
#include
#include
+#include
#include
#include
@@ -130,24 +131,102 @@ __FBSDID("$FreeBSD$");
#endif
/* Other SoC Specific definitions */
-#if defined(SOC_OMAP3)
-#defineMAX_GPIO_BANKS 6
-#defineFIRST_GPIO_BANK 1
-#defineINTR_PER_BANK 1
-#defineTI_GPIO_REV 0x0025
-#elif defined(SOC_OMAP4)
+#defineOMAP3_MAX_GPIO_BANKS6
+#defineOMAP3_FIRST_GPIO_BANK 1
+#defineOMAP3_INTR_PER_BANK 1
+#defineOMAP3_GPIO_REV 0x0025
+#defineOMAP4_MAX_GPIO_BANKS6
+#defineOMAP4_FIRST_GPIO_BANK 1
+#defineOMAP4_INTR_PER_BANK 1
+#defineOMAP4_GPIO_REV 0x50600801
+#defineAM335X_MAX_GPIO_BANKS 4
+#defineAM335X_FIRST_GPIO_BANK 0
+#defineAM335X_INTR_PER_BANK2
+#defineAM335X_GPIO_REV 0x50600801
+#definePINS_PER_BANK 32
#defineMAX_GPIO_BANKS 6
-#defineFIRST_GPIO_BANK 1
-#defineINTR_PER_BANK 1
-#defineTI_GPIO_REV 0x50600801
-#elif defined(SOC_TI_AM335X)
-#defineMAX_GPIO_BANKS 4
-#defineFIRST_GPIO_BANK 0
-#defineINTR_PER_BANK 2
-#defineTI_GPIO_REV 0x50600801
+/* Maximum GPIOS possible, max of *_MAX_GPIO_BANKS * *_INTR_PER_BANK */
+#defineMAX_GPIO_INTRS 8
+
+static u_int
+ti_max_gpio_banks(void)
+{
+ switch(ti_chip()) {
+#ifdef SOC_OMAP3
+ case CHIP_OMAP_3:
+ return (OMAP3_MAX_GPIO_BANKS);
#endif
-#definePINS_PER_BANK 32
-#defineMAX_GPIO_INTRS MAX_GPIO_BANKS * INTR_PER_BANK
+#ifdef SOC_OMAP4
+ case CHIP_OMAP_4:
+ return (OMAP4_MAX_GPIO_BANKS);
+#endif
+#ifdef SOC_TI_AM335X
+ case CHIP_AM335X:
+ return (AM335X_MAX_GPIO_BANKS);
+#endif
+ }
+ return (0);
+}
+
+static u_int
+ti_max_gpio_intrs(void)
+{
+ switch(ti_chip()) {
+#ifdef SOC_OMAP3
+ case CHIP_OMAP_3:
+ return (OMAP3_MAX_GPIO_BANKS * OMAP3_INTR_PER_BANK);
+#endif
+#ifdef SOC_OMAP4
+ case CHIP_OMAP_4:
+ return (OMAP4_MAX_GPIO_BANKS * OMAP4_INTR_PER_BANK);
+#endif
+#ifdef SOC_TI_AM335X
+ case CHIP_AM335X:
+ return (AM335X_MAX_GPIO_BANKS * AM335X_INTR_PER_BANK);
+#endif
+ }
+ return (0);
+}
+
+static u_int
+ti_first_gpio_bank(void)
+{
+ switch(ti_chip()) {
+#ifdef SOC_OMAP3
+ case CHIP_OMAP_3:
+ return (OMAP3_FIRST_GPIO_BANK);
+#endif
+#ifdef SOC_OMAP4
+ case CHIP_OMAP_4:
+ return (OMAP4_FIRST_GPIO_BANK);
+#endif
+#ifdef SOC_TI_AM335X
+ case CHIP_AM335X:
+ return (AM335X_FIRST_GPIO_BANK);
+#endif
+ }
+ return (0);
+}
+
+static uint32_t
+ti_gpio_rev(void)
+{
+ switch(ti_chip()) {
+#ifdef SOC_OMAP3
+ case CHIP_OMAP_3:
+ return (OMAP3_GPIO_REV);
+#endif
+#ifdef SOC_OMAP4
+ case CHIP_OMAP_4:
+ return (OMAP4_GPIO_REV);
+#endif
+#ifdef SOC_TI_AM335X
+ case CHIP_AM335X:
+ return (AM335X_GPIO_REV);
+#endif
+ }
+ return (0);
+}
/**
* ti_gpio_mem_spec - Resource specification used when allocating resources
@@ -301,7 +380,7 @@ ti_gpio_pin_max(device_t dev, int *maxpi
/* Calculate how many valid banks we have and then multiply that by 32
to
* give use the total number of pins.
*/
- for (i = 0; i < MAX_GPIO_BANKS; i++) {
+ for (i = 0; i < ti_max_gpio_banks(); i++) {
if (sc->sc_mem_res[i] != NULL)
banks++;
}
@@ -340,7 +419,7 @@ ti_gpio_pin_getcaps(device_t dev, uint32
TI_GPIO_LOCK(sc);
/* Sanity check the pin number is valid */
- if ((bank >= MAX_GPIO_BANKS) || (sc->sc_mem_res[bank] == NULL)) {
+ if ((bank >= ti_max_gpio_banks()) || (sc->sc_mem_res[bank] == NULL)) {
TI_GPIO_UNLOCK(sc);
return (EINVAL);
}
@@ -378,7 +457,7 @@ ti_gpio_pin_getflags(device_t
svn commit: r266702 - head/release/doc/en_US.ISO8859-1/relnotes
Author: gshapiro Date: Mon May 26 15:54:31 2014 New Revision: 266702 URL: http://svnweb.freebsd.org/changeset/base/266702 Log: Note proper revision number for sendmail 8.14.9 merge. Modified: head/release/doc/en_US.ISO8859-1/relnotes/article.xml Modified: head/release/doc/en_US.ISO8859-1/relnotes/article.xml == --- head/release/doc/en_US.ISO8859-1/relnotes/article.xml Mon May 26 15:53:24 2014(r266701) +++ head/release/doc/en_US.ISO8859-1/relnotes/article.xml Mon May 26 15:54:31 2014(r266702) @@ -346,7 +346,7 @@ &man.jemalloc.3; has been updated to version 3.5.0. -Sendmail +Sendmail has been updated from 8.14.7 to 8.14.9. bmake has been ___ 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 26, 2014, at 8:39 AM, Nathan Whitehorn wrote: > On 05/26/14 02:35, Tijl Coosemans wrote: >> On Sat, 24 May 2014 19:00:18 -0600 Warner Losh wrote: >>> On May 24, 2014, at 5:53 PM, Warner Losh wrote: On May 24, 2014, at 5:13 PM, Tijl Coosemans wrote: > There isn't necessarily any chroot environment. There's one kernel, > two equally valid ABIs (ILP32 and LP64) and any binary like uname might > use either of them. If uname -p returns a different result depending on > which of these two ABIs it was compiled for that could be a problem for > any script that uses it. Well, it depends on what you want to do with the script, eh? If you want to know the ABI of the native binary uname, that’s one thing. But if you want to know the supported ABIs, you are doing it wrong by using uname. You should be using sysctl kern.supported_abi. That will tell you all the ABIs that you can install packages for on this machine, which is what you really want to know. So I’m having trouble connecting the dots between this and what you are saying here. I still am absolutely flabbergasted why the MACHINE_ARCH names aren’t necessary and sufficient for packaging. I’ve yet to see any coherent reason to not use them. >>> Why do I care that they match? Good question. When I was doing FreeNAS, I >>> looked at integrating pkgng into nanobsd. At the time this was quite >>> difficult because every single architecture name was different between >>> pkgng and MACHINE_ARCH. This would mean I’d have to drag around a huge >>> table to know how to translate one to the other (there was no simple regex >>> either, and things like mipsn32 wouldn’t have fit into the scheme at the >>> time). I would very much like us to see us keep these names in sync and >>> avoid large translation tables that are difficult to maintain. >>> >>> Now, do you need to get it from uname -p? No. If you want to parse elf >>> files to get it, that’s fine, so long as the names map directly to the >>> MACHINE_ARCH names that we’ve been using for years. They completely >>> describe the universe of supported platforms. Are they perfect? No, around >>> the edge there may be an odd-ball that’s possible to build, but is >>> unsupported and likely doesn’t work at all. Have we learned from these >>> mistakes? Yes. Anything that’s actively supported has a proper name. This >>> name is needed, btw, so that any machine can self-host, a nice feature of >>> the /usr/src system. >> ABI consists of the following elements: >> >> - OS >> - OS ABI version (major version number in FreeBSD) These two are encoded in FreeBSD and major version. There’s no problem encoding these in the package architecture string. They are easily scriptable and totally obvious to FreeBSD users and pose no problems. Nobody is opposed to these, and actually they are rather a good idea. >> - instruction set >> - programming model (ILP32 or LP64) >> - byte order (little/big endian) These three are encoded in MACHINE_ARCH and have been for quite some time. And you forgot several things as well: register conventions, calling conventions, stack alignment, struct alignment, pointer conversion conventions, address space layout, page size constraints, etc. There are simply far too many to try to break down like you are trying to do. And that’s even before we get into shared library conventions... >> These are almost orthogonal dimensions in the sense that almost any >> combination is possible. (A combination that isn't possible is a >> 32-bit instruction set with LP64.) All of these items are encoded in MACHINE_ARACH and have been for at least a decade. There’s no new argument here. If they were actually orthogonal, then that would be one thing. But they aren’t. They are all closely interrelated and we only support a vanishingly small number of possible conventions. Combinatorically, it can be hundreds. Practically, it is usually only a handful. >> What you are asking for now is to combine two dimensions into one and >> combination in this case means multiplication so if you have 3 >> instruction sets and 2 programming models, the combined dimension needs >> 6 different values. You need to make the case for why you think this >> is a good idea. Because uanme has to be 6 different things so the right binaries are built. It is really that simple. And we’ve already made the case, and have been using this convention for a very long time. It works. I’m not sure that the burden is on us to justify why a convention that’s been in use since FreeBSD 6 needs to not change. As weird as you might think it is, it is a convention that our users understand. >> For the past 20 years we got away with this because >> on every installation of FreeBSD we only used one programming model at >> a time. This is still the case for byte order of course. This isn’t true. For the past 15 years we’ve supported two programming model
svn commit: r266691 - head/usr.bin/printf/tests
Author: pfg
Date: Mon May 26 15:08:39 2014
New Revision: 266691
URL: http://svnweb.freebsd.org/changeset/base/266691
Log:
printf(1): add tests for warn about incomplete uses n$
Submitted by: jilles
MFC after:2 weeks
Added:
head/usr.bin/printf/tests/regress.missingpos1.out (contents, props changed)
Modified:
head/usr.bin/printf/tests/regress.sh
Added: head/usr.bin/printf/tests/regress.missingpos1.out
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/usr.bin/printf/tests/regress.missingpos1.out Mon May 26 15:08:39
2014(r266691)
@@ -0,0 +1 @@
+printf: incomplete use of n$
Modified: head/usr.bin/printf/tests/regress.sh
==
--- head/usr.bin/printf/tests/regress.shMon May 26 14:57:47 2014
(r266690)
+++ head/usr.bin/printf/tests/regress.shMon May 26 15:08:39 2014
(r266691)
@@ -19,5 +19,13 @@ REGRESSION_TEST('zero', `printf "%u%u\n"
REGRESSION_TEST('zero', `printf "%d%d\n" 15')
REGRESSION_TEST('zero', `printf "%d%u\n" 15')
REGRESSION_TEST('zero', `printf "%u%d\n" 15')
+REGRESSION_TEST(`missingpos1', `printf "%1\$*s" 1 1 2>&1')
+REGRESSION_TEST(`missingpos1', `printf "%*1\$s" 1 1 2>&1')
+REGRESSION_TEST(`missingpos1', `printf "%1\$*.*s" 1 1 1 2>&1')
+REGRESSION_TEST(`missingpos1', `printf "%*1\$.*s" 1 1 1 2>&1')
+REGRESSION_TEST(`missingpos1', `printf "%*.*1\$s" 1 1 1 2>&1')
+REGRESSION_TEST(`missingpos1', `printf "%1\$*2\$.*s" 1 1 1 2>&1')
+REGRESSION_TEST(`missingpos1', `printf "%*1\$.*2\$s" 1 1 1 2>&1')
+REGRESSION_TEST(`missingpos1', `printf "%1\$*.*2\$s" 1 1 1 2>&1')
REGRESSION_END()
___
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: r266690 - head/usr.bin/printf
Author: pfg
Date: Mon May 26 14:57:47 2014
New Revision: 266690
URL: http://svnweb.freebsd.org/changeset/base/266690
Log:
printf(1): warn about incomplete uses n$
Reviewed by: jilles
Obtained from:Illumos
MFC after:2 weeks
Modified:
head/usr.bin/printf/printf.c
Modified: head/usr.bin/printf/printf.c
==
--- head/usr.bin/printf/printf.cMon May 26 13:23:36 2014
(r266689)
+++ head/usr.bin/printf/printf.cMon May 26 14:57:47 2014
(r266690)
@@ -244,11 +244,11 @@ printf_doformat(char *fmt, int *rval)
/* save format argument */
fargv = gargv;
} else {
- fargv = NULL;
+ fargv = NULL;
}
/* skip to field width */
- while (strchr(skip1, *fmt) != NULL) {
+ while (*fmt && strchr(skip1, *fmt) != NULL) {
*dptr++ = *fmt++;
*dptr = 0;
}
@@ -259,12 +259,19 @@ printf_doformat(char *fmt, int *rval)
l = strspn(fmt, digits);
if ((l > 0) && (fmt[l] == '$')) {
int idx = atoi(fmt);
+ if (fargv == NULL) {
+ warnx("incomplete use of n$");
+ return (NULL);
+ }
if (idx <= myargc) {
gargv = &myargv[idx - 1];
} else {
gargv = &myargv[myargc];
}
fmt += l + 1;
+ } else if (fargv != NULL) {
+ warnx("incomplete use of n$");
+ return (NULL);
}
if (getint(&fieldwidth))
@@ -296,12 +303,19 @@ printf_doformat(char *fmt, int *rval)
l = strspn(fmt, digits);
if ((l > 0) && (fmt[l] == '$')) {
int idx = atoi(fmt);
+ if (fargv == NULL) {
+ warnx("incomplete use of n$");
+ return (NULL);
+ }
if (idx <= myargc) {
gargv = &myargv[idx - 1];
} else {
gargv = &myargv[myargc];
}
fmt += l + 1;
+ } else if (fargv != NULL) {
+ warnx("incomplete use of n$");
+ return (NULL);
}
if (getint(&precision))
___
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/26/14 02:35, Tijl Coosemans wrote: On Sat, 24 May 2014 19:00:18 -0600 Warner Losh wrote: On May 24, 2014, at 5:53 PM, Warner Losh wrote: On May 24, 2014, at 5:13 PM, Tijl Coosemans wrote: There isn't necessarily any chroot environment. There's one kernel, two equally valid ABIs (ILP32 and LP64) and any binary like uname might use either of them. If uname -p returns a different result depending on which of these two ABIs it was compiled for that could be a problem for any script that uses it. Well, it depends on what you want to do with the script, eh? If you want to know the ABI of the native binary uname, that’s one thing. But if you want to know the supported ABIs, you are doing it wrong by using uname. You should be using sysctl kern.supported_abi. That will tell you all the ABIs that you can install packages for on this machine, which is what you really want to know. So I’m having trouble connecting the dots between this and what you are saying here. I still am absolutely flabbergasted why the MACHINE_ARCH names aren’t necessary and sufficient for packaging. I’ve yet to see any coherent reason to not use them. Why do I care that they match? Good question. When I was doing FreeNAS, I looked at integrating pkgng into nanobsd. At the time this was quite difficult because every single architecture name was different between pkgng and MACHINE_ARCH. This would mean I’d have to drag around a huge table to know how to translate one to the other (there was no simple regex either, and things like mipsn32 wouldn’t have fit into the scheme at the time). I would very much like us to see us keep these names in sync and avoid large translation tables that are difficult to maintain. Now, do you need to get it from uname -p? No. If you want to parse elf files to get it, that’s fine, so long as the names map directly to the MACHINE_ARCH names that we’ve been using for years. They completely describe the universe of supported platforms. Are they perfect? No, around the edge there may be an odd-ball that’s possible to build, but is unsupported and likely doesn’t work at all. Have we learned from these mistakes? Yes. Anything that’s actively supported has a proper name. This name is needed, btw, so that any machine can self-host, a nice feature of the /usr/src system. ABI consists of the following elements: - OS - OS ABI version (major version number in FreeBSD) - instruction set - programming model (ILP32 or LP64) - byte order (little/big endian) These are almost orthogonal dimensions in the sense that almost any combination is possible. (A combination that isn't possible is a 32-bit instruction set with LP64.) What you are asking for now is to combine two dimensions into one and combination in this case means multiplication so if you have 3 instruction sets and 2 programming models, the combined dimension needs 6 different values. You need to make the case for why you think this is a good idea. For the past 20 years we got away with this because on every installation of FreeBSD we only used one programming model at a time. This is still the case for byte order of course. What I'm saying is to keep the option open for installations with multiple programming models, where most binaries could use ILP32 and only the ones that actually need a 64-bit address space use LP64. You query the instruction set using uname and the programming models using getconf. I suppose you could replace the "x86" in the pkg scheme with i386/amd64, but then you'd still be talking about i386:32, amd64:32 and amd64:64 instead of x86:32, x86:x32 and x86:64. No. We support multiple "models" now and have for ten years. That's what MACHINE_ARCH is for: it defines the choice of the last three things you list above. Specifically, a shared value of MACHINE_ARCH guarantees and OS version guarantees, in FreeBSD-land, complete binary compatibility of executables. Kernels support multiple ones, in general (e.g. i386 binaries on amd64, powerpc binaries on powerpc64). They may support more in the future (x32 on amd64, potentially even cross-endian binaries). We have a nice flexible scheme in FreeBSD for supporting this. If you want to find out the list of the things the installed kernel can run, check the kern.supported_archs sysctl. Simple. These strings are just as expressive as the ones in pkg. They are the standard. They're what external build systems test against, what the src, doc, and ports trees use to define what to do universally. It's what users and code expect. The wheel we've had for 20 years is perfectly good -- why invent a new, incompatible one? -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: r266553 - head/release/scripts
On Sat, 24 May 2014 19:00:18 -0600 Warner Losh wrote: > On May 24, 2014, at 5:53 PM, Warner Losh wrote: >> On May 24, 2014, at 5:13 PM, Tijl Coosemans wrote: >>> There isn't necessarily any chroot environment. There's one kernel, >>> two equally valid ABIs (ILP32 and LP64) and any binary like uname might >>> use either of them. If uname -p returns a different result depending on >>> which of these two ABIs it was compiled for that could be a problem for >>> any script that uses it. >> >> Well, it depends on what you want to do with the script, eh? If you want >> to know the ABI of the native binary uname, that’s one thing. But if you >> want to know the supported ABIs, you are doing it wrong by using uname. >> You should be using sysctl kern.supported_abi. That will tell you all the >> ABIs that you can install packages for on this machine, which is what you >> really want to know. So I’m having trouble connecting the dots between >> this and what you are saying here. >> >> I still am absolutely flabbergasted why the MACHINE_ARCH names aren’t >> necessary and sufficient for packaging. I’ve yet to see any coherent >> reason to not use them. > > Why do I care that they match? Good question. When I was doing FreeNAS, I > looked at integrating pkgng into nanobsd. At the time this was quite > difficult because every single architecture name was different between > pkgng and MACHINE_ARCH. This would mean I’d have to drag around a huge > table to know how to translate one to the other (there was no simple regex > either, and things like mipsn32 wouldn’t have fit into the scheme at the > time). I would very much like us to see us keep these names in sync and > avoid large translation tables that are difficult to maintain. > > Now, do you need to get it from uname -p? No. If you want to parse elf > files to get it, that’s fine, so long as the names map directly to the > MACHINE_ARCH names that we’ve been using for years. They completely > describe the universe of supported platforms. Are they perfect? No, around > the edge there may be an odd-ball that’s possible to build, but is > unsupported and likely doesn’t work at all. Have we learned from these > mistakes? Yes. Anything that’s actively supported has a proper name. This > name is needed, btw, so that any machine can self-host, a nice feature of > the /usr/src system. ABI consists of the following elements: - OS - OS ABI version (major version number in FreeBSD) - instruction set - programming model (ILP32 or LP64) - byte order (little/big endian) These are almost orthogonal dimensions in the sense that almost any combination is possible. (A combination that isn't possible is a 32-bit instruction set with LP64.) What you are asking for now is to combine two dimensions into one and combination in this case means multiplication so if you have 3 instruction sets and 2 programming models, the combined dimension needs 6 different values. You need to make the case for why you think this is a good idea. For the past 20 years we got away with this because on every installation of FreeBSD we only used one programming model at a time. This is still the case for byte order of course. What I'm saying is to keep the option open for installations with multiple programming models, where most binaries could use ILP32 and only the ones that actually need a 64-bit address space use LP64. You query the instruction set using uname and the programming models using getconf. I suppose you could replace the "x86" in the pkg scheme with i386/amd64, but then you'd still be talking about i386:32, amd64:32 and amd64:64 instead of x86:32, x86:x32 and x86:64. ___ 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: r266645 - head/usr.bin/netstat
On Sun, 25 May 2014, Bryan Drewery wrote: On 2014-05-25 02:41, Allan Jude wrote: ... Log: Document the new -R flag of netstat(1) introduced in r266448 that tracks the flowid for each socket. Modified: head/usr.bin/netstat/netstat.1 == --- head/usr.bin/netstat/netstat.1 Sun May 25 06:42:43 2014 (r266644) +++ head/usr.bin/netstat/netstat.1 Sun May 25 07:41:12 2014 (r266645) @@ -45,7 +45,7 @@ depending on the options for the informa Looks like you forgot to bump .Dd .It Xo .Bk -words .Nm -.Op Fl 46AaLnSTWx +.Op Fl 46AaLnSTWxR Also, the alphabet. @@ -84,6 +84,9 @@ but show ports symbolically. If .Fl x is present, display socket buffer and tcp timer statistics for each internet socket. +If +.Fl R +is present, display the flowid and flowtype for each internet socket. When .Fl T is present, display information from the TCP control block, including Here -T was already unsorted. The syntax is very complicated and most of the options are not described in a single list, but they are mostly sorted in sub-lists starting with the ones in the synopsis. (The man page is unusually organized and doesn't actually have a SYNOPSIS section. Instead, the synopsis lines are placed in the DESCRIPTION section. I refer to the collection of them as "the synopsis" although there is no actual synopsis). @@ -367,6 +370,11 @@ and display them symbolically. .It Fl W In certain displays, avoid truncating addresses even if this causes some fields to overflow. +.It Fl R +Display the flowid and flowtype for each socket. +flowid is a 32 bit hardware specific identifier for each flow. +flowtype defines which protocol fields are hashed to produce the id. +A complete listing is available in sys/mbuf.h under M_HASHTYPE_* .El .Pp The default display, for active sockets, shows the local -R seems to have only been added to the synopsis for 1 of the displays. If that is correct, then its description doesn't belong here, even if it were sorted (this sub-list was sorted). This is the general list for options that have "the [sic] general meaning". Many of the options in this list are not really general. I think only -M and -N are really general. They are given for all except 4 displays in the synopsis. I think this is a bug in 3 or 4 of these displays in the synopsis. The others (-46fnW and now -R) are not present in most of the displays in the synopsis. I think the bugs for this are distributed. Only the above description for -W is fuzzy enough to be correct (it says "for certain displays"). Actually, this makes it is not even wrong. It is documented for just 2 of the displays, and the details of what it does are given there. PS: oops: the detals are more complicated. The above is generic for "addresses", while the details only mention "interfaces". -W seems to affect both if and only it affects either, but it sometimes affects neither when it is documented to affect "interfaces". Getopt parsing in netstat would have to be just as complicated as the synopsis to restrict to only the documented combinations. It actually seems to allow all combinations except -x with -T. Then netstat does whatever it does with the undocumented/nonsensical combinations. netstat's usage message tries to duplicate all of the synopsis lines. I didn't notice if -R was already up to date or unsorted in the usage message. Comparing the previous versions of them shows only minor bugs: @--- netstat.synopsis 2014-05-26 05:36:41.306465000 + @+++ netstat.usage 2014-05-26 05:35:06.234067000 + @@@ -1,2 +1,2 @@ @- netstat [-46AaLnSTWx] [-f protocol_family | -p protocol] [-M core] @- [-N system] @+usage netstat [-46AaLnSTWx] [-f protocol_family | -p protocol] [-M core] @+ [-M core] [-N system] The usage message is split gratuitously inconsistently. Unfortunately, lining up after printing "usage: " gives a 7-column indentation, while man gives a 5-column identation. (I used diff -w to avoid seeing most such differences.) Despite this, there are enough columns to preserve the line splitting here. @@@ -4,4 +4,5 @@ @- netstat -w wait [-I interface] [-d] [-M core] [-N system] [-q howmany] @- netstat -s [-s] [-46z] [-f protocol_family | -p protocol] [-M core] @- [-N system] @- netstat -i | -I interface -s [-46] [-f protocol_family | -p protocol] @+ [-M core] [-N system] @+ netstat -w wait [-I interface] [-46d] [-M core] [-N system] [-q howmany] @+ netstat -s [-s] [-46z] [-f protocol_family | -p protocol] @+ [-M core] [-N system] @+ netstat -i | -I interface [-46s] [-f protocol_family | -p protocol] The synopsis for -w is missing -46. The synopsis for -i says -s [-46] but the usage says [-46s]. It is unclear where the bug is. The line before this says -s [-s]. There the second -s is certainly correct -- it amplifies the effect of th
