svn commit: r252022 - head/usr.sbin/bsdconfig/share/media
Author: dteske
Date: Thu Jun 20 07:29:42 2013
New Revision: 252022
URL: http://svnweb.freebsd.org/changeset/base/252022
Log:
Fix a code typo in a case-statement match expression that prevented IPv6
URLs with port designator from working properly (e.g. http://[::1]:80/).
Modified:
head/usr.sbin/bsdconfig/share/media/httpproxy.subr
Modified: head/usr.sbin/bsdconfig/share/media/httpproxy.subr
==
--- head/usr.sbin/bsdconfig/share/media/httpproxy.subr Thu Jun 20 07:23:04
2013(r252021)
+++ head/usr.sbin/bsdconfig/share/media/httpproxy.subr Thu Jun 20 07:29:42
2013(r252022)
@@ -81,7 +81,7 @@ f_media_set_http_proxy()
hostname=${hostname#\[}
hostname=${hostname%\]}
;;
- [*]:)
+ [*]:*)
hostname=${hostname#\[}
port=${hostname#*\]:}
port=${port%%[!0-9]*}
___
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: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On 20 Jun 2013, at 00:10, Warner Losh i...@bsdimp.com wrote: - FreeBSD developers, who are probably okay with installing a port, but would prefer a version that didn't depend on kitchen/sink? - Users, who wish to be able to update the source tree and then either build world, or build some optional parts that are not part of the default install? - Some other category of svn consumer? I think having a definitive statement as to the intention of svnlite would help frame the discussion in a more productive format. How do I roll back to last week with FreeBSD-update? Which of the classes of user that I outlined do you think wants to be able to do that? As a FreeBSD user, I never felt the desire to do that, but maybe I was unusual. As a FreeBSD developer, I don't mind installing the svn port to be able to do it (although I'd prefer a more lightweight port). I would expect the same to apply to the sort of engaged user who is willing to bisect to track down a bug. David signature.asc Description: Message signed with OpenPGP using GPGMail
svn commit: r252026 - in head/sys: netinet netinet6 netipsec
Author: ae
Date: Thu Jun 20 09:55:53 2013
New Revision: 252026
URL: http://svnweb.freebsd.org/changeset/base/252026
Log:
Use IPSECSTAT_INC() and IPSEC6STAT_INC() macros for ipsec statistics
accounting.
MFC after:2 weeks
Modified:
head/sys/netinet/tcp_input.c
head/sys/netinet/udp_usrreq.c
head/sys/netinet6/ip6_forward.c
head/sys/netinet6/raw_ip6.c
head/sys/netinet6/udp6_usrreq.c
head/sys/netipsec/ipsec.c
head/sys/netipsec/ipsec.h
head/sys/netipsec/ipsec6.h
head/sys/netipsec/ipsec_mbuf.c
head/sys/netipsec/ipsec_output.c
Modified: head/sys/netinet/tcp_input.c
==
--- head/sys/netinet/tcp_input.cThu Jun 20 08:19:29 2013
(r252025)
+++ head/sys/netinet/tcp_input.cThu Jun 20 09:55:53 2013
(r252026)
@@ -950,12 +950,12 @@ findpcb:
#ifdef IPSEC
#ifdef INET6
if (isipv6 ipsec6_in_reject(m, inp)) {
- V_ipsec6stat.in_polvio++;
+ IPSEC6STAT_INC(in_polvio);
goto dropunlock;
} else
#endif /* INET6 */
if (ipsec4_in_reject(m, inp) != 0) {
- V_ipsec4stat.in_polvio++;
+ IPSECSTAT_INC(in_polvio);
goto dropunlock;
}
#endif /* IPSEC */
Modified: head/sys/netinet/udp_usrreq.c
==
--- head/sys/netinet/udp_usrreq.c Thu Jun 20 08:19:29 2013
(r252025)
+++ head/sys/netinet/udp_usrreq.c Thu Jun 20 09:55:53 2013
(r252026)
@@ -279,7 +279,7 @@ udp_append(struct inpcb *inp, struct ip
/* Check AH/ESP integrity. */
if (ipsec4_in_reject(n, inp)) {
m_freem(n);
- V_ipsec4stat.in_polvio++;
+ IPSECSTAT_INC(in_polvio);
return;
}
#ifdef IPSEC_NAT_T
@@ -1291,7 +1291,7 @@ udp4_espdecap(struct inpcb *inp, struct
if (minlen m-m_pkthdr.len)
minlen = m-m_pkthdr.len;
if ((m = m_pullup(m, minlen)) == NULL) {
- V_ipsec4stat.in_inval++;
+ IPSECSTAT_INC(in_inval);
return (NULL); /* Bypass caller processing. */
}
data = mtod(m, caddr_t);/* Points to ip header. */
@@ -1331,7 +1331,7 @@ udp4_espdecap(struct inpcb *inp, struct
uint32_t spi;
if (payload = sizeof(struct esp)) {
- V_ipsec4stat.in_inval++;
+ IPSECSTAT_INC(in_inval);
m_freem(m);
return (NULL); /* Discard. */
}
@@ -1352,7 +1352,7 @@ udp4_espdecap(struct inpcb *inp, struct
tag = m_tag_get(PACKET_TAG_IPSEC_NAT_T_PORTS,
2 * sizeof(uint16_t), M_NOWAIT);
if (tag == NULL) {
- V_ipsec4stat.in_nomem++;
+ IPSECSTAT_INC(in_nomem);
m_freem(m);
return (NULL); /* Discard. */
}
Modified: head/sys/netinet6/ip6_forward.c
==
--- head/sys/netinet6/ip6_forward.c Thu Jun 20 08:19:29 2013
(r252025)
+++ head/sys/netinet6/ip6_forward.c Thu Jun 20 09:55:53 2013
(r252026)
@@ -120,7 +120,7 @@ ip6_forward(struct mbuf *m, int srcrt)
* before forwarding packet actually.
*/
if (ipsec6_in_reject(m, NULL)) {
- V_ipsec6stat.in_polvio++;
+ IPSEC6STAT_INC(in_polvio);
m_freem(m);
return;
}
@@ -182,7 +182,7 @@ ip6_forward(struct mbuf *m, int srcrt)
sp = ipsec_getpolicybyaddr(m, IPSEC_DIR_OUTBOUND,
IP_FORWARDING, error);
if (sp == NULL) {
- V_ipsec6stat.out_inval++;
+ IPSEC6STAT_INC(out_inval);
IP6STAT_INC(ip6s_cantforward);
if (mcopy) {
#if 0
@@ -203,7 +203,7 @@ ip6_forward(struct mbuf *m, int srcrt)
/*
* This packet is just discarded.
*/
- V_ipsec6stat.out_polvio++;
+ IPSEC6STAT_INC(out_polvio);
IP6STAT_INC(ip6s_cantforward);
KEY_FREESP(sp);
if (mcopy) {
Modified: head/sys/netinet6/raw_ip6.c
==
--- head/sys/netinet6/raw_ip6.c Thu Jun 20 08:19:29 2013(r252025)
+++ head/sys/netinet6/raw_ip6.c Thu Jun 20 09:55:53 2013(r252026)
@@ -263,7 +263,7 @@ rip6_input(struct mbuf **mp, int *offp,
*/
if (n ipsec6_in_reject(n, last)) {
m_freem(n);
- V_ipsec6stat.in_polvio++;
+ IPSEC6STAT_INC(in_polvio);
/* Do not inject data into pcb. */
} else
#endif /*
svn commit: r252028 - head/sys/netipsec
Author: ae
Date: Thu Jun 20 11:44:16 2013
New Revision: 252028
URL: http://svnweb.freebsd.org/changeset/base/252028
Log:
Use corresponding macros to update statistics for AH, ESP, IPIP, IPCOMP,
PFKEY.
MFC after:2 weeks
Modified:
head/sys/netipsec/ah_var.h
head/sys/netipsec/esp_var.h
head/sys/netipsec/ipcomp_var.h
head/sys/netipsec/ipip_var.h
head/sys/netipsec/ipsec_input.c
head/sys/netipsec/ipsec_output.c
head/sys/netipsec/key.c
head/sys/netipsec/keysock.c
head/sys/netipsec/keysock.h
head/sys/netipsec/xform_ah.c
head/sys/netipsec/xform_esp.c
head/sys/netipsec/xform_ipcomp.c
head/sys/netipsec/xform_ipip.c
Modified: head/sys/netipsec/ah_var.h
==
--- head/sys/netipsec/ah_var.h Thu Jun 20 11:24:38 2013(r252027)
+++ head/sys/netipsec/ah_var.h Thu Jun 20 11:44:16 2013(r252028)
@@ -75,6 +75,8 @@ VNET_DECLARE(int, ah_enable);
VNET_DECLARE(int, ah_cleartos);
VNET_DECLARE(struct ahstat, ahstat);
+#defineAHSTAT_ADD(name, val) V_ahstat.name += (val)
+#defineAHSTAT_INC(name)AHSTAT_ADD(name, 1)
#defineV_ah_enable VNET(ah_enable)
#defineV_ah_cleartos VNET(ah_cleartos)
#defineV_ahstatVNET(ahstat)
Modified: head/sys/netipsec/esp_var.h
==
--- head/sys/netipsec/esp_var.h Thu Jun 20 11:24:38 2013(r252027)
+++ head/sys/netipsec/esp_var.h Thu Jun 20 11:44:16 2013(r252028)
@@ -75,6 +75,8 @@ struct espstat {
VNET_DECLARE(int, esp_enable);
VNET_DECLARE(struct espstat, espstat);
+#defineESPSTAT_ADD(name, val) V_espstat.name += (val)
+#defineESPSTAT_INC(name) ESPSTAT_ADD(name, 1)
#defineV_esp_enableVNET(esp_enable)
#defineV_espstat VNET(espstat)
#endif /* _KERNEL */
Modified: head/sys/netipsec/ipcomp_var.h
==
--- head/sys/netipsec/ipcomp_var.h Thu Jun 20 11:24:38 2013
(r252027)
+++ head/sys/netipsec/ipcomp_var.h Thu Jun 20 11:44:16 2013
(r252028)
@@ -68,6 +68,8 @@ struct ipcompstat {
VNET_DECLARE(int, ipcomp_enable);
VNET_DECLARE(struct ipcompstat, ipcompstat);
+#defineIPCOMPSTAT_ADD(name, val) V_ipcompstat.name += (val)
+#defineIPCOMPSTAT_INC(name)IPCOMPSTAT_ADD(name, 1)
#defineV_ipcomp_enable VNET(ipcomp_enable)
#defineV_ipcompstatVNET(ipcompstat)
#endif /* _KERNEL */
Modified: head/sys/netipsec/ipip_var.h
==
--- head/sys/netipsec/ipip_var.hThu Jun 20 11:24:38 2013
(r252027)
+++ head/sys/netipsec/ipip_var.hThu Jun 20 11:44:16 2013
(r252028)
@@ -62,6 +62,8 @@ struct ipipstat
VNET_DECLARE(int, ipip_allow);
VNET_DECLARE(struct ipipstat, ipipstat);
+#defineIPIPSTAT_ADD(name, val) V_ipipstat.name += (val)
+#defineIPIPSTAT_INC(name) IPIPSTAT_ADD(name, 1)
#defineV_ipip_allowVNET(ipip_allow)
#defineV_ipipstat VNET(ipipstat)
#endif /* _KERNEL */
Modified: head/sys/netipsec/ipsec_input.c
==
--- head/sys/netipsec/ipsec_input.c Thu Jun 20 11:24:38 2013
(r252027)
+++ head/sys/netipsec/ipsec_input.c Thu Jun 20 11:44:16 2013
(r252028)
@@ -99,8 +99,14 @@
#endif
-#define IPSEC_ISTAT(p,x,y,z) ((p) == IPPROTO_ESP ? (x)++ : \
- (p) == IPPROTO_AH ? (y)++ : (z)++)
+#defineIPSEC_ISTAT(proto, name)do {\
+ if ((proto) == IPPROTO_ESP) \
+ ESPSTAT_INC(esps_##name); \
+ else if ((proto) == IPPROTO_AH) \
+ AHSTAT_INC(ahs_##name); \
+ else\
+ IPCOMPSTAT_INC(ipcomps_##name); \
+} while (0)
#ifdef INET
static void ipsec4_common_ctlinput(int, struct sockaddr *, void *, int);
@@ -125,8 +131,7 @@ ipsec_common_input(struct mbuf *m, int s
#endif
#endif
- IPSEC_ISTAT(sproto, V_espstat.esps_input, V_ahstat.ahs_input,
- V_ipcompstat.ipcomps_input);
+ IPSEC_ISTAT(sproto, input);
IPSEC_ASSERT(m != NULL, (null packet));
@@ -138,15 +143,13 @@ ipsec_common_input(struct mbuf *m, int s
(sproto == IPPROTO_AH !V_ah_enable) ||
(sproto == IPPROTO_IPCOMP !V_ipcomp_enable)) {
m_freem(m);
- IPSEC_ISTAT(sproto, V_espstat.esps_pdrops, V_ahstat.ahs_pdrops,
- V_ipcompstat.ipcomps_pdrops);
+ IPSEC_ISTAT(sproto, pdrops);
return EOPNOTSUPP;
}
if (m-m_pkthdr.len - skip 2 * sizeof (u_int32_t)) {
m_freem(m);
-
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On 6/20/13 4:40 PM, David Chisnall wrote: On 20 Jun 2013, at 00:10, Warner Losh i...@bsdimp.com wrote: - FreeBSD developers, who are probably okay with installing a port, but would prefer a version that didn't depend on kitchen/sink? - Users, who wish to be able to update the source tree and then either build world, or build some optional parts that are not part of the default install? - Some other category of svn consumer? I think having a definitive statement as to the intention of svnlite would help frame the discussion in a more productive format. How do I roll back to last week with FreeBSD-update? Which of the classes of user that I outlined do you think wants to be able to do that? As a FreeBSD user, I never felt the desire to do that, but maybe I was unusual. As a FreeBSD developer, I don't mind installing the svn port to be able to do it (although I'd prefer a more lightweight port). I would expect the same to apply to the sort of engaged user who is willing to bisect to track down a bug. bug reporter: I have this new bug... developer:Can you try rolling back to xyzzy bug reporter: Yeah that fixes it.. developer: Ok.. patch will follow David ___ 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: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On 6/20/13 9:13 PM, David Chisnall wrote: On 20 Jun 2013, at 14:09, Julian Elischer jul...@freebsd.org wrote: Which of the classes of user that I outlined do you think wants to be able to do that? As a FreeBSD user, I never felt the desire to do that, but maybe I was unusual. As a FreeBSD developer, I don't mind installing the svn port to be able to do it (although I'd prefer a more lightweight port). I would expect the same to apply to the sort of engaged user who is willing to bisect to track down a bug. bug reporter: I have this new bug... developer:Can you try rolling back to xyzzy bug reporter: Yeah that fixes it.. developer: Ok.. patch will follow And do you think that the sort of user who is sufficiently engaged with the project to do this is the sort of user who would not be willing to do so if it meant installing the subversion port? If so, then there is a clear case for svnlite. I think that it lowers the barrier.. once you start bringing ports into the picture you start running the risk of port revision hell. David ___ 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: r252032 - head/sys/amd64/include
Author: kib Date: Thu Jun 20 14:30:04 2013 New Revision: 252032 URL: http://svnweb.freebsd.org/changeset/base/252032 Log: Allow immediate operand. Sponsored by: The FreeBSD Foundation Modified: head/sys/amd64/include/counter.h Modified: head/sys/amd64/include/counter.h == --- head/sys/amd64/include/counter.hThu Jun 20 14:20:03 2013 (r252031) +++ head/sys/amd64/include/counter.hThu Jun 20 14:30:04 2013 (r252032) @@ -44,7 +44,7 @@ counter_u64_add(counter_u64_t c, int64_t __asm __volatile(addq\t%1,%%gs:(%0) : - : r ((char *)c - (char *)__pcpu[0]), r (inc) + : r ((char *)c - (char *)__pcpu[0]), ri (inc) : memory, cc); } ___ 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: r252033 - head/sbin/mdconfig
Author: hrs
Date: Thu Jun 20 14:30:16 2013
New Revision: 252033
URL: http://svnweb.freebsd.org/changeset/base/252033
Log:
- Add -f file support to listing mode (-l). When a -f option is
specified, only md(4) devices which have the specified file as backing
store are displayed.
- Use MD_NAME instead of md.
- Use _PATH_DEV instead of /dev/.
MFC after:1 week
Modified:
head/sbin/mdconfig/mdconfig.8
head/sbin/mdconfig/mdconfig.c
Modified: head/sbin/mdconfig/mdconfig.8
==
--- head/sbin/mdconfig/mdconfig.8 Thu Jun 20 14:30:04 2013
(r252032)
+++ head/sbin/mdconfig/mdconfig.8 Thu Jun 20 14:30:16 2013
(r252033)
@@ -41,7 +41,7 @@
.\
.\ $FreeBSD$
.\
-.Dd November 3, 2012
+.Dd June 20, 2013
.Dt MDCONFIG 8
.Os
.Sh NAME
@@ -72,6 +72,7 @@
.Fl l
.Op Fl n
.Op Fl v
+.Op Fl f Ar file
.Op Fl u Ar unit
.Nm
.Ar file
@@ -131,6 +132,19 @@ List configured devices.
If given with
.Fl u ,
display details about that particular device.
+If given with
+.Fl f Ar file ,
+display
+.Xr md 4
+device names of which
+.Ar file
+is used as the backing store.
+If both of
+.Fl u
+and
+.Fl f
+options are specified,
+display devices which match the two conditions.
If the
.Fl v
option is specified, show all details.
Modified: head/sbin/mdconfig/mdconfig.c
==
--- head/sbin/mdconfig/mdconfig.c Thu Jun 20 14:30:04 2013
(r252032)
+++ head/sbin/mdconfig/mdconfig.c Thu Jun 20 14:30:16 2013
(r252033)
@@ -47,6 +47,7 @@
#include inttypes.h
#include libgeom.h
#include libutil.h
+#include paths.h
#include stdarg.h
#include stdio.h
#include stdlib.h
@@ -59,9 +60,9 @@ static int nflag;
static void usage(void);
static void md_set_file(const char *);
-static int md_find(char *, const char *);
-static int md_query(char *name);
-static int md_list(char *units, int opt);
+static int md_find(const char *, const char *);
+static int md_query(const char *, const int, const char *);
+static int md_list(const char *, int, const char *);
static char *geom_config_get(struct gconf *g, const char *name);
static void md_prthumanval(char *length);
@@ -82,7 +83,7 @@ usage(void)
[-x sectors/track] [-y heads/cylinder]\n
mdconfig -d -u unit [-o [no]force]\n
mdconfig -r -u unit -s size [-o [no]force]\n
- mdconfig -l [-v] [-n] [-u unit]\n
+ mdconfig -l [-v] [-n] [-f file] [-u unit]\n
mdconfig file\n);
fprintf(stderr, \t\ttype = {malloc, vnode, swap}\n);
fprintf(stderr, \t\toption = {cluster, compress, reserve}\n);
@@ -215,7 +216,7 @@ main(int argc, char **argv)
errx(1, unknown suffix on -s argument);
break;
case 'u':
- if (!strncmp(optarg, /dev/, 5))
+ if (!strncmp(optarg, _PATH_DEV, 5))
optarg += 5;
if (!strncmp(optarg, MD_NAME, sizeof(MD_NAME) - 1))
optarg += sizeof(MD_NAME) - 1;
@@ -298,8 +299,8 @@ main(int argc, char **argv)
errx(1, -x can only be used with -a);
if (mdio.md_fwheads != 0)
errx(1, -y can only be used with -a);
- if (fflag != NULL)
- errx(1, -f can only be used with -a);
+ if (fflag != NULL action != LIST)
+ errx(1, -f can only be used with -a and -l);
if (tflag != NULL)
errx(1, -t can only be used with -a);
if (argc 0)
@@ -333,14 +334,14 @@ main(int argc, char **argv)
if (!kld_isloaded(g_md) kld_load(geom_md) == -1)
err(1, failed to load geom_md module);
- fd = open(/dev/ MDCTL_NAME, O_RDWR, 0);
+ fd = open(_PATH_DEV MDCTL_NAME, O_RDWR, 0);
if (fd 0)
- err(1, open(/dev/%s), MDCTL_NAME);
+ err(1, open(%s%s), _PATH_DEV, MDCTL_NAME);
if (action == ATTACH) {
i = ioctl(fd, MDIOCATTACH, mdio);
if (i 0)
- err(1, ioctl(/dev/%s), MDCTL_NAME);
+ err(1, ioctl(%s%s), _PATH_DEV, MDCTL_NAME);
if (mdio.md_options MD_AUTOUNIT)
printf(%s%d\n, nflag ? : MD_NAME, mdio.md_unit);
} else if (action == DETACH) {
@@ -348,22 +349,22 @@ main(int argc, char **argv)
errx(1, -d requires -u);
i = ioctl(fd, MDIOCDETACH, mdio);
if (i 0)
- err(1, ioctl(/dev/%s), MDCTL_NAME);
+ err(1, ioctl(%s%s), _PATH_DEV, MDCTL_NAME);
} else if (action == RESIZE) {
if (mdio.md_options MD_AUTOUNIT)
errx(1, -r requires -u);
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On 20 Jun 2013, at 14:09, Julian Elischer jul...@freebsd.org wrote: Which of the classes of user that I outlined do you think wants to be able to do that? As a FreeBSD user, I never felt the desire to do that, but maybe I was unusual. As a FreeBSD developer, I don't mind installing the svn port to be able to do it (although I'd prefer a more lightweight port). I would expect the same to apply to the sort of engaged user who is willing to bisect to track down a bug. bug reporter: I have this new bug... developer:Can you try rolling back to xyzzy bug reporter: Yeah that fixes it.. developer: Ok.. patch will follow And do you think that the sort of user who is sufficiently engaged with the project to do this is the sort of user who would not be willing to do so if it meant installing the subversion port? If so, then there is a clear case for svnlite. David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On 20/06/2013, at 23:03, Julian Elischer jul...@freebsd.org wrote: And do you think that the sort of user who is sufficiently engaged with the project to do this is the sort of user who would not be willing to do so if it meant installing the subversion port? If so, then there is a clear case for svnlite. I think that it lowers the barrier.. once you start bringing ports into the picture you start running the risk of port revision hell. If there is a statically linked port corresponding package then the barrier is almost as low, but has a few other advantages that other people have listed. That approach has a small footprint (binary + man page), is always up to date (so the VCS infrastructure is not tied to the earliest version of SVN) and doesn't have any dependencies. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On Thu, Jun 20, 2013 at 09:33:52PM +0800, Julian Elischer wrote: On 6/20/13 9:13 PM, David Chisnall wrote: On 20 Jun 2013, at 14:09, Julian Elischer jul...@freebsd.org wrote: Which of the classes of user that I outlined do you think wants to be able to do that? As a FreeBSD user, I never felt the desire to do that, but maybe I was unusual. As a FreeBSD developer, I don't mind installing the svn port to be able to do it (although I'd prefer a more lightweight port). I would expect the same to apply to the sort of engaged user who is willing to bisect to track down a bug. bug reporter: I have this new bug... developer:Can you try rolling back to xyzzy bug reporter: Yeah that fixes it.. developer: Ok.. patch will follow And do you think that the sort of user who is sufficiently engaged with the project to do this is the sort of user who would not be willing to do so if it meant installing the subversion port? If so, then there is a clear case for svnlite. I think that it lowers the barrier.. once you start bringing ports into the picture you start running the risk of port revision hell. Once everything will be back to normal $ pkg install subversion I don't see much revision hell in that (bonus it will bring to python and no perl). regards, Bapt pgpDF_p4yWMQj.pgp Description: PGP signature
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On Thu, Jun 20, 2013 at 11:49:13PM +0930, Daniel O'Connor wrote: On 20/06/2013, at 23:03, Julian Elischer jul...@freebsd.org wrote: And do you think that the sort of user who is sufficiently engaged with the project to do this is the sort of user who would not be willing to do so if it meant installing the subversion port? If so, then there is a clear case for svnlite. I think that it lowers the barrier.. once you start bringing ports into the picture you start running the risk of port revision hell. If there is a statically linked port corresponding package then the barrier is almost as low, but has a few other advantages that other people have listed. That approach has a small footprint (binary + man page), is always up to date (so the VCS infrastructure is not tied to the earliest version of SVN) and doesn't have any dependencies. svnlite (1.8.0-rc3 in base system) and subversion (1.7.10 from ports) are not interoperable, they create incompatible repositories (at least by default). Not a problem for me personally, I use git mirrors, just my 5 cents. Details below. Here the freebsd repo checked out by subversion port svn info Path: . Working Copy Root Path: /usr/src/freebsd-head.svn URL: http://svn.freebsd.org/base/head Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 245668 Node Kind: directory Schedule: normal Last Changed Author: joel Last Changed Rev: 245667 Last Changed Date: 2013-01-19 11:07:05 +0400 (Sat, 19 Jan 2013) Now trying to work with svnlite: svnlite info svn: E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at '/usr/src/freebsd-head.svn' is too old (format 29) to work with client version '1.8.0-rc3 (Release Candidate 3)' (expects format 31). You need to upgrade the working copy first. Creating repo with svnlite and trying to run svn on it: svnlite co http://svn.freebsd.org/base/head/bin/cat Acat/Makefile Acat/cat.1 Acat/cat.c Checked out revision 252033. cd cat svnlite info Path: . Working Copy Root Path: /tmp/src-test/cat URL: http://svn.freebsd.org/base/head/bin/cat Relative URL: ^/head/bin/cat Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 252033 Node Kind: directory Schedule: normal Last Changed Author: eadler Last Changed Rev: 249804 Last Changed Date: 2013-04-23 17:03:11 +0400 (Tue, 23 Apr 2013) svn info svn: E155021: This client is too old to work with the working copy at '/tmp/src-test/cat' (format 31). You need to get a newer Subversion client. For more details, see http://subversion.apache.org/faq.html#working-copy-format-change ___ 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: r252036 - head/sbin/mdconfig
Author: hrs
Date: Thu Jun 20 17:01:02 2013
New Revision: 252036
URL: http://svnweb.freebsd.org/changeset/base/252036
Log:
eturn -1 when the specified backing store file is not found in the md
device list.
MFC after:1 week
Modified:
head/sbin/mdconfig/mdconfig.c
Modified: head/sbin/mdconfig/mdconfig.c
==
--- head/sbin/mdconfig/mdconfig.c Thu Jun 20 16:51:25 2013
(r252035)
+++ head/sbin/mdconfig/mdconfig.c Thu Jun 20 17:01:02 2013
(r252036)
@@ -362,7 +362,7 @@ main(int argc, char **argv)
* Listing all devices. This is why we pass NULL
* together with OPT_LIST.
*/
- md_list(NULL, OPT_LIST | vflag, fflag);
+ return (md_list(NULL, OPT_LIST | vflag, fflag));
} else
return (md_query(uflag, vflag, fflag));
} else
@@ -408,7 +408,7 @@ md_list(const char *units, int opt, cons
struct ggeom *gg;
struct gclass *gcl;
void *sq;
- int retcode, found;
+ int retcode, ffound, ufound;
char *type, *file, *length;
type = file = length = NULL;
@@ -423,7 +423,7 @@ md_list(const char *units, int opt, cons
if (sq == NULL)
return (-1);
- found = 0;
+ ffound = ufound = 0;
while ((gsp = geom_stats_snapshot_next(sq)) != NULL) {
gid = geom_lookupid(gm, gsp-id);
if (gid == NULL)
@@ -439,7 +439,7 @@ md_list(const char *units, int opt, cons
if (retcode != 1)
continue;
else
- found = 1;
+ ufound = 1;
}
gc = pp-lg_config;
type = geom_config_get(gc, type);
@@ -448,6 +448,8 @@ md_list(const char *units, int opt, cons
if (fflag != NULL
strcmp(fflag, file) != 0)
continue;
+ else
+ ffound = 1;
}
if (nflag strncmp(pp-lg_name, MD_NAME, 2) == 0)
printf(%s, pp-lg_name + 2);
@@ -476,7 +478,9 @@ md_list(const char *units, int opt, cons
printf(\n);
/* XXX: Check if it's enough to clean everything. */
geom_stats_snapshot_free(sq);
- if ((opt OPT_UNIT) found)
+ if (((opt OPT_UNIT) (fflag == NULL) ufound) ||
+ ((opt OPT_UNIT) == 0 (fflag != NULL) ffound) ||
+ ((opt OPT_UNIT) (fflag != NULL) ufound ffound))
return (0);
else
return (-1);
___
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: r252037 - head/share/man/man9
Author: jhb Date: Thu Jun 20 17:26:25 2013 New Revision: 252037 URL: http://svnweb.freebsd.org/changeset/base/252037 Log: Document RA_RECURSED and RA_NOTRECURSED. MFC after:3 days Modified: head/share/man/man9/rwlock.9 Modified: head/share/man/man9/rwlock.9 == --- head/share/man/man9/rwlock.9Thu Jun 20 17:01:02 2013 (r252036) +++ head/share/man/man9/rwlock.9Thu Jun 20 17:26:25 2013 (r252037) @@ -24,7 +24,7 @@ .\ .\ $FreeBSD$ .\ -.Dd November 16, 2011 +.Dd June 20, 2013 .Dt RWLOCK 9 .Os .Sh NAME @@ -254,7 +254,7 @@ with and .Cd options INVARIANT_SUPPORT , the kernel will panic. -Currently the following assertions are supported: +Currently the following base assertions are supported: .Bl -tag -width .Dv RA_UNLOCKED .It Dv RA_LOCKED Assert that current thread holds either a shared or exclusive lock @@ -270,6 +270,20 @@ Assert that current thread holds an excl Assert that current thread holds neither a shared nor exclusive lock of .Fa rw . .El +.Pp +In addition, one of the following optional flags may be specified with +.Dv RA_LOCKED , +.Dv RA_RLOCKED , +or +.Dv RA_WLOCKED : +.Bl -tag -width .Dv RA_NOTRECURSED +.It Dv RA_RECURSED +Assert that the current thread holds a recursive lock of +.Fa rw . +.It Dv RA_NOTRECURSED +Assert that the current thread does not hold a recursive lock of +.Fa rw . +.El .El .Sh SEE ALSO .Xr locking 9 , ___ 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: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On Thursday, June 20, 2013 9:13:51 am David Chisnall wrote: On 20 Jun 2013, at 14:09, Julian Elischer jul...@freebsd.org wrote: Which of the classes of user that I outlined do you think wants to be able to do that? As a FreeBSD user, I never felt the desire to do that, but maybe I was unusual. As a FreeBSD developer, I don't mind installing the svn port to be able to do it (although I'd prefer a more lightweight port). I would expect the same to apply to the sort of engaged user who is willing to bisect to track down a bug. bug reporter: I have this new bug... developer:Can you try rolling back to xyzzy bug reporter: Yeah that fixes it.. developer: Ok.. patch will follow And do you think that the sort of user who is sufficiently engaged with the project to do this is the sort of user who would not be willing to do so if it meant installing the subversion port? If so, then there is a clear case for svnlite. I only mean that this use-case is required and this is why you can't use portsnap for src updates. Especially because when some user does an update they aren't going to want to switch to some other tool so they can start bisecting to find an offending revision. Many of our users are willing to do the bisection thing, and it was a commonly used feature of cvsup to do this via timestamps. In terms of whether or not the src updating tool live in ports: cvsup used to only be available as a port, and many users really did like having csup come into the base system so they did not need a port for this. The rather broad support for svnup among our users on stable@, etc. should be a good clue that many of them would greatly prefer a tool in the base system for tracking source rather than installing a port, esp. a port with the large number of dependencies that svn has. -- John Baldwin ___ 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: r252039 - in head/contrib: gcc llvm/lib/CodeGen
Author: dim
Date: Thu Jun 20 18:25:10 2013
New Revision: 252039
URL: http://svnweb.freebsd.org/changeset/base/252039
Log:
Pull in r183984 from llvm trunk:
Make PrologEpilogInserter save/restore all callee saved registers in
functions which call __builtin_unwind_init()
__builtin_unwind_init() is an undocumented gcc intrinsic which has
this effect, and is used in libgcc_eh.
Goes part of the way toward fixing PR8541.
This obsoletes the ugly hack to libgcc's unwind code from r245272, and
should also work for other arches, so revert the hack too.
Modified:
head/contrib/gcc/unwind-dw2.c
head/contrib/llvm/lib/CodeGen/PrologEpilogInserter.cpp
Modified: head/contrib/gcc/unwind-dw2.c
==
--- head/contrib/gcc/unwind-dw2.c Thu Jun 20 17:45:29 2013
(r252038)
+++ head/contrib/gcc/unwind-dw2.c Thu Jun 20 18:25:10 2013
(r252039)
@@ -1438,17 +1438,6 @@ uw_init_context_1 (struct _Unwind_Contex
context-ra = __builtin_extract_return_addr (outer_ra);
}
-#if defined(__clang__) defined(__amd64__)
-/* Some versions of clang don't save and restore all callee registers, if a
- __builtin_eh_return() intrinsic is used in a function. This is particularly
- bad on amd64. For now, use the following ugly hack to force it to assume
- those registers are clobbered, when invoking __builtin_eh_return(), so it
- will emit code to save and restore them. */
-#define CLOBBER_REGS_HACK \
- __asm __volatile( : : : r15, r14, r13, r12, rbx, rdx, rax);
-#else
-#define CLOBBER_REGS_HACK
-#endif /* __clang__ */
/* Install TARGET into CURRENT so that we can return to it. This is a
macro because __builtin_eh_return must be invoked in the context of
@@ -1459,7 +1448,6 @@ uw_init_context_1 (struct _Unwind_Contex
{ \
long offset = uw_install_context_1 ((CURRENT), (TARGET));
\
void *handler = __builtin_frob_return_addr ((TARGET)-ra);\
- CLOBBER_REGS_HACK
\
__builtin_eh_return (offset, handler);\
} \
while (0)
Modified: head/contrib/llvm/lib/CodeGen/PrologEpilogInserter.cpp
==
--- head/contrib/llvm/lib/CodeGen/PrologEpilogInserter.cpp Thu Jun 20
17:45:29 2013(r252038)
+++ head/contrib/llvm/lib/CodeGen/PrologEpilogInserter.cpp Thu Jun 20
18:25:10 2013(r252039)
@@ -29,6 +29,7 @@
#include llvm/CodeGen/MachineFrameInfo.h
#include llvm/CodeGen/MachineInstr.h
#include llvm/CodeGen/MachineLoopInfo.h
+#include llvm/CodeGen/MachineModuleInfo.h
#include llvm/CodeGen/MachineRegisterInfo.h
#include llvm/CodeGen/RegisterScavenging.h
#include llvm/IR/InlineAsm.h
@@ -214,7 +215,8 @@ void PEI::calculateCalleeSavedRegisters(
std::vectorCalleeSavedInfo CSI;
for (unsigned i = 0; CSRegs[i]; ++i) {
unsigned Reg = CSRegs[i];
-if (F.getRegInfo().isPhysRegUsed(Reg)) {
+// Functions which call __builtin_unwind_init get all their registers
saved.
+if (F.getRegInfo().isPhysRegUsed(Reg) || F.getMMI().callsUnwindInit()) {
// If the reg is modified, save it!
CSI.push_back(CalleeSavedInfo(Reg));
}
___
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: r252040 - head/sys/vm
Author: jeff
Date: Thu Jun 20 19:08:12 2013
New Revision: 252040
URL: http://svnweb.freebsd.org/changeset/base/252040
Log:
- Add a per-zone lock for zones without kegs.
- Be more explicit about zone vs keg locking. This functionally changes
almost nothing.
- Add a size parameter to uma_zcache_create() so we can size the buckets.
- Pass the zone to bucket_alloc() so it can modify allocation flags
as appropriate.
- Fix a bug in zone_alloc_bucket() where I missed an address of operator
in a failure case. (Found by pho)
Sponsored by: EMC / Isilon Storage Division
Modified:
head/sys/vm/uma.h
head/sys/vm/uma_core.c
head/sys/vm/uma_dbg.c
head/sys/vm/uma_int.h
Modified: head/sys/vm/uma.h
==
--- head/sys/vm/uma.h Thu Jun 20 18:25:10 2013(r252039)
+++ head/sys/vm/uma.h Thu Jun 20 19:08:12 2013(r252040)
@@ -234,7 +234,7 @@ int uma_zsecond_add(uma_zone_t zone, uma
* zones. The 'arg' parameter is passed to import/release and is caller
* specific.
*/
-uma_zone_t uma_zcache_create(char *name, uma_ctor ctor, uma_dtor dtor,
+uma_zone_t uma_zcache_create(char *name, int size, uma_ctor ctor, uma_dtor
dtor,
uma_init zinit, uma_fini zfini, uma_import zimport,
uma_release zrelease, void *arg, int flags);
Modified: head/sys/vm/uma_core.c
==
--- head/sys/vm/uma_core.c Thu Jun 20 18:25:10 2013(r252039)
+++ head/sys/vm/uma_core.c Thu Jun 20 19:08:12 2013(r252040)
@@ -246,8 +246,8 @@ static void *zone_alloc_item(uma_zone_t,
static void zone_free_item(uma_zone_t, void *, void *, enum zfreeskip);
static void bucket_enable(void);
static void bucket_init(void);
-static uma_bucket_t bucket_alloc(int, int);
-static void bucket_free(uma_bucket_t);
+static uma_bucket_t bucket_alloc(uma_zone_t zone, int);
+static void bucket_free(uma_zone_t zone, uma_bucket_t);
static void bucket_zone_drain(void);
static uma_bucket_t zone_alloc_bucket(uma_zone_t zone, int flags);
static uma_slab_t zone_fetch_slab(uma_zone_t zone, uma_keg_t last, int flags);
@@ -256,8 +256,6 @@ static void *slab_alloc_item(uma_keg_t k
static void slab_free_item(uma_keg_t keg, uma_slab_t slab, void *item);
static uma_keg_t uma_kcreate(uma_zone_t zone, size_t size, uma_init uminit,
uma_fini fini, int align, uint32_t flags);
-static inline void zone_relock(uma_zone_t zone, uma_keg_t keg);
-static inline void keg_relock(uma_keg_t keg, uma_zone_t zone);
static int zone_import(uma_zone_t zone, void **bucket, int max, int flags);
static void zone_release(uma_zone_t zone, void **bucket, int cnt);
@@ -352,7 +350,7 @@ bucket_select(int size)
}
static uma_bucket_t
-bucket_alloc(int entries, int bflags)
+bucket_alloc(uma_zone_t zone, int flags)
{
struct uma_bucket_zone *ubz;
uma_bucket_t bucket;
@@ -366,8 +364,10 @@ bucket_alloc(int entries, int bflags)
if (bucketdisable)
return (NULL);
- ubz = bucket_zone_lookup(entries);
- bucket = uma_zalloc(ubz-ubz_zone, bflags);
+ if (zone-uz_flags UMA_ZFLAG_CACHEONLY)
+ flags |= M_NOVM;
+ ubz = bucket_zone_lookup(zone-uz_count);
+ bucket = uma_zalloc(ubz-ubz_zone, flags);
if (bucket) {
#ifdef INVARIANTS
bzero(bucket-ub_bucket, sizeof(void *) * ubz-ubz_entries);
@@ -380,7 +380,7 @@ bucket_alloc(int entries, int bflags)
}
static void
-bucket_free(uma_bucket_t bucket)
+bucket_free(uma_zone_t zone, uma_bucket_t bucket)
{
struct uma_bucket_zone *ubz;
@@ -662,9 +662,9 @@ cache_drain(uma_zone_t zone)
bucket_drain(zone, cache-uc_allocbucket);
bucket_drain(zone, cache-uc_freebucket);
if (cache-uc_allocbucket != NULL)
- bucket_free(cache-uc_allocbucket);
+ bucket_free(zone, cache-uc_allocbucket);
if (cache-uc_freebucket != NULL)
- bucket_free(cache-uc_freebucket);
+ bucket_free(zone, cache-uc_freebucket);
cache-uc_allocbucket = cache-uc_freebucket = NULL;
}
ZONE_LOCK(zone);
@@ -688,7 +688,7 @@ bucket_cache_drain(uma_zone_t zone)
LIST_REMOVE(bucket, ub_link);
ZONE_UNLOCK(zone);
bucket_drain(zone, bucket);
- bucket_free(bucket);
+ bucket_free(zone, bucket);
ZONE_LOCK(zone);
}
}
@@ -801,7 +801,7 @@ zone_drain_wait(uma_zone_t zone, int wai
if (waitok == M_NOWAIT)
goto out;
mtx_unlock(uma_mtx);
- msleep(zone, zone-uz_lock, PVM, zonedrain, 1);
+ msleep(zone, zone-uz_lockptr, PVM, zonedrain, 1);
mtx_lock(uma_mtx);
}
zone-uz_flags |=
Re: svn commit: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On Jun 20, 2013, at 2:40 AM, David Chisnall wrote: On 20 Jun 2013, at 00:10, Warner Losh i...@bsdimp.com wrote: - FreeBSD developers, who are probably okay with installing a port, but would prefer a version that didn't depend on kitchen/sink? - Users, who wish to be able to update the source tree and then either build world, or build some optional parts that are not part of the default install? - Some other category of svn consumer? I think having a definitive statement as to the intention of svnlite would help frame the discussion in a more productive format. How do I roll back to last week with FreeBSD-update? Which of the classes of user that I outlined do you think wants to be able to do that? As a FreeBSD user, I never felt the desire to do that, but maybe I was unusual. As a FreeBSD developer, I don't mind installing the svn port to be able to do it (although I'd prefer a more lightweight port). I would expect the same to apply to the sort of engaged user who is willing to bisect to track down a bug. People trying new versions of FreeBSD. Some of them install the release, others might install a snapshot, some will do an install world. But if it worked in release 9.3 and broke in 9.4, then to find where they would need to install an svn port to get all the points in between. Not having to install a port, possibly a port that got messed up by the world you just build, is a big win for me in my mind. Users often have commented to me that running FreeBSD gets harder and harder with more hoops to jump through to do things that used to be easy. Installing svn is one more hoop. It, by itself isn't a huge hoop, but if we can avoid that hoop we should. I do mind installing a port to do this. We've kicked too much out of the tree in the name of anti-bloat, and frankly I'm glad to see this. I think insisting on a definitive statement on svn lite's mission statement is a way to obstruct progress. Sometimes you just need to things because they feel right, not because they have been through a 20-step approval process... Warner ___ 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: r251886 - in head: contrib/apr contrib/apr-util contrib/serf contrib/sqlite3 contrib/subversion share/mk usr.bin usr.bin/svn usr.bin/svn/lib usr.bin/svn/lib/libapr usr.bin/svn/lib/liba
On 20 Jun 2013, at 20:34, Warner Losh i...@bsdimp.com wrote: People trying new versions of FreeBSD. Some of them install the release, others might install a snapshot, some will do an install world. But if it worked in release 9.3 and broke in 9.4, then to find where they would need to install an svn port to get all the points in between. Not having to install a port, possibly a port that got messed up by the world you just build, is a big win for me in my mind. Users often have commented to me that running FreeBSD gets harder and harder with more hoops to jump through to do things that used to be easy. Installing svn is one more hoop. It, by itself isn't a huge hoop, but if we can avoid that hoop we should. I do mind installing a port to do this. We've kicked too much out of the tree in the name of anti-bloat, and frankly I'm glad to see this. This rationale makes sense to me. I think insisting on a definitive statement on svn lite's mission statement is a way to obstruct progress. Sometimes you just need to things because they feel right, not because they have been through a 20-step approval process... When we add something to base, it should always be for a reason with a defined use-case that can't be (easily) solved by existing means. I think we have that rationale now, and I'm happy. A long discussion could have been circumvented by providing it up-front. David signature.asc Description: Message signed with OpenPGP using GPGMail
svn commit: r252042 - head/share/man/man7
Author: eadler Date: Thu Jun 20 21:16:46 2013 New Revision: 252042 URL: http://svnweb.freebsd.org/changeset/base/252042 Log: Ports switched from dialog to dialog4ports some time ago. PR: docs/179785 Repored by: Kevin Oberman rkober...@gmail.com Submitted by: Ilya A. Arkhipov rum1...@yandex.ru MFC After:3 days Modified: head/share/man/man7/ports.7 Modified: head/share/man/man7/ports.7 == --- head/share/man/man7/ports.7 Thu Jun 20 19:56:26 2013(r252041) +++ head/share/man/man7/ports.7 Thu Jun 20 21:16:46 2013(r252042) @@ -97,7 +97,7 @@ target. Configure .Va OPTIONS for this port using -.Xr dialog 1 . +.Xr dialog4ports 1 . .It Cm fetch Fetch all of the files needed to build this port from the sites listed in @@ -177,7 +177,7 @@ configured. Configure .Va OPTIONS for this port and all its dependencies using -.Xr dialog 1 . +.Xr dialog4ports 1 . .It Cm fetch-list Show list of files to be fetched in order to build the port. .It Cm fetch-recursive ___ 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: r252045 - head/sys/cam/scsi
Author: smh
Date: Thu Jun 20 21:38:08 2013
New Revision: 252045
URL: http://svnweb.freebsd.org/changeset/base/252045
Log:
Corrected ATA Passthrough defines from decimal to hex
Reviewed by: scottl
MFC after:1 week
Modified:
head/sys/cam/scsi/scsi_all.h
Modified: head/sys/cam/scsi/scsi_all.h
==
--- head/sys/cam/scsi/scsi_all.hThu Jun 20 21:29:03 2013
(r252044)
+++ head/sys/cam/scsi/scsi_all.hThu Jun 20 21:38:08 2013
(r252045)
@@ -917,10 +917,10 @@ struct ata_pass_12 {
#defineAP_PROTO_DMA_QUEUED (0x07 1)
#defineAP_PROTO_DEVICE_DIAG(0x08 1)
#defineAP_PROTO_DEVICE_RESET (0x09 1)
-#defineAP_PROTO_UDMA_IN(0x10 1)
-#defineAP_PROTO_UDMA_OUT (0x11 1)
-#defineAP_PROTO_FPDMA (0x12 1)
-#defineAP_PROTO_RESP_INFO (0x15 1)
+#defineAP_PROTO_UDMA_IN(0x0a 1)
+#defineAP_PROTO_UDMA_OUT (0x0b 1)
+#defineAP_PROTO_FPDMA (0x0c 1)
+#defineAP_PROTO_RESP_INFO (0x0f 1)
#defineAP_MULTI0xe0
u_int8_t flags;
#defineAP_T_LEN0x03
___
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: r252032 - head/sys/amd64/include
On Thu, 20 Jun 2013, Konstantin Belousov wrote:
Log:
Allow immediate operand.
..
Modified: head/sys/amd64/include/counter.h
==
--- head/sys/amd64/include/counter.hThu Jun 20 14:20:03 2013
(r252031)
+++ head/sys/amd64/include/counter.hThu Jun 20 14:30:04 2013
(r252032)
@@ -44,7 +44,7 @@ counter_u64_add(counter_u64_t c, int64_t
__asm __volatile(addq\t%1,%%gs:(%0)
:
- : r ((char *)c - (char *)__pcpu[0]), r (inc)
+ : r ((char *)c - (char *)__pcpu[0]), ri (inc)
: memory, cc);
}
I don't like the quality of these asms. pcpu.h on both amd64 and i386
uses a hackish output operand and no memory clobber, and no cc clobber.
The output operand is hackish because the variable is in a different
address space. But since the variable is in a different address space,
the memory clobber is very unlikely to protect anything -- it could
only protect accesses to the variable without using %gs, and it is
practically impossible to have such accesses in scope, since we are
using %gs because it is the only way that we have in scope to access
the variable.
The i386 version is much larger and uglier. It has mounds of style bugs.
See {amd64.i386}/include/atomic.h for normal style of multi-line asms.
I don't like that either. I like a style with backslash-newlines, hard
tabs and soft newlines ('...\n\$') used in i386/isa/npx.c. The
backslash-newlines are and hard tabs less ugly and more readable than
double quotes and soft tabs ('...\n\t$'). Escapes in string constants
are unfortunately necessary since gcc broke its extension of allowing
hard newlines in string constants.
The old good way, using the gcc extension, allowed copying extern asm:
directly into inline asm (code for a dummy loop):
asm(
movl$100,%%ecx
1:
decl%%ecx
jne 1b
);
Without the extension, this has to be uglified and requires a lot of editing
to convert. Using backslash-newline and the same indentation for the source
and generated asm file, but with trailing tabs to line up:
asm( \n\
movl$100,%%ecx \n\
1: \n\
decl%%ecx \n\
jne 1b \n\
);/* clobbers omitted */
The style in machine/atomic.h adds lots of quotes and breaks the formatting
of the generated asm file by omitting the newlines, and has to add another
ugliness to recover from that -- now it needs semicolons instead of newlines:
asm(
movl$100,%%ecx;
1: /* should use newline/semi */
decl%%ecx ;
jne 1b
); /* might be on previous line */
This requires much more editing. Finally, the style in
i386/include/counter.h changes the semicolons to soft newlines to
improve the output and removes most of the formatting in the source but
adds soft tabs to give the indentation in the output in another way:
asm(
movl $100,%%ecx\n\t
1:\n\t
decl %%ecx\n\t
jne 1b\n\t
);
The i386 version of the counter asm doesn't support the immediate
constraint for technical reasons. 64 bit counters are too large and
slow to use on i386, especially when they are implemented as they are
without races.
Bruce
___
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: r252032 - head/sys/amd64/include
On Fri, 21 Jun 2013, I wrote: On Thu, 20 Jun 2013, Konstantin Belousov wrote: ... @@ -44,7 +44,7 @@ counter_u64_add(counter_u64_t c, int64_t ... The i386 version of the counter asm doesn't support the immediate constraint for technical reasons. 64 bit counters are too large and slow to use on i386, especially when they are implemented as they are without races. Actual testing showed that it is only about twice as slow as a direct increment. With the enclosed test program (a userland version hacked on a bit to avoid pcpu), on ref10-i386 the times are: - loop overhead:1 cycle - direct unlocked increment of a uint32_t: 6 cycles - direct unlocked increment of a uint64_t: 7 cycles - non-inline function unlocked increment of a uint64_t: 7.5 cycles - counter_u64_add(): 14 cycles - non-inline counter_u64_add():18 cycles Add many more when critical_enter()/exit() is needed. I thought that a direct increment of a uint32_t took only 3 cycles. This is the documented time for i486. 4 cycles latency is documented for AthlonxXP/64. The carry check for incrementing a uint64_t is pipelined on most modern i386, so it adds very little to this. Nevertheless, the correct implementation of counters, once you have the complexity of a counter API and can't just do counter++, is to use small counters and run a daemon to accumulate them in larger counters before they overflow. pcpu accesses should allow simple counter++ accesses to work for the smaller counters (except their address is in pcpu space). But I don't see how sysctl accesses can work without lots of context switches to reach strictly per-CPU context. The current accumulation of pcpu counters in places like vcnt() doesn't do that -- it accesses pcpu counters for other CPUs, so has races. The races are more serious for accumulating counters into larger ones. Then the smaller ones need to be cleared atomically with copying them. The accumulation daemon(s) can run per-CPU more easily than sysctls, since the daemons don't need to run as frequently as sysctls might. Bruce ___ 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: r252032 - head/sys/amd64/include
On Fri, 21 Jun 2013, Bruce Evans wrote:
On Fri, 21 Jun 2013, I wrote:
On Thu, 20 Jun 2013, Konstantin Belousov wrote:
...
@@ -44,7 +44,7 @@ counter_u64_add(counter_u64_t c, int64_t
...
The i386 version of the counter asm doesn't support the immediate
constraint for technical reasons. 64 bit counters are too large and
slow to use on i386, especially when they are implemented as they are
without races.
Actual testing showed that it is only about twice as slow as a direct
increment. With the enclosed test program (a userland version hacked
on a bit to avoid pcpu), on ref10-i386 the times are:
- loop overhead:1 cycle
- direct unlocked increment of a uint32_t: 6 cycles
- direct unlocked increment of a uint64_t: 7 cycles
- non-inline function unlocked increment of a uint64_t: 7.5 cycles
- counter_u64_add(): 14 cycles
- non-inline counter_u64_add():18 cycles
...
Actually enclosing the test program:
% #include stdint.h
% #include stdio.h
%
% static inline void
% counter_64_inc_8b(volatile uint64_t *p, int64_t inc)
% {
%
% __asm __volatile(
% movl %%ds:(%%esi),%%eax\n\t
% movl %%ds:4(%%esi),%%edx\n
% 1:\n\t
% movl %%eax,%%ebx\n\t
% movl %%edx,%%ecx\n\t
% addl (%%edi),%%ebx\n\t
% adcl 4(%%edi),%%ecx\n\t
% cmpxchg8b %%ds:(%%esi)\n\t
% jnz 1b
% :
% : S (p), D (inc)
% : memory, cc, eax, edx, ebx, ecx);
% }
%
% uint32_t cpu_feature = 1;
%
% typedef volatile uint64_t *counter_u64_t;
%
% static void
% #if 1
% inline
% #else
% __noinline
% #endif
% counter_u64_add(counter_u64_t c, int64_t inc)
% {
%
% #if 1
% if ((cpu_feature 1) == 1) {
% counter_64_inc_8b(c, inc);
% }
% #elif 0
% if ((cpu_feature 1) == 1) {
% *c += inc;
% }
% #else
% *c += inc;
% #endif
% }
%
% uint64_t mycounter[1];
%
% int
% main(void)
% {
% unsigned i;
%
% for (i = 0; i 1861955704; i++) /* sysctl -n machdep.tsc_freq */
% counter_u64_add(mycounter, 1);
% printf(%ju\n, (uintmax_t)mycounter[0]);
% }
Bruce
___
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: r252051 - head/sbin/mdconfig
Author: hrs
Date: Fri Jun 21 01:47:22 2013
New Revision: 252051
URL: http://svnweb.freebsd.org/changeset/base/252051
Log:
- Use length of _PATH_DEV instead of a hardcoded value[*].
- Use MD_NAME for md.
Pointed out by: trasz [*]
MFC after:1 week
Modified:
head/sbin/mdconfig/mdconfig.c
Modified: head/sbin/mdconfig/mdconfig.c
==
--- head/sbin/mdconfig/mdconfig.c Fri Jun 21 01:22:29 2013
(r252050)
+++ head/sbin/mdconfig/mdconfig.c Fri Jun 21 01:47:22 2013
(r252051)
@@ -216,8 +216,8 @@ main(int argc, char **argv)
errx(1, unknown suffix on -s argument);
break;
case 'u':
- if (!strncmp(optarg, _PATH_DEV, 5))
- optarg += 5;
+ if (!strncmp(optarg, _PATH_DEV, sizeof(_PATH_DEV) - 1))
+ optarg += sizeof(_PATH_DEV) - 1;
if (!strncmp(optarg, MD_NAME, sizeof(MD_NAME) - 1))
optarg += sizeof(MD_NAME) - 1;
uflag = optarg;
@@ -510,7 +510,7 @@ static int
md_find(const char *list, const char *name)
{
int ret;
- char num[16];
+ char num[PATH_MAX];
char *ptr, *p, *u;
ret = 0;
@@ -518,10 +518,10 @@ md_find(const char *list, const char *na
if (ptr == NULL)
return (-1);
for (p = ptr; (u = strsep(p, ,)) != NULL;) {
- if (strncmp(u, _PATH_DEV, 5) == 0)
- u += 5;
+ if (strncmp(u, _PATH_DEV, sizeof(_PATH_DEV) - 1) == 0)
+ u += sizeof(_PATH_DEV) - 1;
/* Just in case user specified number instead of full name */
- snprintf(num, sizeof(num), md%s, u);
+ snprintf(num, sizeof(num), %s%s, MD_NAME, u);
if (strcmp(u, name) == 0 || strcmp(num, name) == 0) {
ret = 1;
break;
___
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: r252032 - head/sys/amd64/include
Hi Kostik, On 06/21/13 00:30, Konstantin Belousov wrote: Author: kib Date: Thu Jun 20 14:30:04 2013 New Revision: 252032 URL: http://svnweb.freebsd.org/changeset/base/252032 Log: Allow immediate operand. Sponsored by: The FreeBSD Foundation Modified: head/sys/amd64/include/counter.h Modified: head/sys/amd64/include/counter.h == --- head/sys/amd64/include/counter.h Thu Jun 20 14:20:03 2013 (r252031) +++ head/sys/amd64/include/counter.h Thu Jun 20 14:30:04 2013 (r252032) @@ -44,7 +44,7 @@ counter_u64_add(counter_u64_t c, int64_t __asm __volatile(addq\t%1,%%gs:(%0) : - : r ((char *)c - (char *)__pcpu[0]), r (inc) + : r ((char *)c - (char *)__pcpu[0]), ri (inc) : memory, cc); } For mere mortals like myself, a verbose explanation of what this does, why it's necessary and what problem(s) it solves (if any) would be most helpful :) Cheers, Lawrence ___ 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: r252052 - head/share/man/man9
Author: lstewart Date: Fri Jun 21 03:37:35 2013 New Revision: 252052 URL: http://svnweb.freebsd.org/changeset/base/252052 Log: Non-virtualised hhook points are supported as of r251732. MFC after:1 week X-MFC with: 251732 Modified: head/share/man/man9/hhook.9 Modified: head/share/man/man9/hhook.9 == --- head/share/man/man9/hhook.9 Fri Jun 21 01:47:22 2013(r252051) +++ head/share/man/man9/hhook.9 Fri Jun 21 03:37:35 2013(r252052) @@ -30,7 +30,7 @@ .\ .\ $FreeBSD$ .\ -.Dd February 15, 2011 +.Dd June 21, 2013 .Dt HHOOK 9 .Os .Sh NAME @@ -380,9 +380,3 @@ This manual page was written by .An David Hayes Aq david.ha...@ieee.org and .An Lawrence Stewart Aq lstew...@freebsd.org . -.Sh BUGS -The framework does not currently support registering hook points in subsystems -which have not been virtualised with VIMAGE. -Fairly minimal internal changes to the -.Nm -implementation are required to address this. ___ 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
