Re: Reviewing a FAQ change about LORs
on 09/02/2013 01:51 Eitan Adler said the following: On 8 February 2013 16:31, Ian Lepore i...@freebsd.org wrote: On Thu, 2013-02-07 at 19:32 -0500, Eitan Adler wrote: Does someone here mind reviewing http://www.freebsd.org/cgi/query-pr.cgi?pr=174226 for correctness. Please feel free to post alternate diffs as a reply as well. Does it make sense to reference a web page on LOR status that hasn't been updated in four years? I was unaware of this, which is the reason I asked for review. ;) Is there an updated page or is there no such service anymore? I suspect that the list of LORs doesn't get updated because we don't get many new LORs that here are to stay. Those old LORs are well known, harmless and hard to fix. We try to not introduce any new LORs of that kind. So the new LORs are either not introduced or getting fixed. Hence no strong need for an up-to-date list. It also seems that the interest in LORs diminished over the years as FreeBSD SMP / locking stabilized to the point of being taken for granted (as opposed to the early SMP days). So nobody (except developers adding new locks) really looks at LORs until a deadlock/livelock is really hit. On the other hand, the referenced page looks like new reports are welcome and get actually processes, which is not true. Also, the list of fixed/patched LORs has no practical use. Additionally, many LORs there are duplicates (e.g. a LOR between devfs and any other fs during unmount is replicated for many values of other fs). There also seem to be some fixed LORs, etc. It probably would make sense to reference some static page with a list of some well known LORs. But that page doesn't seem to be very useful. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Reviewing a FAQ change about LORs
On 02/09/2013 12:51 AM, Eitan Adler wrote: On 8 February 2013 16:31, Ian Lepore i...@freebsd.org wrote: On Thu, 2013-02-07 at 19:32 -0500, Eitan Adler wrote: Does someone here mind reviewing http://www.freebsd.org/cgi/query-pr.cgi?pr=174226 for correctness. Please feel free to post alternate diffs as a reply as well. Does it make sense to reference a web page on LOR status that hasn't been updated in four years? I was unaware of this, which is the reason I asked for review. ;) Is there an updated page or is there no such service anymore? Hi Sorry I didn't check this either. There seems to be no updated page on LOR's so maybe just remove the URL? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Request for review, time_pps_fetch() enhancement
On Wed, Feb 06, 2013 at 05:58:30PM +0200, Konstantin Belousov wrote:
On Tue, Feb 05, 2013 at 09:41:38PM -0700, Ian Lepore wrote:
I'd like feedback on the attached patch, which adds support to our
time_pps_fetch() implementation for the blocking behaviors described in
section 3.4.3 of RFC 2783. The existing implementation can only return
the most recently captured data without blocking. These changes add the
ability to block (forever or with timeout) until a new event occurs.
Index: sys/kern/kern_tc.c
===
--- sys/kern/kern_tc.c (revision 246337)
+++ sys/kern/kern_tc.c (working copy)
@@ -1446,6 +1446,50 @@
* RFC 2783 PPS-API implementation.
*/
+static int
+pps_fetch(struct pps_fetch_args *fapi, struct pps_state *pps)
+{
[snip]
+ aseq = pps-ppsinfo.assert_sequence;
+ cseq = pps-ppsinfo.clear_sequence;
+ while (aseq == pps-ppsinfo.assert_sequence
+ cseq == pps-ppsinfo.clear_sequence) {
Note that compilers are allowed to optimize these accesses even over
the sequential point, which is the tsleep() call. Only accesses to
volatile objects are forbidden to be rearranged.
I suggest to add volatile casts to pps in the loop condition.
The memory pointed to by pps is global (other code may have a pointer to
it); therefore, the compiler must assume that the tsleep() call (which
invokes code in a different compilation unit) may modify it.
Because volatile does not make concurrent access by multiple threads
defined either, adding it here only seems to slow down the code
(potentially).
+ err = tsleep(pps, PCATCH, ppsfch, timo);
+ if (err == EWOULDBLOCK fapi-timeout.tv_sec == -1) {
+ continue;
+ } else if (err != 0) {
+ return (err);
+ }
+ }
+ }
--
Jilles Tjoelker
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Request for review, time_pps_fetch() enhancement
... why aren't you using atomics? or read/write barriers? Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Eliminating a warning in sys/boot
So, this is not a valid warning in our universe and I'd like to silence it when compiling sys/boot as printf(9) and sprintf(9) supports this format. How can we silence this warning for the FreeBSD universe? === efi/libefi (all) In file included from efinet.c:39: /home/sbruno/fbsd_head/sys/boot/efi/libefi/../../common/dev_net.c:328:19: warning: invalid conversion specifier 'D' [-Wformat-invalid-specifier] sprintf(temp, %6D, d-myea, :); SEan signature.asc Description: This is a digitally signed message part
