Re: svn commit: r252032 - head/sys/amd64/include
On Sat, Jun 22, 2013 at 01:37:58PM +1000, Bruce Evans wrote:
On Sat, 22 Jun 2013, I wrote:
...
Here are considerably expanded tests, with noninline tests dropped.
Summary of times on Athlon64:
simple increment: 4-7 cycles (1)
simple increment preceded by feature test: 5-8 cycles (1)
simple 32-bit increment:4-7 cycles (2)
correct 32-bit increment (addl to mem): 5.5-7 cycles (3)
inlined critical section: 8.5 cycles (4)
better inlined critical section:7 cycles (5)
correct unsigned 32-bit inc of 64-bit counter: 4-7 cycles (6)
improve previous to allow immediate operand: 5+ cycles
correct signed 32-bit inc of 64-bit counter:8.5-9 cycles (7)
correct 64-bit inc of 64-bit counter: 8-9 cycles (8)
-current method (cmpxchg8b): 18 cycles
corei7 (freefall) has about the same timing as Athlon64, but core2
(ref10-i386) is 3-4 cycles slower for the tests that use cmpxchg.
You only tested 32 bit, right ? Note that core2-class machines have
at least one cycle penalty for decoding any instruction with REX prefix.
(4) The critical section method is quite fast when inlined.
(5) The critical section method is even faster when optimized. This is
what should be used if you don't want the complications for the
daemon.
Oops, I forgot that critical sections are much slower in -current than
in my version. They probably take 20-40 cycles for the best case, and
can't easily be tested in userland since they disable interrupts in
hardware. My versions disable interrupts in software.
The critical sections do not disable the interrupts. Only the thread
local counter is incremented. Leaving the section could be complicated
though.
...
% % static inline void
% alt_counter_u64_add(counter_u64_t c, int64_t inc)
% {
% #if 1
% /* 8.5 cycles on A64. */
% td-td_critnest++;
% __asm __volatile(addl %1,%%ds:%0 : =m,m (*c) : ?i,r (inc));
% td-td_critnest++;
Oops, one increment should be a decrement.
% #elif 1
% /* 7 cycles on A64. */
% uint32_t ocritnest;
%
% ocritnest = td-td_critnest;
% td-td_critnest = ocritnest + 1;
% __asm __volatile(addl %1,%%ds:%0 : =m,m (*c) : ?i,r (inc));
% td-td_critnest = ocritnest;
% #elif 0
Even in my version, I have to check for unmasked interrupts when td_critnest
is reduced to 0. At least the test for being reduced to 0 can be very fast,
since the reduced value is loaded early and can be tested early.
Further tests confirm that incl and incq are pipelined normally on at
least corei7 and core2. In the loop test, freefall can do 4 independent
addq's to memory faster than it can do 1 :-). It can do 6 independent
addq's to memory in the same time that it can do 1. After that, the
loop overhead prevents geting the complete bandwidth of the memory
system. However, 6 addq's to the same memory location take a little
more than 6 times longer than 1. Multiple increments of the same counter
one after the other are probably rare, but the counter API makes it harder
to coaelsce them if they occur, and the implementation using independent
asms ensures that the compiler cannot coalesce them.
I think that the naive looping on Core i7+ to measure the latencies
of the instructions simply does not work. The Nehalem hardware started
to provide the loop detector for the instruction queue inside the decoder,
which essentially makes the short loops executed from the microopcode
form. We never use counters in the tight loops.
pgpNJb5wXELLy.pgp
Description: PGP signature
Re: svn commit: r252032 - head/sys/amd64/include
On Sat, Jun 22, 2013 at 06:58:15PM +1000, Bruce Evans wrote: So the i386 version be simply addl; adcl to memory. Each store in this is atomic at the per-CPU level. If there is no carry, then the separate stores are equivalent to adding separate nonnegative values and the counter value is valid at all times. If there is carry, then the separate stores are equivalent to adding a negative value followed by a larger positive value. The counter transiently goes backwards, but no information is lost and the counter is eventually set to the correct forward-going value. This is quite interesting idea, but I still did not decided if it acceptable. The issue is that we could add the carry to the other processor counter, if the preemption kicks in at right time between two instructions. I did not found any argument why would it be wrong, the races for fetch operation seems to be the same with either local update method. On the other hand, for debugging it would be quite confusing state of the counters array to observe. pgpBRbpz1zfRK.pgp Description: PGP signature
Re: svn commit: r252032 - head/sys/amd64/include
On Sun, 23 Jun 2013, Konstantin Belousov wrote: On Sat, Jun 22, 2013 at 01:37:58PM +1000, Bruce Evans wrote: On Sat, 22 Jun 2013, I wrote: ... Here are considerably expanded tests, with noninline tests dropped. Summary of times on Athlon64: simple increment: 4-7 cycles (1) simple increment preceded by feature test: 5-8 cycles (1) simple 32-bit increment:4-7 cycles (2) correct 32-bit increment (addl to mem): 5.5-7 cycles (3) inlined critical section: 8.5 cycles (4) better inlined critical section:7 cycles (5) correct unsigned 32-bit inc of 64-bit counter: 4-7 cycles (6) improve previous to allow immediate operand: 5+ cycles correct signed 32-bit inc of 64-bit counter:8.5-9 cycles (7) correct 64-bit inc of 64-bit counter: 8-9 cycles (8) -current method (cmpxchg8b): 18 cycles corei7 (freefall) has about the same timing as Athlon64, but core2 (ref10-i386) is 3-4 cycles slower for the tests that use cmpxchg. You only tested 32 bit, right ? Note that core2-class machines have at least one cycle penalty for decoding any instruction with REX prefix. Yes, since the 64-bit case works more or less correctly. I tested the 32-bit binary on 64-bit systems. (4) The critical section method is quite fast when inlined. (5) The critical section method is even faster when optimized. This is what should be used if you don't want the complications for the daemon. Oops, I forgot that critical sections are much slower in -current than in my version. They probably take 20-40 cycles for the best case, and can't easily be tested in userland since they disable interrupts in hardware. My versions disable interrupts in software. The critical sections do not disable the interrupts. Only the thread local counter is incremented. Leaving the section could be complicated though. Yes, as I noticed later, it was only an old version of FreeBSD that disabled interrupts. The critical section method (or disabling interrupts, which is probably faster) only works for the non-SMP case, but old CPUs that don't have cmpxchg8b probably don't support SMP. Further tests confirm that incl and incq are pipelined normally on at least corei7 and core2. In the loop test, freefall can do 4 independent addq's to memory faster than it can do 1 :-). It can do 6 independent addq's to memory in the same time that it can do 1. After that, the loop overhead prevents geting the complete bandwidth of the memory system. However, 6 addq's to the same memory location take a little more than 6 times longer than 1. Multiple increments of the same counter one after the other are probably rare, but the counter API makes it harder to coaelsce them if they occur, and the implementation using independent asms ensures that the compiler cannot coalesce them. I think that the naive looping on Core i7+ to measure the latencies of the instructions simply does not work. The Nehalem hardware started to provide the loop detector for the instruction queue inside the decoder, which essentially makes the short loops executed from the microopcode form. We never use counters in the tight loops. The test results show it working perfectly in the test environment. Any loop detection just does a better job of running all the loop instructions in parallel with the instructions being timed. But even old CPUs can run all the loop instructions in parallel with high-latency instructions like add-to-memory. Also, add-to-memory instructions have strict ordering requirements on x86. The order must be load-modify-store. That's for storing to a single location. This prevents the loop running in parallel with itself, so its latency timing works especially simply. However, the test environment isn't normal. It is important to understand that some of the time is latency that doesn't matter in the normal environment. But in the complicated versions with cmpxchg8b's or critical sections, there are lots of extra instructions and ordering requirements whose latencies can't be hidden. 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: r252109 - head/usr.sbin/bsdconfig/share/media
Author: dteske
Date: Sun Jun 23 09:41:47 2013
New Revision: 252109
URL: http://svnweb.freebsd.org/changeset/base/252109
Log:
Fine-tune the parsing of the URL. Re-order, comment, and add debugging to
each case of unique URL format.
Modified:
head/usr.sbin/bsdconfig/share/media/ftp.subr
head/usr.sbin/bsdconfig/share/media/httpproxy.subr
Modified: head/usr.sbin/bsdconfig/share/media/ftp.subr
==
--- head/usr.sbin/bsdconfig/share/media/ftp.subrSun Jun 23 09:34:55
2013(r252108)
+++ head/usr.sbin/bsdconfig/share/media/ftp.subrSun Jun 23 09:41:47
2013(r252109)
@@ -378,27 +378,62 @@ f_media_set_ftp()
local hostname=${url#*://} port=21 dir=/
case $hostname in
- [*])
+ #
+ # The order in-which the below individual cases appear is important!
+ #
+ [*]:*/*) # IPv6 address with port and directory
+ f_dprintf Looks like an IPv6 addr with port/dir: %s \
+ $hostname
hostname=${hostname#\[}
- hostname=${hostname%%\]*}
+ port=${hostname#*\]:}
+ port=${port%%[!0-9]*}
+ dir=/${hostname#*/}
+ hostname=${hostname%%\]:*}
;;
- [*]/*)
+ [*]:*) # IPv6 address with port
+ f_dprintf Looks like an IPv6 addr with port: %s $hostname
hostname=${hostname#\[}
- dir=/${hostname#*/}
- hostname=${hostname%%\]*}
+ port=${hostname#*\]:}
+ port=${port%%[!0-9]*}
+ hostname=${hostname%%\]:*}
;;
- */*)
+ [*]/*) # IPv6 address with directory
+ f_dprintf Looks like an IPv6 addr with dir: %s $hostname
+ hostname=${hostname#\[}
dir=/${hostname#*/}
- hostname=${hostname%%/*}
+ hostname=${hostname%%\]*}
;;
- [*]:*)
+ [*]) # IPv6 address
+ f_dprintf Looks like an IPv6 addr: %s $hostname
hostname=${hostname#\[}
- port=${hostname#*\]:}
+ hostname=${hostname%\]}
+ ;;
+ #
+ # ^^^ IPv6 above / DNS Name or IPv4 below vvv
+ #
+ *:*/*) # DNS name or IPv4 address with port and directory
+ f_dprintf Looks like a %s with port/dir: %s \
+ DNS name or IPv4 addr $hostname
+ port=${hostname#*:}
port=${port%%[!0-9]*}
- hostname=${hostname%%\]:*}
+ dir=/${hostname#*/}
+ hostname=${hostname%%:*}
+ ;;
+ *:*) # DNS name or IPv4 address with port
+ f_dprintf Looks like a DNS name or IPv4 addr with port: %s \
+ $hostname
+ port=${hostname#*:}
+ hostname=${hostname%%:*}
;;
- *)
+ */*) # DNS name or IPv4 address with directory
+ f_dprintf Looks like a DNS name or IPv4 addr with dir: %s \
+ $hostname
+ dir=/${hostname#*/}
hostname=${hostname%%/*}
+ ;;
+ *) # DNS name or IPv4 address
+ f_dprintf Looks like a DNS name or IPv4 addr: %s $hostname
+ : leave hostname as-is
esac
f_dprintf hostname = \`%s' $hostname
Modified: head/usr.sbin/bsdconfig/share/media/httpproxy.subr
==
--- head/usr.sbin/bsdconfig/share/media/httpproxy.subr Sun Jun 23 09:34:55
2013(r252108)
+++ head/usr.sbin/bsdconfig/share/media/httpproxy.subr Sun Jun 23 09:41:47
2013(r252109)
@@ -77,19 +77,33 @@ f_media_set_http_proxy()
local hostname=$proxy port=3128
case $hostname in
- [*])
- hostname=${hostname#\[}
- hostname=${hostname%\]}
- ;;
- [*]:*)
+ #
+ # The order in-which the below individual cases appear is important!
+ #
+ [*]:*) # IPv6 address with port
+ f_dprintf Looks like an IPv6 addr with port: %s $hostname
hostname=${hostname#\[}
port=${hostname#*\]:}
port=${port%%[!0-9]*}
hostname=${hostname%%\]:*}
;;
- *:*)
+ [*]) # IPv6 address
+ f_dprintf Looks like an IPv6 addr: %s $hostname
+ hostname=${hostname#\[}
+ hostname=${hostname%\]}
+ ;;
+ #
+ # ^^^ IPv6 above / DNS Name or IPv4 below vvv
+ #
+ *:*) # DNS name or IPv4 address with port
+ f_dprintf Looks like a DNS name or IPv4 addr with port: %s \
+ $hostname
port=${hostname#*:}
hostname=${hostname%%:*}
+ ;;
+ *) #
Re: svn commit: r252032 - head/sys/amd64/include
On Sun, 23 Jun 2013, Konstantin Belousov wrote: On Sat, Jun 22, 2013 at 06:58:15PM +1000, Bruce Evans wrote: So the i386 version be simply addl; adcl to memory. Each store in this is atomic at the per-CPU level. If there is no carry, then the separate stores are equivalent to adding separate nonnegative values and the counter value is valid at all times. If there is carry, then the separate stores are equivalent to adding a negative value followed by a larger positive value. The counter transiently goes backwards, but no information is lost and the counter is eventually set to the correct forward-going value. This is quite interesting idea, but I still did not decided if it acceptable. The issue is that we could add the carry to the other processor counter, if the preemption kicks in at right time between two instructions. I did not found any argument why would it be wrong, the races for fetch operation seems to be the same with either local update method. I thought about exploiting not-so-strong memory ordering to fix the fetches. On at least x86, stores are not reordered, so if the storer does a simple addl, adcl, then the order is not much different from load low 32 bits store low 32 bits load high 32 bits store high 32 bits The loads can be in any order, but must be before the stores to the same location. I think the fetching code can depend on this (maybe only on x86, but the fetching code needs to be MD anyway). Thus it can detect most races by simply rereading the counters in almost any order until they don't change. Without this, the fetching code can easily read high and low bits from unrelated stores (when it is preempted, the race window is large), and the sophisticated cmpxchg8b code to make each store atomic is almost useless. The case that can't be fixed by rereading the counters is when fetching code runs in between the stores. If the stores are on a another CPU that is currently executing them, then we can keep checking that the counters don't change for the maximum time that any pair of stores take to complete. This time is quite long and difficult to determine (but it can be bounded by hard-disabling interrupts in the storer, and limited by prefetching). If the stores are on the same CPU, then we have no good way to detect that another thread is in the middle of them, or to switch back to that thread. So we currently prevent this case using slow methods. On the other hand, for debugging it would be quite confusing state of the counters array to observe. I thought of lots of variations, but couldn't find one that works perfectly. One idea (that goes with the sign check on the low 32 bits) is to use a misaligned add to memory to copy the 31st bit as a carry bit to the the high word. The value of the counter is supposed to be [unsigned value of low 32 bits] + [unsigned value of next 24 bits] 31 (high 8 bits not used) at all times, with the 31st bit zero at most times so that the the carry operation is rarely executed. This format is only slightly confusing for debugging (it basically has 2 31st bits, with the one in the low 32 bits rarely used). This format can be updated using something like: addl%1,%%fs:(%0)# only small 32-bit increments supported jns 8f addl$0x80,%%fs:3(%0)# misaligned memory access 8: ; No problem if this is not preempted. The idea of the misaligned memory access is that the CPU needs to make this atomic enough even though it crosses a 32-bit boundary. BTW, is anything guaranteed if the access also crosses a cache line or page boundary? The OS would be involved for page boundaries if there is a page fault. Better not step on bugs in that. What about for misaligned 64-bit or 128-bit stores done by cmpxchg8b or SSE? Counters are 64-bit aligned, so I think that at least CPUs that are basically 64-bit must handle this like I want. The above doesn't work if it is preempted -- then it might add do the carry operation more than once. But it is easy to lock using cmpxchg or disabling interrupts. Disabling interrupts requires only small code: addl%1,%%fs:(%0)# only small 32-bit increments supported jns 8f pushfl cli testb $0x80,%%fs:3(%0) je 1f # carry already done by preemption addl$0x80,%%fs:3(%0)# misaligned memory access 1: popfl 8: ; Another idea is to use the high bits of the high word to encode state. They can be set atomically enough using addl/andl/orl/xorl since they are per-CPU. I couldn't quite get this to work. You could increment them to indicate an update in progress. This only requires 1 extra add to memory if the adcl is always done (e.g., first add 0x01 to the high word; then addl to the low word; then adcl of (inc 32) - 0x0100 to the high word. Increments must be limited to not
svn commit: r252110 - head/usr.sbin/bsdconfig/share/media
Author: dteske Date: Sun Jun 23 10:04:23 2013 New Revision: 252110 URL: http://svnweb.freebsd.org/changeset/base/252110 Log: Implement the $probe_only parameter (previously unimplemented). 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 Sun Jun 23 09:41:47 2013(r252109) +++ head/usr.sbin/bsdconfig/share/media/httpproxy.subr Sun Jun 23 10:04:23 2013(r252110) @@ -333,8 +333,10 @@ f_media_init_http_proxy() # # Returns data from $file on an FTP server via HTTP proxy using nc(1). Please # note that $device is unused but must be present (even if null). Information -# is instead gathered from the environment. $probe_only is currently unused by -# this media type. +# is instead gathered from the environment. If $probe_only is both present and +# non-NULL, this function exits after receiving the HTTP header response from +# the proxy server (if the HTTP response code is 200, success is returned; +# otherwise failure). # # The variables used to configure the connection are as follows (all of which # are configured by f_media_set_http_proxy above): @@ -425,11 +427,14 @@ f_media_get_http_proxy() [ $rv -ge 300 ] exit 3 [ $rv -eq 200 ] || exit $FAILURE - cat # output the rest ``as-is'' + if [ ! $probe_only ]; then + cat # output the rest ``as-is'' + fi exit 200 ) local retval=$? [ $retval -eq 200 ] return $SUCCESS + [ $probe_only ] return $FAILURE case $retval in 5) f_show_msg $msg_server_error_when_requesting_url $url ;; ___ 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: r252112 - in head/usr.sbin/bsdconfig: include share share/media
Author: dteske Date: Sun Jun 23 10:48:26 2013 New Revision: 252112 URL: http://svnweb.freebsd.org/changeset/base/252112 Log: Merge r248313 from stable/9 sysinstall(8) to head bsdconfig(8): Add support for installation directly via HTTP. While we're here, remove the menu-item for Passive FTP (since moving to ftp(1) and switching FTPMODE to `auto' by default -- see r251613 -- the single remaining FTP menu-item works for both ftp.f.o and ftp-archive.f.o; previously each requiring separately active versus passive both work with the `auto' setting). In scripting you still have mediaSetFTPActive and mediaSetFTPPassive but the remaining FTP menu-item uses mediaSetFTP which defaults to `auto' (aforementioned SVN r251613). Added: head/usr.sbin/bsdconfig/share/media/http.subr (contents, props changed) Modified: head/usr.sbin/bsdconfig/include/media.hlp head/usr.sbin/bsdconfig/include/messages.subr head/usr.sbin/bsdconfig/share/device.subr head/usr.sbin/bsdconfig/share/media/Makefile head/usr.sbin/bsdconfig/share/media/any.subr head/usr.sbin/bsdconfig/share/media/options.subr head/usr.sbin/bsdconfig/share/script.subr head/usr.sbin/bsdconfig/share/variable.subr Modified: head/usr.sbin/bsdconfig/include/media.hlp == --- head/usr.sbin/bsdconfig/include/media.hlp Sun Jun 23 10:16:14 2013 (r252111) +++ head/usr.sbin/bsdconfig/include/media.hlp Sun Jun 23 10:48:26 2013 (r252112) @@ -25,13 +25,11 @@ You can install from the following types FTP Get the distribution files from an anonymous ftp server (you will be presented with a list). Please note that -you may invoke FTP in Active mode, Passive mode, or +you may invoke FTP in Active/Passive auto-mode, or via an HTTP proxy. -Active mode is the standard way of fetching files and -Passive mode is for use when you're behind a firewall or -some other security mechanism that blocks active FTP -connections. Using an HTTP proxy is sometimes necessary +By default, ftp(1) will automatically use the best mode +for the server. Using an HTTP proxy is sometimes necessary for firewalls which block all FTP connections. If you chose to enter your own URL in the FTP menu, please @@ -41,6 +39,14 @@ You can install from the following types Options screen. + HTTP Direct +Get the distribution files directly from an HTTP server. + +If you chose to enter your own URL in the HTTP Direct menu, +please note that all paths are *relative* to the root +directory of the web server. + + NFS Get the distribution files from an NFS server somewhere (make sure that permissions on the server allow this!). If this install method hangs on you or refuses to work Modified: head/usr.sbin/bsdconfig/include/messages.subr == --- head/usr.sbin/bsdconfig/include/messages.subr Sun Jun 23 10:16:14 2013(r252111) +++ head/usr.sbin/bsdconfig/include/messages.subr Sun Jun 23 10:48:26 2013(r252112) @@ -87,6 +87,7 @@ msg_could_not_unmount_the_nfs_partition= msg_could_not_unmount_the_ufs_partition=Could not unmount the UFS partition from %s: %s msg_couldnt_connect_to_ftp_server=Couldn't connect to FTP server msg_couldnt_connect_to_proxy=Couldn't connect to proxy +msg_couldnt_connect_to_server=Couldn't connect to server msg_couldnt_open_ftp_connection=Couldn't open FTP connection to %s:\n %s. msg_created_path=Created %s msg_croatia=Croatia @@ -148,7 +149,7 @@ msg_hebrew_desc=Ported software for Heb msg_help=Help msg_host_name_including_domain=Host name (including domain) msg_hostname_variable_not_set=WARNING: hostname variable not set and is a non-optional\nparameter. Please add this to your installation script\nor set the netInteractive variable (see bsdconfig man page) -msg_http=HTTP +msg_http_direct=HTTP Direct msg_http_proxy=HTTP Proxy msg_hungarian_desc=Ported software for the Hungarian market. msg_hungary=Hungary @@ -161,6 +162,7 @@ msg_install_from_a_usb_drive=Install fr msg_install_from_an_ftp_server=Install from an FTP server msg_install_from_an_ftp_server_thru_firewall=Install from an FTP server through a firewall msg_install_from_an_ftp_server_thru_proxy=Install from an FTP server through an HTTP proxy +msg_install_from_an_http_server=Install from an HTTP server msg_install_from_the_existing_filesystem=Install from the existing filesystem msg_install_over_nfs=Install over NFS msg_installed=Installed @@ -270,6 +272,7 @@ msg_please_select_a_category_to_display= msg_please_select_a_cd_dvd_drive=FreeBSD can be installed directly from a CD/DVD containing a valid\nFreeBSD distribution. If
svn commit: r252113 - head/usr.sbin/bsdconfig/include
Author: dteske Date: Sun Jun 23 10:51:26 2013 New Revision: 252113 URL: http://svnweb.freebsd.org/changeset/base/252113 Log: Add a newline character to the end of the Check URL again error message because long URLs do not induce extra height despite wrapping by dialog(1). NOTE: For even longer lines, the cursor up/down keys work to scroll through Modified: head/usr.sbin/bsdconfig/include/messages.subr Modified: head/usr.sbin/bsdconfig/include/messages.subr == --- head/usr.sbin/bsdconfig/include/messages.subr Sun Jun 23 10:48:26 2013(r252112) +++ head/usr.sbin/bsdconfig/include/messages.subr Sun Jun 23 10:51:26 2013(r252113) @@ -259,7 +259,7 @@ msg_pear_desc=Software related to the P msg_perl5_desc=Utilities/modules for the PERL5 language. msg_permission_denied=%s: %s: Permission denied msg_plan9_desc=Software from the Plan9 operating system. -msg_please_check_the_url_and_try_again=No such directory: %s\nplease check the URL and try again. +msg_please_check_the_url_and_try_again=No such directory: %s\nplease check the URL and try again.\n msg_please_enter_password=Please enter your password for sudo(8): msg_please_enter_the_address_of_the_http_proxy=Please enter the address of the HTTP proxy in this format:\n hostname:port (the ':port' is optional, default is 3128) msg_please_enter_the_full_nfs_file_specification=Please enter the full NFS file specification for the remote\nhost and directory containing the FreeBSD distribution files.\nThis should be in the format: hostname:/some/freebsd/dir ___ 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 2013-06-23 04:43, Garance A Drosehn wrote: On 6/22/13 2:38 PM, Tijl Coosemans wrote: On 2013-06-20 21:34, Warner Losh wrote: 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... For what it's worth, my reservations have always been because it didn't feel right. I never asked for an approval process. I do think there should be a tool in base that can fetch source updates and it would be nice if it could roll back changes and even nicer if it could do bisects. But svn itself is not the right tool for that. For instance, will you allow that svn is updated from version x.y to x.(y+1) in a stable branch? If yes, then users might have to run run svn upgrade which is a one way process, so how does importing svn allow you to roll back changes or do bisects then? If no, then who's volunteering to backport security fixes? What was added to the base system was 'svnlite', not 'svn' from the official subversion project. The distinction is that 'svnlite' is a version meant only for access to the official FreeBSD repositories. 'svnlite' in the base system would only be upgraded when it is needed to match the FreeBSD respository. And if you need to run 'svn upgrade' to access the FreeBSD repository, then it doesn't make much difference if you have to do that with 'svnlite' or via the official 'svn' port. I'm not sure that my comments provide an answer to what you're concerned about, but anyone who wants the latest version of 'svn' to match their own repositories is still going to need to install the port. We're not going to blindly update 'svnlite' every time a new version of 'svn' is released. 'svnlite' is going to be updated on *FreeBSD*'s schedule, not on the schedule of the subversion project. It is true that we're going to have to be careful when it does come time to switch to some new repo-format for the FreeBSD repository. We might find ourselves in some kind of chicken- and-egg situation at that point. And when we do make a significant upgrade to the FreeBSD repository, then we're going to have to upgrade 'svnlite' across multiple FreeBSD branches at the same time, including all -stable branches. But when that issue comes up it'll come up on our schedule, because we'll control both 'svnlite' and the FreeBSD repo. It is precisely the other way around. Once you do a FreeBSD release (releng branch) that release will be stuck with the same version of svnlite for years. You will end up with multiple releases with multiple versions of svnlite that you cannot change. You have zero control. A port on the other hand is the same for all branches and releases of FreeBSD. It is a single point where you have total control over the version of svn for all users. Conceptually, a port corresponds to the fact all branches and releases share the same subversion repo. signature.asc Description: OpenPGP digital signature
svn commit: r252115 - head/sys/powerpc/ofw
Author: jhibbits
Date: Sun Jun 23 14:20:54 2013
New Revision: 252115
URL: http://svnweb.freebsd.org/changeset/base/252115
Log:
Cache the Open Firmware CPU properties at attach time, so we don't always
enter it at runtime to get static data.
Modified:
head/sys/powerpc/ofw/ofw_cpu.c
Modified: head/sys/powerpc/ofw/ofw_cpu.c
==
--- head/sys/powerpc/ofw/ofw_cpu.c Sun Jun 23 13:27:37 2013
(r252114)
+++ head/sys/powerpc/ofw/ofw_cpu.c Sun Jun 23 14:20:54 2013
(r252115)
@@ -133,6 +133,11 @@ static int ofw_cpu_attach(device_t);
static int ofw_cpu_read_ivar(device_t dev, device_t child, int index,
uintptr_t *result);
+struct ofw_cpu_softc {
+ struct pcpu *sc_cpu_pcpu;
+ uint32_t sc_nominal_mhz;
+};
+
static device_method_t ofw_cpu_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, ofw_cpu_probe),
@@ -175,6 +180,15 @@ ofw_cpu_probe(device_t dev)
static int
ofw_cpu_attach(device_t dev)
{
+ struct ofw_cpu_softc *sc;
+ uint32_t cell;
+
+ sc = device_get_softc(dev);
+ OF_getprop(ofw_bus_get_node(dev), reg, cell, sizeof(cell));
+ sc-sc_cpu_pcpu = pcpu_find(cell);
+ OF_getprop(ofw_bus_get_node(dev), clock-frequency, cell,
sizeof(cell));
+ sc-sc_nominal_mhz = cell / 100; /* convert to MHz */
+
bus_generic_probe(dev);
return (bus_generic_attach(dev));
}
@@ -182,19 +196,16 @@ ofw_cpu_attach(device_t dev)
static int
ofw_cpu_read_ivar(device_t dev, device_t child, int index, uintptr_t *result)
{
- uint32_t cell;
+ struct ofw_cpu_softc *sc;
+
+ sc = device_get_softc(dev);
switch (index) {
case CPU_IVAR_PCPU:
- OF_getprop(ofw_bus_get_node(dev), reg, cell, sizeof(cell));
- *result = (uintptr_t)(pcpu_find(cell));
+ *result = (uintptr_t)sc-sc_cpu_pcpu;
return (0);
case CPU_IVAR_NOMINAL_MHZ:
- cell = 0;
- OF_getprop(ofw_bus_get_node(dev), clock-frequency,
- cell, sizeof(cell));
- cell /= 100; /* convert to MHz */
- *result = (uintptr_t)(cell);
+ *result = (uintptr_t)sc-sc_nominal_mhz;
return (0);
}
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
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 23, 2013, at 6:22 AM, Tijl Coosemans wrote: On 2013-06-23 04:43, Garance A Drosehn wrote: On 6/22/13 2:38 PM, Tijl Coosemans wrote: On 2013-06-20 21:34, Warner Losh wrote: 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... For what it's worth, my reservations have always been because it didn't feel right. I never asked for an approval process. I do think there should be a tool in base that can fetch source updates and it would be nice if it could roll back changes and even nicer if it could do bisects. But svn itself is not the right tool for that. For instance, will you allow that svn is updated from version x.y to x.(y+1) in a stable branch? If yes, then users might have to run run svn upgrade which is a one way process, so how does importing svn allow you to roll back changes or do bisects then? If no, then who's volunteering to backport security fixes? What was added to the base system was 'svnlite', not 'svn' from the official subversion project. The distinction is that 'svnlite' is a version meant only for access to the official FreeBSD repositories. 'svnlite' in the base system would only be upgraded when it is needed to match the FreeBSD respository. And if you need to run 'svn upgrade' to access the FreeBSD repository, then it doesn't make much difference if you have to do that with 'svnlite' or via the official 'svn' port. I'm not sure that my comments provide an answer to what you're concerned about, but anyone who wants the latest version of 'svn' to match their own repositories is still going to need to install the port. We're not going to blindly update 'svnlite' every time a new version of 'svn' is released. 'svnlite' is going to be updated on *FreeBSD*'s schedule, not on the schedule of the subversion project. It is true that we're going to have to be careful when it does come time to switch to some new repo-format for the FreeBSD repository. We might find ourselves in some kind of chicken- and-egg situation at that point. And when we do make a significant upgrade to the FreeBSD repository, then we're going to have to upgrade 'svnlite' across multiple FreeBSD branches at the same time, including all -stable branches. But when that issue comes up it'll come up on our schedule, because we'll control both 'svnlite' and the FreeBSD repo. It is precisely the other way around. Once you do a FreeBSD release (releng branch) that release will be stuck with the same version of svnlite for years. You will end up with multiple releases with multiple versions of svnlite that you cannot change. You have zero control. Then they will never have to do svn update, since their checked out tree will never be obsolete in relationship to the version that's installed. A port on the other hand is the same for all branches and releases of FreeBSD. It is a single point where you have total control over the version of svn for all users. Conceptually, a port corresponds to the fact all branches and releases share the same subversion repo. Except that you still need to do svn update on trees that are checked out from old repos. I'm having a real hard time seeing this as an issue based on my experience with the svn port since we made the switch. Then again, I've been talking to the svn repo over http, which is independent of the version of the repo on the other end... 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
You know that there _are_ users that want behaviour (A), and some that want behaviour (B), right? Not everyone wants to run the latest and greatest ports tree on all releases. Adrian On 23 June 2013 05:22, Tijl Coosemans t...@freebsd.org wrote: On 2013-06-23 04:43, Garance A Drosehn wrote: On 6/22/13 2:38 PM, Tijl Coosemans wrote: On 2013-06-20 21:34, Warner Losh wrote: 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... For what it's worth, my reservations have always been because it didn't feel right. I never asked for an approval process. I do think there should be a tool in base that can fetch source updates and it would be nice if it could roll back changes and even nicer if it could do bisects. But svn itself is not the right tool for that. For instance, will you allow that svn is updated from version x.y to x.(y+1) in a stable branch? If yes, then users might have to run run svn upgrade which is a one way process, so how does importing svn allow you to roll back changes or do bisects then? If no, then who's volunteering to backport security fixes? What was added to the base system was 'svnlite', not 'svn' from the official subversion project. The distinction is that 'svnlite' is a version meant only for access to the official FreeBSD repositories. 'svnlite' in the base system would only be upgraded when it is needed to match the FreeBSD respository. And if you need to run 'svn upgrade' to access the FreeBSD repository, then it doesn't make much difference if you have to do that with 'svnlite' or via the official 'svn' port. I'm not sure that my comments provide an answer to what you're concerned about, but anyone who wants the latest version of 'svn' to match their own repositories is still going to need to install the port. We're not going to blindly update 'svnlite' every time a new version of 'svn' is released. 'svnlite' is going to be updated on *FreeBSD*'s schedule, not on the schedule of the subversion project. It is true that we're going to have to be careful when it does come time to switch to some new repo-format for the FreeBSD repository. We might find ourselves in some kind of chicken- and-egg situation at that point. And when we do make a significant upgrade to the FreeBSD repository, then we're going to have to upgrade 'svnlite' across multiple FreeBSD branches at the same time, including all -stable branches. But when that issue comes up it'll come up on our schedule, because we'll control both 'svnlite' and the FreeBSD repo. It is precisely the other way around. Once you do a FreeBSD release (releng branch) that release will be stuck with the same version of svnlite for years. You will end up with multiple releases with multiple versions of svnlite that you cannot change. You have zero control. A port on the other hand is the same for all branches and releases of FreeBSD. It is a single point where you have total control over the version of svn for all users. Conceptually, a port corresponds to the fact all branches and releases share the same subversion repo. ___ 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 Sun, Jun 23, 2013 at 10:12 AM, Warner Losh i...@bsdimp.com wrote: On Jun 23, 2013, at 6:22 AM, Tijl Coosemans wrote: On 2013-06-23 04:43, Garance A Drosehn wrote: On 6/22/13 2:38 PM, Tijl Coosemans wrote: On 2013-06-20 21:34, Warner Losh wrote: 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... For what it's worth, my reservations have always been because it didn't feel right. I never asked for an approval process. I do think there should be a tool in base that can fetch source updates and it would be nice if it could roll back changes and even nicer if it could do bisects. But svn itself is not the right tool for that. For instance, will you allow that svn is updated from version x.y to x.(y+1) in a stable branch? If yes, then users might have to run run svn upgrade which is a one way process, so how does importing svn allow you to roll back changes or do bisects then? If no, then who's volunteering to backport security fixes? What was added to the base system was 'svnlite', not 'svn' from the official subversion project. The distinction is that 'svnlite' is a version meant only for access to the official FreeBSD repositories. 'svnlite' in the base system would only be upgraded when it is needed to match the FreeBSD respository. And if you need to run 'svn upgrade' to access the FreeBSD repository, then it doesn't make much difference if you have to do that with 'svnlite' or via the official 'svn' port. I'm not sure that my comments provide an answer to what you're concerned about, but anyone who wants the latest version of 'svn' to match their own repositories is still going to need to install the port. We're not going to blindly update 'svnlite' every time a new version of 'svn' is released. 'svnlite' is going to be updated on *FreeBSD*'s schedule, not on the schedule of the subversion project. It is true that we're going to have to be careful when it does come time to switch to some new repo-format for the FreeBSD repository. We might find ourselves in some kind of chicken- and-egg situation at that point. And when we do make a significant upgrade to the FreeBSD repository, then we're going to have to upgrade 'svnlite' across multiple FreeBSD branches at the same time, including all -stable branches. But when that issue comes up it'll come up on our schedule, because we'll control both 'svnlite' and the FreeBSD repo. It is precisely the other way around. Once you do a FreeBSD release (releng branch) that release will be stuck with the same version of svnlite for years. You will end up with multiple releases with multiple versions of svnlite that you cannot change. You have zero control. Then they will never have to do svn update, since their checked out tree will never be obsolete in relationship to the version that's installed. A port on the other hand is the same for all branches and releases of FreeBSD. It is a single point where you have total control over the version of svn for all users. Conceptually, a port corresponds to the fact all branches and releases share the same subversion repo. Except that you still need to do svn update on trees that are checked out from old repos. I'm having a real hard time seeing this as an issue based on my experience with the svn port since we made the switch. Then again, I've been talking to the svn repo over http, which is independent of the version of the repo on the other end... Warner I've been resisting the urge to dive in. I will say right up front that a drive-by commit like this is Not The Way We Are Supposed To Do Things(TM). I know that I have ruffled some people's feathers, and for that I'm sorry. I've also got a lot of thank-you messages. I'll try and explain myself. [I know this is long. Please don't start replying until you've read it to the end.] The bottom line as to why I did this.. we are an open *source* operating system. After actually working fully from source on the freebsd.org cluster, it has become rather apparent that convenience of working with a pure-source environment has regressed considerably since 2008 when we switched from cvs. As an example of inconvenient, take this clean 24 core system with 24 GB ram. Suppose I have a problem that I want to do a bisection search to see when it first appeared (right there, freebsd-update is excluded). # rm -rf /usr/local/* /var/db/pkg/* /var/db/ports/* then a config-recursive, taking default options to match packages: # cd /usr/ports/devel/subversion; time make config-recursive (immediately hitting enter) 41.693u 4.778s 0:37.12 125.1% 30872+507k 185+13771io 360pf+0w 37 seconds just to configure the build options. # cd /usr/ports/devel/subversion; time make
svn commit: r252119 - head/release/doc/en_US.ISO8859-1/relnotes
Author: gjb Date: Sun Jun 23 19:47:59 2013 New Revision: 252119 URL: http://svnweb.freebsd.org/changeset/base/252119 Log: Add missing copyright years. 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 Sun Jun 23 16:58:59 2013(r252118) +++ head/release/doc/en_US.ISO8859-1/relnotes/article.xml Sun Jun 23 19:47:59 2013(r252119) @@ -25,6 +25,9 @@ year2008/year year2009/year year2010/year +year2011/year +year2012/year +year2013/year holder role=mailto:d...@freebsd.org;The os; Documentation Project/holder /copyright ___ 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 Sun, Jun 23, 2013 at 12:30 PM, Peter Wemm pe...@wemm.org wrote: [..] I still want svnup to be finished and imported. Just like when we had cvs and csup, they're targeted at different people. One clarification. svnlite is intended to be a lighter weight alternative to the devel/subversion port, not to eliminate the port. Things like svn.freebsd.org and the mirrors could never use svnlite and will always run the port because they need the py-subversion API library or the apache DAV plugins. That isn't something I could ever imagine making its way into svnlite - it wasn't the point. For what its worth, the freebsd.org cluster has been mostly running svn-1.8.x for over a week, including svn.freebsd.org and all but one mirror. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV ___ 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: r252121 - in head/release/doc: en_US.ISO8859-1/errata share/xml
Author: gjb Date: Sun Jun 23 20:19:00 2013 New Revision: 252121 URL: http://svnweb.freebsd.org/changeset/base/252121 Log: Add a new macro, release.current.release, to denote the head/ branch with the -RELEASE suffix. This fixes the incorrect text on the -CURRENT errata page from showing '10.0-CURRENT' followed by 'until 9.1-RELEASE is released.' Modified: head/release/doc/en_US.ISO8859-1/errata/article.xml head/release/doc/share/xml/release.ent Modified: head/release/doc/en_US.ISO8859-1/errata/article.xml == --- head/release/doc/en_US.ISO8859-1/errata/article.xml Sun Jun 23 20:09:58 2013(r252120) +++ head/release/doc/en_US.ISO8859-1/errata/article.xml Sun Jun 23 20:19:00 2013(r252121) @@ -57,7 +57,7 @@ os;./para paraThis errata document for os; release; - will be maintained until the release of os; release.next;./para + will be maintained until the release of os; release.current.release;./para /abstract sect1 id=intro Modified: head/release/doc/share/xml/release.ent == --- head/release/doc/share/xml/release.ent Sun Jun 23 20:09:58 2013 (r252120) +++ head/release/doc/share/xml/release.ent Sun Jun 23 20:19:00 2013 (r252121) @@ -6,7 +6,9 @@ !-- Version of the OS we're describing. This needs to be updated with each new release. -- -!ENTITY release.current 10.0-CURRENT +!ENTITY release.current.version 10.0 +!ENTITY release.current release.current.version;-CURRENT +!ENTITY release.current.release release.current.version;-RELEASE !-- The previous version used for comparison in the What's New section. For -CURRENT, we might point back to the last ___ 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: r252123 - head/sys/dev/usb/serial
Author: thomas
Date: Sun Jun 23 20:19:51 2013
New Revision: 252123
URL: http://svnweb.freebsd.org/changeset/base/252123
Log:
Fix minor typo in comment
Modified:
head/sys/dev/usb/serial/uark.c
head/sys/dev/usb/serial/umcs.h
Modified: head/sys/dev/usb/serial/uark.c
==
--- head/sys/dev/usb/serial/uark.c Sun Jun 23 20:19:05 2013
(r252122)
+++ head/sys/dev/usb/serial/uark.c Sun Jun 23 20:19:51 2013
(r252123)
@@ -92,6 +92,7 @@ struct uark_softc {
uint8_t sc_msr;
uint8_t sc_lsr;
+ uint8_t sc_irda;/* Set to 1 for IrDA */
};
/* prototypes */
@@ -173,8 +174,12 @@ MODULE_DEPEND(uark, ucom, 1, 1, 1);
MODULE_DEPEND(uark, usb, 1, 1, 1);
MODULE_VERSION(uark, 1);
+#define UARK_TYPE_SERIAL 0
+#define UARK_TYPE_IRDA 1
+
static const STRUCT_USB_HOST_ID uark_devs[] = {
- {USB_VPI(USB_VENDOR_ARKMICRO, USB_PRODUCT_ARKMICRO_ARK3116, 0)},
+ {USB_VPI(USB_VENDOR_ARKMICRO, USB_PRODUCT_ARKMICRO_ARK3116,
UARK_TYPE_SERIAL)},
+ {USB_VPI(USB_VENDOR_ARKMICRO2, USB_PRODUCT_ARKMICRO2_ARK3118,
UARK_TYPE_IRDA)},
};
static int
@@ -207,6 +212,7 @@ uark_attach(device_t dev)
ucom_ref(sc-sc_super_ucom);
sc-sc_udev = uaa-device;
+ sc-sc_irda = (USB_GET_DRIVER_INFO (uaa) == UARK_TYPE_IRDA);
iface_index = UARK_IFACE_INDEX;
error = usbd_transfer_setup
@@ -378,6 +384,15 @@ uark_cfg_param(struct ucom_softc *ucom,
uint32_t speed = t-c_ospeed;
uint16_t data;
+ if (!(sc-sc_irda)) {
+ uark_cfg_write(sc, 0xb, 0);
+ } else {
+ uark_cfg_write(sc, 0xb, 1);
+ uark_cfg_write(sc, 0xc, 0);
+ uark_cfg_write(sc, 0xd, 0x41);
+ uark_cfg_write(sc, 0xa, 1);
+ }
+
/*
* NOTE: When reverse computing the baud rate from the data all
* allowed baud rates are within 3% of the initial baud rate.
@@ -419,6 +434,10 @@ uark_cfg_param(struct ucom_softc *ucom,
}
uark_cfg_write(sc, 3, 0x00);
uark_cfg_write(sc, 3, data);
+
+ uark_cfg_write(sc, 0xe, 0);
+ if (sc-sc_irda)
+ uark_cfg_write (sc, 9, 0);
}
static void
Modified: head/sys/dev/usb/serial/umcs.h
==
--- head/sys/dev/usb/serial/umcs.h Sun Jun 23 20:19:05 2013
(r252122)
+++ head/sys/dev/usb/serial/umcs.h Sun Jun 23 20:19:51 2013
(r252123)
@@ -596,7 +596,7 @@
#defineMCS7840_UART_LSR_RHROVERRUN 0x02/* Data FIFO/register
overflow */
#defineMCS7840_UART_LSR_PARITYERR 0x04/* Parity error */
#defineMCS7840_UART_LSR_FRAMEERR 0x10/* Framing error */
-#defineMCS7840_UART_LSR_BREAKERR 0x20/* BREAK sigmal
received */
+#defineMCS7840_UART_LSR_BREAKERR 0x20/* BREAK signal
received */
#defineMCS7840_UART_LSR_THREMPTY 0x40/* THR register is
empty,
* ready for transmit */
#defineMCS7840_UART_LSR_HASERR 0x80/* Has error in
receiver FIFO */
___
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: r252124 - head/release/doc/en_US.ISO8859-1/errata
Author: gjb Date: Sun Jun 23 20:20:34 2013 New Revision: 252124 URL: http://svnweb.freebsd.org/changeset/base/252124 Log: Rewrap after previous commit. Modified: head/release/doc/en_US.ISO8859-1/errata/article.xml Modified: head/release/doc/en_US.ISO8859-1/errata/article.xml == --- head/release/doc/en_US.ISO8859-1/errata/article.xml Sun Jun 23 20:19:51 2013(r252123) +++ head/release/doc/en_US.ISO8859-1/errata/article.xml Sun Jun 23 20:20:34 2013(r252124) @@ -56,8 +56,8 @@ should always be consulted before installing this version of os;./para -paraThis errata document for os; release; - will be maintained until the release of os; release.current.release;./para +paraThis errata document for os; release; will be maintained + until the release of os; release.current.release;./para /abstract sect1 id=intro ___ 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: r252125 - head/sys/dev/usb/serial
Author: thomas
Date: Sun Jun 23 20:22:49 2013
New Revision: 252125
URL: http://svnweb.freebsd.org/changeset/base/252125
Log:
Revert previous change to uark.c (restore previous rev), which was
committed by mistake.
Replaced:
- copied unchanged from r250749, head/sys/dev/usb/serial/uark.c
Directory Properties:
head/sys/dev/usb/serial/uark.c (props changed)
Copied: head/sys/dev/usb/serial/uark.c (from r250749,
head/sys/dev/usb/serial/uark.c)
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/sys/dev/usb/serial/uark.c Sun Jun 23 20:22:49 2013
(r252125, copy of r250749, head/sys/dev/usb/serial/uark.c)
@@ -0,0 +1,468 @@
+/* $OpenBSD: uark.c,v 1.1 2006/08/14 08:30:22 jsg Exp $*/
+
+/*
+ * Copyright (c) 2006 Jonathan Gray j...@openbsd.org
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ * $FreeBSD$
+ */
+
+/*
+ * NOTE: all function names beginning like uark_cfg_ can only
+ * be called from within the config thread function !
+ */
+
+
+#include sys/stdint.h
+#include sys/stddef.h
+#include sys/param.h
+#include sys/queue.h
+#include sys/types.h
+#include sys/systm.h
+#include sys/kernel.h
+#include sys/bus.h
+#include sys/module.h
+#include sys/lock.h
+#include sys/mutex.h
+#include sys/condvar.h
+#include sys/sysctl.h
+#include sys/sx.h
+#include sys/unistd.h
+#include sys/callout.h
+#include sys/malloc.h
+#include sys/priv.h
+
+#include dev/usb/usb.h
+#include dev/usb/usbdi.h
+#include dev/usb/usbdi_util.h
+#include dev/usb/usbhid.h
+#include usbdevs.h
+
+#defineUSB_DEBUG_VAR usb_debug
+#include dev/usb/usb_debug.h
+#include dev/usb/usb_process.h
+
+#include dev/usb/serial/usb_serial.h
+
+#defineUARK_BUF_SIZE 1024/* bytes */
+
+#defineUARK_SET_DATA_BITS(x) ((x) - 5)
+
+#defineUARK_PARITY_NONE0x00
+#defineUARK_PARITY_ODD 0x08
+#defineUARK_PARITY_EVEN0x18
+
+#defineUARK_STOP_BITS_10x00
+#defineUARK_STOP_BITS_20x04
+
+#defineUARK_BAUD_REF 300
+
+#defineUARK_WRITE 0x40
+#defineUARK_READ 0xc0
+
+#defineUARK_REQUEST0xfe
+
+#defineUARK_CONFIG_INDEX 0
+#defineUARK_IFACE_INDEX0
+
+enum {
+ UARK_BULK_DT_WR,
+ UARK_BULK_DT_RD,
+ UARK_N_TRANSFER,
+};
+
+struct uark_softc {
+ struct ucom_super_softc sc_super_ucom;
+ struct ucom_softc sc_ucom;
+
+ struct usb_xfer *sc_xfer[UARK_N_TRANSFER];
+ struct usb_device *sc_udev;
+ struct mtx sc_mtx;
+
+ uint8_t sc_msr;
+ uint8_t sc_lsr;
+};
+
+/* prototypes */
+
+static device_probe_t uark_probe;
+static device_attach_t uark_attach;
+static device_detach_t uark_detach;
+static void uark_free_softc(struct uark_softc *);
+
+static usb_callback_t uark_bulk_write_callback;
+static usb_callback_t uark_bulk_read_callback;
+
+static voiduark_free(struct ucom_softc *);
+static voiduark_start_read(struct ucom_softc *);
+static voiduark_stop_read(struct ucom_softc *);
+static voiduark_start_write(struct ucom_softc *);
+static voiduark_stop_write(struct ucom_softc *);
+static int uark_pre_param(struct ucom_softc *, struct termios *);
+static voiduark_cfg_param(struct ucom_softc *, struct termios *);
+static voiduark_cfg_get_status(struct ucom_softc *, uint8_t *,
+ uint8_t *);
+static voiduark_cfg_set_break(struct ucom_softc *, uint8_t);
+static voiduark_cfg_write(struct uark_softc *, uint16_t, uint16_t);
+static voiduark_poll(struct ucom_softc *ucom);
+
+static const struct usb_config
+ uark_xfer_config[UARK_N_TRANSFER] = {
+
+ [UARK_BULK_DT_WR] = {
+ .type = UE_BULK,
+ .endpoint = UE_ADDR_ANY,
+ .direction = UE_DIR_OUT,
+ .bufsize = UARK_BUF_SIZE,
+ .flags = {.pipe_bof = 1,.force_short_xfer = 1,},
+ .callback = uark_bulk_write_callback,
+ },
+
+ [UARK_BULK_DT_RD] = {
+ .type = UE_BULK,
+ .endpoint = UE_ADDR_ANY,
+ .direction = UE_DIR_IN,
+ .bufsize =
svn commit: r252126 - head/release/doc/en_US.ISO8859-1/errata
Author: gjb Date: Sun Jun 23 20:24:43 2013 New Revision: 252126 URL: http://svnweb.freebsd.org/changeset/base/252126 Log: Trim copyright years, and add the current year. Modified: head/release/doc/en_US.ISO8859-1/errata/article.xml Modified: head/release/doc/en_US.ISO8859-1/errata/article.xml == --- head/release/doc/en_US.ISO8859-1/errata/article.xml Sun Jun 23 20:22:49 2013(r252125) +++ head/release/doc/en_US.ISO8859-1/errata/article.xml Sun Jun 23 20:24:43 2013(r252126) @@ -28,12 +28,7 @@ pubdate$FreeBSD$/pubdate copyright - year2000/year - year2001/year - year2002/year - year2003/year - year2004/year - year2005/year + year2013/year holder role=mailto:d...@freebsd.org;The os; Documentation Project/holder /copyright ___ 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: r252127 - head/share/mk
Author: eadler
Date: Sun Jun 23 20:34:54 2013
New Revision: 252127
URL: http://svnweb.freebsd.org/changeset/base/252127
Log:
Remove variable added by ru@ in r94940 that is no longer used by source or
ports in share/mk/sys.mk
PR: conf/155737
Reviewed by: ed (two years ago!)
Exp-Run by: bdrewery
Modified:
head/share/mk/sys.mk
Modified: head/share/mk/sys.mk
==
--- head/share/mk/sys.mkSun Jun 23 20:24:43 2013(r252126)
+++ head/share/mk/sys.mkSun Jun 23 20:34:54 2013(r252127)
@@ -332,10 +332,6 @@ SHELL= ${__MAKE_SHELL}
.SHELL: path=${__MAKE_SHELL}
.endif
-# Default executable format
-# XXX hint for bsd.port.mk
-OBJFORMAT?=elf
-
# Tell bmake to expand -V VAR by default
.MAKE.EXPAND_VARIABLES= yes
___
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: r252129 - in head: . gnu/lib/libdialog
Author: bapt
Date: Sun Jun 23 21:59:52 2013
New Revision: 252129
URL: http://svnweb.freebsd.org/changeset/base/252129
Log:
Bump shlib for dialog because ABI has changed when version 1.2 was imported
Reviewed by: kib
Modified:
head/ObsoleteFiles.inc
head/gnu/lib/libdialog/Makefile
Modified: head/ObsoleteFiles.inc
==
--- head/ObsoleteFiles.inc Sun Jun 23 21:58:34 2013(r252128)
+++ head/ObsoleteFiles.inc Sun Jun 23 21:59:52 2013(r252129)
@@ -38,6 +38,9 @@
# xargs -n1 | sort | uniq -d;
# done
+# 20130623: dialog update from 1.1 to 1.2
+OLD_LIBS+=usr/lib/libdialog.so.7
+OLD_LIBS+=usr/lib32/libdialog.so.7
# 20130616: vfs_mounted.9 removed
OLD_FILES+=usr/share/man/man9/vfs_mount.9.gz
# 20130614: remove CVS from base
Modified: head/gnu/lib/libdialog/Makefile
==
--- head/gnu/lib/libdialog/Makefile Sun Jun 23 21:58:34 2013
(r252128)
+++ head/gnu/lib/libdialog/Makefile Sun Jun 23 21:59:52 2013
(r252129)
@@ -3,7 +3,7 @@
DIALOG=${.CURDIR}/../../../contrib/dialog
LIB= dialog
-SHLIB_MAJOR= 7
+SHLIB_MAJOR= 8
SRCS= argv.c arrows.c buildlist.c buttons.c calendar.c checklist.c \
columns.c dlg_keys.c editbox.c fselect.c formbox.c guage.c \
help.c inputbox.c inputstr.c menubox.c mixedform.c \
___
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 Sun, 23 Jun 2013, I wrote: I thought of lots of variations, but couldn't find one that works perfectly. One idea (that goes with the sign check on the low 32 bits) is to use a misaligned add to memory to copy the 31st bit as a carry bit to the the high word. The value of the counter is supposed to be [unsigned value of low 32 bits] + [unsigned value of next 24 bits] 31 (high 8 bits not used) at all times, with the 31st bit zero at most times so that the the carry operation is rarely executed. This format is only slightly confusing for debugging (it basically has 2 31st bits, with the one in the low 32 bits rarely used). This format can be updated using something like: The above doesn't work if it is preempted -- then it might add do the carry operation more than once. But it is easy to lock using cmpxchg or disabling interrupts. Disabling interrupts requires only small code: ... Another idea is to use the high bits of the high word to encode state. They can be set atomically enough using addl/andl/orl/xorl since they are per-CPU. I couldn't quite get this to work. You could increment Here is a combined version. It uses the old shift trick instead of disabling interrupts for locking. The shift trick is not often used since it doesn't work for SMP. It works here since the counters are per-CPU: addl%1,%%fs:(%0)# only small 32-bit increments supported jns 8f sar $1,%%fs:7(%0) # hi 8 bits are for lock; init to 0xfe jc 8f # already locked addl$0x80,%%fs:3(%0)# misaligned memory access movb$0xfe,%%fs:7(%0)# unlock 8: ; Since the locked case is rarely executed and the code for it is only inline for convenience, the shortest code should be preferred and that is the simpler version that disables interrupts. Unless the lock byte can be exploited in the fetching and zeroing code. I don't see how it can be, since this type of locking only works for a single CPU. 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: r252138 - head/usr.sbin/gssd
Author: rmacklem
Date: Mon Jun 24 02:19:23 2013
New Revision: 252138
URL: http://svnweb.freebsd.org/changeset/base/252138
Log:
Add a new -o option to the gssd which forces gss_init_sec_context()
to use DES and the associated old style GSS initialization token.
This appears to be required for some non-FreeBSD servers to
get a kerberized NFS mount to work. Also, ignore some signals when daemonized,
which might fix the gssd from disappearing without leaving a core dump.
Given the tight timeframe for the FreeBSD9.2 release, I have
committed this while waiting for code review. I will commit
changes recommended by the review in a separate commit.
Reviewed by: dfr (pending)
MFC after:10 days
Modified:
head/usr.sbin/gssd/gssd.c
Modified: head/usr.sbin/gssd/gssd.c
==
--- head/usr.sbin/gssd/gssd.c Mon Jun 24 01:09:28 2013(r252137)
+++ head/usr.sbin/gssd/gssd.c Mon Jun 24 02:19:23 2013(r252138)
@@ -42,6 +42,7 @@ __FBSDID($FreeBSD$);
#include krb5.h
#endif
#include pwd.h
+#include signal.h
#include stdarg.h
#include stdio.h
#include stdlib.h
@@ -73,11 +74,26 @@ int debug_level;
static char ccfile_dirlist[PATH_MAX + 1], ccfile_substring[NAME_MAX + 1];
static char pref_realm[1024];
static int verbose;
+static int use_old_des;
+#ifndef WITHOUT_KERBEROS
+/* 1.2.752.43.13.14 */
+static gss_OID_desc gss_krb5_set_allowable_enctypes_x_desc =
+{6, (void *) \x2a\x85\x70\x2b\x0d\x0e};
+static gss_OID GSS_KRB5_SET_ALLOWABLE_ENCTYPES_X =
+gss_krb5_set_allowable_enctypes_x_desc;
+static gss_OID_desc gss_krb5_mech_oid_x_desc =
+{9, (void *) \x2a\x86\x48\x86\xf7\x12\x01\x02\x02 };
+static gss_OID GSS_KRB5_MECH_OID_X =
+gss_krb5_mech_oid_x_desc;
+#endif
static void gssd_load_mech(void);
static int find_ccache_file(const char *, uid_t, char *);
static int is_a_valid_tgt_cache(const char *, uid_t, int *, time_t *);
static void gssd_verbose_out(const char *, ...);
+#ifndef WITHOUT_KERBEROS
+static OM_uint32 gssd_get_user_cred(OM_uint32 *, uid_t, gss_cred_id_t *);
+#endif
extern void gssd_1(struct svc_req *rqstp, SVCXPRT *transp);
extern int gssd_syscall(char *path);
@@ -103,11 +119,22 @@ main(int argc, char **argv)
pref_realm[0] = '\0';
debug = 0;
verbose = 0;
- while ((ch = getopt(argc, argv, dvs:c:r:)) != -1) {
+ while ((ch = getopt(argc, argv, dovs:c:r:)) != -1) {
switch (ch) {
case 'd':
debug_level++;
break;
+ case 'o':
+#ifndef WITHOUT_KERBEROS
+ /*
+* Force use of DES and the old type of GSSAPI token.
+*/
+ use_old_des = 1;
+#else
+ errx(1, This option not available when built
+without MK_KERBEROS\n);
+#endif
+ break;
case 'v':
verbose = 1;
break;
@@ -149,8 +176,12 @@ main(int argc, char **argv)
gssd_load_mech();
- if (!debug_level)
+ if (!debug_level) {
daemon(0, 0);
+ signal(SIGINT, SIG_IGN);
+ signal(SIGQUIT, SIG_IGN);
+ signal(SIGHUP, SIG_IGN);
+ }
memset(sun, 0, sizeof sun);
sun.sun_family = AF_LOCAL;
@@ -336,7 +367,14 @@ gssd_init_sec_context_1_svc(init_sec_con
gss_ctx_id_t ctx = GSS_C_NO_CONTEXT;
gss_name_t name = GSS_C_NO_NAME;
char ccname[PATH_MAX + 5 + 1], *cp, *cp2;
- int gotone;
+ int gotone, gotcred;
+ OM_uint32 min_stat;
+#ifndef WITHOUT_KERBEROS
+ gss_buffer_desc principal_desc;
+ char enctype[sizeof(uint32_t)];
+ int key_enctype;
+ OM_uint32 maj_stat;
+#endif
memset(result, 0, sizeof(*result));
if (ccfile_dirlist[0] != '\0' argp-cred == 0) {
@@ -411,7 +449,46 @@ gssd_init_sec_context_1_svc(init_sec_con
return (TRUE);
}
}
+ gotcred = 0;
+#ifndef WITHOUT_KERBEROS
+ if (use_old_des != 0) {
+ if (cred == GSS_C_NO_CREDENTIAL) {
+ /* Acquire a credential for the uid. */
+ maj_stat = gssd_get_user_cred(min_stat, argp-uid,
+ cred);
+ if (maj_stat == GSS_S_COMPLETE)
+ gotcred = 1;
+ else
+ gssd_verbose_out(gssd_init_sec_context:
+ get user cred failed uid=%d major=0x%x
+ minor=%d\n, (int)argp-uid,
+ (unsigned int)maj_stat, (int)min_stat);
+ }
+ if (cred != GSS_C_NO_CREDENTIAL) {
+ key_enctype = ETYPE_DES_CBC_CRC;
+
svn commit: r252139 - head/usr.sbin/gssd
Author: rmacklem Date: Mon Jun 24 02:24:22 2013 New Revision: 252139 URL: http://svnweb.freebsd.org/changeset/base/252139 Log: Document the -o option added by r252138. MFC after:10 days Modified: head/usr.sbin/gssd/gssd.8 Modified: head/usr.sbin/gssd/gssd.8 == --- head/usr.sbin/gssd/gssd.8 Mon Jun 24 02:19:23 2013(r252138) +++ head/usr.sbin/gssd/gssd.8 Mon Jun 24 02:24:22 2013(r252139) @@ -25,7 +25,7 @@ .\ .\ $FreeBSD$ .\ -.Dd June 5, 2013 +.Dd June 23, 2013 .Dt GSSD 8 .Os .Sh NAME @@ -34,6 +34,7 @@ .Sh SYNOPSIS .Nm .Op Fl d +.Op Fl o .Op Fl v .Op Fl s Ar dir-list .Op Fl c Ar file-substring @@ -50,6 +51,10 @@ Run in debug mode. In this mode, .Nm will not fork when it starts. +.It Fl o +Force use of DES and the associated old style GSS-API initialization token. +This may be required to make kerberized NFS mounts work against some +non-FreeBSD NFS servers. .It Fl v Run in verbose mode. In this mode, ___ 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: r252141 - head/sys/netinet6
Author: qingli
Date: Mon Jun 24 05:01:13 2013
New Revision: 252141
URL: http://svnweb.freebsd.org/changeset/base/252141
Log:
Delete the nd6 entries associated with an off-link prefix
if the same prefix cannot be found on an alternative
interface.
Reviewed by: hrs
MFC after:1 week
Modified:
head/sys/netinet6/nd6_rtr.c
Modified: head/sys/netinet6/nd6_rtr.c
==
--- head/sys/netinet6/nd6_rtr.c Mon Jun 24 05:00:31 2013(r252140)
+++ head/sys/netinet6/nd6_rtr.c Mon Jun 24 05:01:13 2013(r252141)
@@ -1720,6 +1720,7 @@ nd6_prefix_offlink(struct nd_prefix *pr)
}
}
error = a_failure;
+ a_failure = 1;
if (error == 0) {
pr-ndpr_stateflags = ~NDPRF_ONLINK;
@@ -1758,7 +1759,8 @@ nd6_prefix_offlink(struct nd_prefix *pr)
opr-ndpr_prefix.sin6_addr),
opr-ndpr_plen, if_name(ifp),
if_name(opr-ndpr_ifp), e));
- }
+ } else
+ a_failure = 0;
}
}
} else {
@@ -1770,6 +1772,10 @@ nd6_prefix_offlink(struct nd_prefix *pr)
if_name(ifp), error));
}
+ if (a_failure)
+ lltable_prefix_free(AF_INET6, (struct sockaddr *)sa6,
+ (struct sockaddr *)mask6, LLE_STATIC);
+
return (error);
}
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r252143 - head/sys/dev/usb/net
Author: yongari
Date: Mon Jun 24 05:18:31 2013
New Revision: 252143
URL: http://svnweb.freebsd.org/changeset/base/252143
Log:
When RX checksum offloading is active, AX88772B will prepend a
checksum header. The header contains a received frame length but
the defined length for AX88772B is different with other ASIX
controllers. When the RX checksum is off, AX88772B controller does
not prepend a checksum header so driver has to use normal header
length mask.
This change should fix RX errors when RX checksum offloading is
off.
Tested by:kevlo
MFC After:1 week
Modified:
head/sys/dev/usb/net/if_axe.c
Modified: head/sys/dev/usb/net/if_axe.c
==
--- head/sys/dev/usb/net/if_axe.c Mon Jun 24 05:03:42 2013
(r252142)
+++ head/sys/dev/usb/net/if_axe.c Mon Jun 24 05:18:31 2013
(r252143)
@@ -1351,15 +1351,14 @@ axe_init(struct usb_ether *ue)
if (AXE_IS_178_FAMILY(sc)) {
sc-sc_flags = ~(AXE_FLAG_STD_FRAME | AXE_FLAG_CSUM_FRAME);
- if ((sc-sc_flags AXE_FLAG_772B) != 0)
- sc-sc_lenmask = AXE_CSUM_HDR_LEN_MASK;
- else
- sc-sc_lenmask = AXE_HDR_LEN_MASK;
if ((sc-sc_flags AXE_FLAG_772B) != 0
- (ifp-if_capenable IFCAP_RXCSUM) != 0)
+ (ifp-if_capenable IFCAP_RXCSUM) != 0) {
+ sc-sc_lenmask = AXE_CSUM_HDR_LEN_MASK;
sc-sc_flags |= AXE_FLAG_CSUM_FRAME;
- else
+ } else {
+ sc-sc_lenmask = AXE_HDR_LEN_MASK;
sc-sc_flags |= AXE_FLAG_STD_FRAME;
+ }
}
/* Configure TX/RX checksum offloading. */
___
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: r252121 - in head/release/doc: en_US.ISO8859-1/errata share/xml
Glen Barber g...@freebsd.org wrote in 201306232019.r5nkj1gz064...@svn.freebsd.org: gj Author: gjb gj Date: Sun Jun 23 20:19:00 2013 gj New Revision: 252121 gj URL: http://svnweb.freebsd.org/changeset/base/252121 gj gj Log: gj Add a new macro, release.current.release, to denote the head/ branch gj with the -RELEASE suffix. This fixes the incorrect text on the -CURRENT gj errata page from showing '10.0-CURRENT' followed by 'until 9.1-RELEASE is gj released.' No, please revert this. release.next is correct, but the value cannot be defined meaningfully for a branch which has no release yet. Errata never works for head, so please leave it as-is. This errata document for FreeBSD 10.0-CURRENT will be maintained until the release of FreeBSD 10.0-RELEASE is still incorrect. -- Hiroki pgps2FUnADyaO.pgp Description: PGP signature
