wrto the in-kernel NTP synchronization,
as discussed before [1], my opinion
is that it should be done in userland.
Keeping it in kernel implies subtle code
in each of the supported architectures.
So, if the arch maintainers agree,
I would suggest to schedule it for removal.
[1] http://lkml.org/lkml/2006/3/28/358
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
http://www.towertech.it
On Wed, Nov 22, 2006 at 08:36:33PM +0100, Alessandro Zummo wrote:
>
>
> wrto the in-kernel NTP synchronization,
> as discussed before [1], my opinion
> is that it should be done in userland.
>
> Keeping it in kernel implies subtle code
> in each of the supported architectures.
>
> So, if the arch maintainers agree,
> I would suggest to schedule it for removal.
>
> [1] http://lkml.org/lkml/2006/3/28/358
Fine, provided there's also a shell tool that can enquire whether the
kernel is sync'd or not. (Currently the 11-minute update does not
occur when the kernel is desynced from a time source - the RTC itself
might be more accurate in this case.)
Throwing hwclock commands into crontab such that they do not take
note of the kernel's sync status is probably a very bad move in that
respect.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Wednesday 22 November 2006 11:36 am, Alessandro Zummo wrote:
>
> wrto the in-kernel NTP synchronization,
> as discussed before [1], my opinion
> is that it should be done in userland.
>
> Keeping it in kernel implies subtle code
> in each of the supported architectures.
>
> So, if the arch maintainers agree,
> I would suggest to schedule it for removal.
>
> [1] http://lkml.org/lkml/2006/3/28/358
Suggested time of removal: one year after two relevant software
package releases get updated:
- NTPD, to call hwclock specifying the relevant RTC;
- util-linux, updating hwclock to know about /dev/rtcN;
- busybox, with its own hwclock implementation.
The util-linux hwclock update is already in the queue, I'm told.
- Dave
On Wed, 22 Nov 2006 11:55:23 -0800
David Brownell <[email protected]> wrote:
> >
> > So, if the arch maintainers agree,
> > I would suggest to schedule it for removal.
> >
> > [1] http://lkml.org/lkml/2006/3/28/358
>
> Suggested time of removal: one year after two relevant software
> package releases get updated:
>
> - NTPD, to call hwclock specifying the relevant RTC;
This might introduce delays. ntpd might open the device
and update the time itself.
> - util-linux, updating hwclock to know about /dev/rtcN;
> - busybox, with its own hwclock implementation.
>
> The util-linux hwclock update is already in the queue, I'm told.
I suspect nobody would change NTPD if we don't
schedule that feature for removal :)
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
http://www.towertech.it
On Wed, 22 Nov 2006 19:51:53 +0000
Russell King <[email protected]> wrote:
> > So, if the arch maintainers agree,
> > I would suggest to schedule it for removal.
> >
> > [1] http://lkml.org/lkml/2006/3/28/358
>
> Fine, provided there's also a shell tool that can enquire whether the
> kernel is sync'd or not. (Currently the 11-minute update does not
> occur when the kernel is desynced from a time source - the RTC itself
> might be more accurate in this case.)
>
> Throwing hwclock commands into crontab such that they do not take
> note of the kernel's sync status is probably a very bad move in that
> respect.
I agree. I would like to coordinate this effort together with
the ntp folks so that we can find a viable solution.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
http://www.towertech.it
On Wed, Nov 22, 2006 at 09:23:55PM +0100, Alessandro Zummo wrote:
> On Wed, 22 Nov 2006 11:55:23 -0800
> David Brownell <[email protected]> wrote:
>
> > >
> > > So, if the arch maintainers agree,
> > > I would suggest to schedule it for removal.
> > >
> > > [1] http://lkml.org/lkml/2006/3/28/358
> >
> > Suggested time of removal: one year after two relevant software
> > package releases get updated:
> >
> > - NTPD, to call hwclock specifying the relevant RTC;
>
> This might introduce delays. ntpd might open the device
> and update the time itself.
>
Indeed, the update should be at least _triggered_ by ntp.
In the end it will be the kernel that accesses the hardware,
the fundamental problem is that with RTC chips with very slow
access like I2C it cannot be done from an interrupt.
But it nevertheless has to be done as close as possible
to the half-second or second boundary (depending on the chip)
boundary if we want to keep some precision. You can't expect
miracles from RTC chips in this respect, since the crystal
period is about 30?s to boot and from some tests I did a long
time ago it seems that most do not reset the first bits of
the divider when written to, so the precision is much worse
(something like 30ms IIRC). It is still much better than 1
second in any case.
How can ntp know if the RTC chip has to be updated at the
half-second or second boundary? That is the kind of knowledge
that is better left to the driver.
Regards,
Gabriel
> [1] http://lkml.org/lkml/2006/3/28/358
What was the answer to Matt's last question in there?
If the existing user land does it already then
probably. If not then a good migration strategy would
be needed.
-Andi
On Thu, 2006-11-23 at 11:54 +0100, Andi Kleen wrote:
> > [1] http://lkml.org/lkml/2006/3/28/358
>
> What was the answer to Matt's last question in there?
> If the existing user land does it already then
> probably. If not then a good migration strategy would
> be needed.
Couldn't we have a transition period by making the kernel not rely on
interrupts ? if the NTP irq code just triggers a work queue, then all of
a sudden, all of the RTC drivers can be used and the latency is small.
That might well be a good enough solution and is very simple.
Ben
On Thursday 23 November 2006 3:00 am, Benjamin Herrenschmidt wrote:
>
> Couldn't we have a transition period by making the kernel not rely on
> interrupts ? if the NTP irq code just triggers a work queue, then all of
> a sudden, all of the RTC drivers can be used and the latency is small.
> That might well be a good enough solution and is very simple.
Good point. Of course, one issue is that the NTP sync code all
seems to be platform-specific right now ... just like the code
to set the system time from an RTC at boot (except for the new
RTC framework stuff) and after resume.
- Dave
> -----Original Message-----
> From:
> [email protected]
> [mailto:linuxppc-dev-bounces+joakim.tjernlund=transmode.se@ozl
> abs.org] On Behalf Of David Brownell
> Sent: den 26 november 2006 00:22
> To: Benjamin Herrenschmidt
> Cc: [email protected]; Alessandro Zummo; [email protected];
> [email protected]; Linux Kernel Mailing List;
> [email protected]; Andi Kleen; [email protected];
> [email protected]; [email protected]; [email protected]
> Subject: Re: NTP time sync
>
> On Thursday 23 November 2006 3:00 am, Benjamin Herrenschmidt wrote:
> >
> > Couldn't we have a transition period by making the kernel
> not rely on
> > interrupts ? if the NTP irq code just triggers a work
> queue, then all of
> > a sudden, all of the RTC drivers can be used and the
> latency is small.
> > That might well be a good enough solution and is very simple.
>
> Good point. Of course, one issue is that the NTP sync code all
> seems to be platform-specific right now ... just like the code
> to set the system time from an RTC at boot (except for the new
> RTC framework stuff) and after resume.
>
> - Dave
Looking at rtc-dev.c I don't see a MARJOR number assigned to /dev/rtcN. Seems like
it is dynamically allocated to whatever major number that is free.
Is that the way it is supposed to be? How do I create a static /dev/rtcN in my /dev
directory if the major number isn't fixed?
Maybe I am just missing something, feel free to correct me :)
Jocke
On Sun, 26 Nov 2006 12:04:54 +0100
"Joakim Tjernlund" <[email protected]> wrote:
> Looking at rtc-dev.c I don't see a MARJOR number assigned to /dev/rtcN. Seems like
> it is dynamically allocated to whatever major number that is free.
> Is that the way it is supposed to be? How do I create a static /dev/rtcN in my /dev
> directory if the major number isn't fixed?
> Maybe I am just missing something, feel free to correct me :)
udev ;)
the concept of static numbers is quite old...
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
http://www.towertech.it
> -----Original Message-----
> From: Alessandro Zummo [mailto:[email protected]]
> Sent: den 26 november 2006 20:22
> To: Joakim Tjernlund
>
> On Sun, 26 Nov 2006 12:04:54 +0100
> "Joakim Tjernlund" <[email protected]> wrote:
>
> > Looking at rtc-dev.c I don't see a MARJOR number assigned
> to /dev/rtcN. Seems like
> > it is dynamically allocated to whatever major number that is free.
> > Is that the way it is supposed to be? How do I create a
> static /dev/rtcN in my /dev
> > directory if the major number isn't fixed?
> > Maybe I am just missing something, feel free to correct me :)
>
> udev ;)
>
> the concept of static numbers is quite old...
Yes it is old, but is the old way unsupported now? I have an embedded target
which is using the old static /dev directory, do I need to make
it udev aware to use newer features like the rtc subsystem?
Jocke
Joakim Tjernlund wrote:
>>> Is that the way it is supposed to be? How do I create a
>> static /dev/rtcN in my /dev
>>> directory if the major number isn't fixed?
>>> Maybe I am just missing something, feel free to correct me :)
>> udev ;)
>>
>> the concept of static numbers is quite old...
>
> Yes it is old, but is the old way unsupported now? I have an embedded target
> which is using the old static /dev directory, do I need to make
> it udev aware to use newer features like the rtc subsystem?
Really you do not have to make it udev aware, it is enough to make it
sysfs aware. You will be done by reading /sys/class/misc/rtc/dev on
initialization and replacing /dev/rtcN with device with the address
read. If you have configuration static enough, I guess you can even
create it once and for life of current setup with current kernel.
On Sun, 26 Nov 2006 22:37:10 +0100
"Joakim Tjernlund" <[email protected]> wrote:
> > the concept of static numbers is quite old...
>
> Yes it is old, but is the old way unsupported now? I have an embedded target
> which is using the old static /dev directory, do I need to make
> it udev aware to use newer features like the rtc subsystem?
That can be a good option. You can also do
a symlink to /dev/rtc0 in your boot scripts or simply
upgrade your hwclock to a version that accepts
the device as a parameter.
The old /dev/rtc name is not supported on the new rtc subsystem.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
http://www.towertech.it
On Sunday 26 November 2006 2:53 pm, Alessandro Zummo wrote:
> On Sun, 26 Nov 2006 22:37:10 +0100
> "Joakim Tjernlund" <[email protected]> wrote:
>
> > > the concept of static numbers is quite old...
> >
> > Yes it is old, but is the old way unsupported now? I have an embedded target
> > which is using the old static /dev directory, do I need to make
> > it udev aware to use newer features like the rtc subsystem?
>
> That can be a good option.
And it's simple enough. You might not even need to run "udevd"
if you don't have hotpluggable devices ... just the startup stuff,
which you might not need after the first boot. (Since the set of
devices will be stable, /dev/* won't change, and you can speed up
system boot by that small delta.)
I certainly run udev on some small systems, with /sbin/hotplug as
appended. Getting udev set up, and handling coldplug, is left as
an exercise for the reader. :)
- Dave
#!/bin/ash
#
# "hotplug" initializes devices ... hardware drivers get modprobed and
# create class devices. then later udev handles /dev node creation and
# invokes programs that make userspace aware of the new device node.
#
# install as /sbin/hotplug
if [ ! -d /sys ]
then
exit 1
fi
cd /sys
if [ "$ACTION" = "add" -a "$SUBSYSTEM" = "mmc" ]
then
# MMC doesn't support modalias yet, but this is
# the only choice until we have SDIO support.
MODALIAS=mmc_block
fi
if [ "$ACTION" = "add" -a -n "$MODALIAS" -a ! -L $DEVPATH/driver ]
then
# most important subsystems now have $MODALIAS support:
modprobe -q $MODALIAS
fi
if [ -n "$DEVPATH" ]
then
/sbin/udevsend $1
fi