freebsd-hackers Digest, Vol 365, Issue 7
freebsd-hac...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
or, via email, send a message with subject or body 'help' to
freebsd-hac...@freebsd.org
You can reach the person managing the list at
freebsd-ha...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-hackers digest..."
Today's Topics:
1. Re: periodically save current time to time-of-day hardware
(Peter Jeremy)
2. Re: Compiling kernel with gcc43 (Mario Lobo)
3. Re: Panic in vm_map_stack (Attilio Rao)
4. Re: periodically save current time to time-of-day hardware
(Dag-Erling Sm?rgrav)
5. Re: periodically save current time to time-of-day hardware
(Dag-Erling Sm?rgrav)
6. Re: Compiling kernel with gcc43 (jhell)
----------------------------------------------------------------------
Message: 1
Date: Sat, 27 Mar 2010 08:30:23 +1100
From: Peter Jeremy <peter...@acm.org>
Subject: Re: periodically save current time to time-of-day hardware
To: Dag-Erling Sm?rgrav <d...@des.no>
Cc: freebsd...@FreeBSD.org, Andriy Gapon <a...@icyb.net.ua>
Message-ID: <20100326213...@server.vk2pj.dyndns.org>
Content-Type: text/plain; charset="iso-8859-1"
On 2010-Mar-26 17:30:14 +0100, Dag-Erling Smørgrav <d...@des.no> wrote:
>Andriy Gapon <a...@icyb.net.ua> writes:
>> Dag-Erling Smørgrav <d...@des.no> writes:
>> > Andriy Gapon <a...@icyb.net.ua> writes:
>> > > Also, I am aware that the period should be configurable (sysctl).
>> > Why?
>> Because there would always be someone who would want a different value :)
>> > Although I can see an argument for a sysctl to turn it on or off.
>> Good idea.
>
>You can combine the two - P == 0 means "don't save", P > 0 means "save
>every P minutes".
>
>> > IIRC, Linux saves the clock at shutdown, and every 11 minutes if and
>> > only if the system clock is synchronized to an external reference.
At least some versions of Linux also save a RTC drift approximation
and "last set" timestamp whenever the RTC is updated. This allows the
kernel to better set the system clock from the RTC at boot (ie, our
inittodr()). The downside is that this needs to store 8-16 bytes of
state somewhere non-volatile. Linux does this using an external
program and a file - but finding a location for a regularly updated
file that is read very early in the rc.d sequence might be problematic.
>> I know how to add a shutdown hook (event handler), but I don't know how to check
>> if time synchronization is taking place.
>
>adjtime() / adjtimex() sets a flag. I'm not sure if (or how) the flag
>is cleared when synchronization stops (i.e. /etc/rc.d/ntpd stop);
>perhaps the simplest solution is to set a T = monotime() every time
>adjtime() is called, and check that monotime() - (T * 60) < (P * 60).
It's not especially important how regularly the RTC is updated, just
that it _is_ updated. This suggests that an alternative approach
would be for adjtime() / ntp_adjtime() to directly call resettodr() if
it's more than P minutes since resettodr() was last called.
As a general comment, whilst resettodr() needs to be serialised, there
is no need for it to block. If thread B wants to call resettodr()
whilst thread A is doing so, thread B can just skip the call because
calling resettodr() twice in quick succession has no benefit. This
means the serialisation can be a simple atomic_readandclear_int().
--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20100326/d14839cf/attachment-0001.pgp
------------------------------
Message: 2
Date: Fri, 26 Mar 2010 18:40:49 +0000
From: Mario Lobo <lo...@bsd.com.br>
Subject: Re: Compiling kernel with gcc43
To: freebsd...@freebsd.org
Cc: Garrett Cooper <yane...@gmail.com>, Jille Timmermans
<ji...@quis.cx>
Message-ID: <20100326184...@bsd.com.br>
Content-Type: Text/Plain; charset="iso-8859-1"
On Friday 26 March 2010 13:01:21 Jille Timmermans wrote:
> Op 25-3-2010 18:31, Garrett Cooper schreef:
> > -Wno-error .
> > -Garrett
>
> I tried building world with it; but it doesn't seem to work :(
>
> [quis@istud /usr/src]$ CFLAGS="-Wno-error -Garrett" make buildworld
> [snip]
> cc: unrecognized option '-Garrett'
>
> ;)
>
That's right. It doesn't. But the kernel does !
I am trying VBox port now. Tweaks all over the place but movin on.
Post results when done.
By the way: WTF is the "-Garrett" option?
If it's not a joke from you, it won't work with anything.
--
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] (99,7% winfoes FREE)
------------------------------
Message: 3
Date: Fri, 26 Mar 2010 22:40:45 +0100
From: Attilio Rao <att...@freebsd.org>
Subject: Re: Panic in vm_map_stack
To: pluknet <plu...@gmail.com>
Cc: Tom Judge <t...@tomjudge.com>, Kostik Belousov
<kost...@gmail.com>, freebsd...@freebsd.org
Message-ID:
<3bbf2fe11003261440x15d...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2010/3/26 pluknet <plu...@gmail.com>:
> On 26 March 2010 23:10, Tom Judge <t...@tomjudge.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> This is the function, I am guessing that I need to unlock the proc
>> before calling vmspace_free ?
>>
>>
>
> As far as I know you cannot lock a process around
> locking vmspace and/or vm_map (at least on 6.x).
> I used process reference counting for that purpose.
> Sort of the following mumble..
Generally that is true for vm_map_lock() because it is a sx_lock (thus
sleeping) but in this case it is used a trylock operation that won't
sleep (and I assume that is why it is used), thus it is not a problem.
The vmspace refcounting doesn't impose any extra-constraint instead,
thus the lock dance is not required here I think.
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
------------------------------
Message: 4
Date: Fri, 26 Mar 2010 23:47:10 +0100
From: Dag-Erling Sm?rgrav <d...@des.no>
Subject: Re: periodically save current time to time-of-day hardware
To: Peter Jeremy <peter...@acm.org>
Cc: freebsd...@FreeBSD.org, Andriy Gapon <a...@icyb.net.ua>
Message-ID: <861vf6n...@ds4.des.no>
Content-Type: text/plain; charset=utf-8
Peter Jeremy <peter...@acm.org> writes:
> At least some versions of Linux also save a RTC drift approximation
> and "last set" timestamp whenever the RTC is updated. This allows the
> kernel to better set the system clock from the RTC at boot (ie, our
> inittodr()). The downside is that this needs to store 8-16 bytes of
> state somewhere non-volatile. Linux does this using an external
> program and a file - but finding a location for a regularly updated
> file that is read very early in the rc.d sequence might be problematic.
We already do something similar for entropy.
> that it _is_ updated. This suggests that an alternative approach
> would be for adjtime() / ntp_adjtime() to directly call resettodr() if
> it's more than P minutes since resettodr() was last called.
...if we want something like Linux's eleven-minute-mode.
DES
--
Dag-Erling Smørgrav - d...@des.no
------------------------------
Message: 5
Date: Sat, 27 Mar 2010 01:38:36 +0100
From: Dag-Erling Sm?rgrav <d...@des.no>
Subject: Re: periodically save current time to time-of-day hardware
To: Peter Jeremy <peter...@acm.org>
Cc: freebsd...@FreeBSD.org, Andriy Gapon <a...@icyb.net.ua>
Message-ID: <86pr2ql...@ds4.des.no>
Content-Type: text/plain; charset=utf-8
Peter Jeremy <peter...@acm.org> writes:
> It's not especially important how regularly the RTC is updated, just
> that it _is_ updated. This suggests that an alternative approach
> would be for adjtime() / ntp_adjtime() to directly call resettodr() if
> it's more than P minutes since resettodr() was last called.
It just occurred to me that resettodr() is very slow (it usually
involves writing to NVRAM over an I2C bus), so it might not be a good
idea to call it from adjtime().
> As a general comment, whilst resettodr() needs to be serialised, there
> is no need for it to block. If thread B wants to call resettodr()
> whilst thread A is doing so, thread B can just skip the call because
> calling resettodr() twice in quick succession has no benefit.
It does if thread B set the system clock before calling resettodr()
(think ntpd -gq). Actually, it might be a good idea to call resettodr()
any time the clock is stepped.
DES
--
Dag-Erling Smørgrav - d...@des.no
------------------------------
Message: 6
Date: Fri, 26 Mar 2010 20:59:33 -0400
From: jhell <jh...@dataix.net>
Subject: Re: Compiling kernel with gcc43
To: Dag-Erling Sm?rgrav <d...@des.no>
Cc: Garrett Cooper <yane...@gmail.com>, Jille Timmermans
<ji...@quis.cx>, freebsd...@freebsd.org
Message-ID: <4BAD5875...@dataix.net>
Content-Type: text/plain; charset=UTF-8
On 03/26/2010 12:47, Dag-Erling Smørgrav wrote:
> jhell <jh...@DataIX.net> writes:
>> Jille Timmermans <ji...@quis.cx> writes:
>>> I tried building world with it; but it doesn't seem to work :(
>>>
>>> [quis@istud /usr/src]$ CFLAGS="-Wno-error -Garrett" make buildworld
>>> [snip]
>>> cc: unrecognized option '-Garrett'
>>>
>>> ;)
>> ROFL I sure hope your kidding!
>
> No, he's from a country where ";)" means "I'm deadly serious".
>
> DES
L0L
--
jhell
------------------------------
End of freebsd-hackers Digest, Vol 365, Issue 7
***********************************************