Re: [RFC PATCH util-linux] Support hwclock read and set operations for Hurd

[Samuel Thibault]

Zhaoming Luo, le mer. 04 déc. 2024 11:04:02 +0800, a ecrit:
> On 12/4/24 5:56 AM, Samuel Thibault wrote:
> > Zhaoming Luo, le mar. 03 déc. 2024 08:53:44 +0800, a ecrit:
> > > On 12/3/24 6:48 AM, Samuel Thibault wrote:
> > > > Zhaoming Luo, le mar. 03 déc. 2024 06:42:07 +0800, a ecrit:
> > > > > On 12/2/24 10:12 AM, Samuel Thibault wrote:
> > > > > > Please factorize these with the linux port, by putting them into a
> > > > > > shared file that is linked-in in both ports cases.
> > > > > Do you mean having the following structure?
> > > > >            /----- hurd-hwlock-rtc.c \
> > > > > hwclock.c                           hwclock-rtc.c
> > > > >            \----- linux-hwlock-rtc.c /
> > > > > 
> > > > > hwclock-rtc.c contains close_rtc, open_rtc, etc.
> > > > 
> > > > Yes.
> > > I think another of supporting hwclock in Hurd is implementing more ioctl
> > > calls (RTC_UIE_ON, RTC_PARAM_GET, etc) for rtc. The current compile errors
> > > seem to be mainly due to the lack of RTC ioctl macros (i.e. RTC_UIE_ON,
> > > etc).
> > 
> > That's also a solution, though more involved in terms of implementing
> > RPCs. Notably UIE_ON will have to be blocking.
> I will try this solution first, because those RPCs will eventually be
> implemented in the future. There is no reason we don't finish them now :).
> 
> BTW, what do you mean by "blocking"?

See util-linux' synchronize_to_clock_tick_rtc, the select() call
has to block until next RTC's tick. Properly implementing it would
mean registering to gnumach for the RTC interrupt (8), and tell the
RTC to raise interrupts, and then wait for the interrupt. That's
quite involved. A simpler solution is to just do it like util-linux'
synchronize_to_clock_tick_cmos does it: just busy-loop-read the RTC
until it ticks.

Samuel