Re: [PATCH] rtc-dev: stop periodic interrupts on device release

[David Brownell <david-b@pacbell.net>]

On Saturday 26 July 2008, Alessandro Zummo wrote:
> On Sat, 26 Jul 2008 20:06:10 +0200 Tomáš Janoušek <tomi@nomi.cz> wrote:
> > On Sat, Jul 26, 2008 at 07:55:21PM +0200 Alessandro Zummo wrote:
> > 
> > >  I'm not sure this is appropriate. sometimes the PIE is used to control
> > >  external hardware and it doesn't make sense to have an application that's
> > >  always open to handle that. 

I'd stay that having an application running is the standard way
to handle such stuff!

In fact, how could the 1/(2^N) Hz periodic interrupt ever control
external hardware *by itself*?  It would need some control path
that's not part of the programming interface, like routing some
signal from the RTC to that hardware.  That's PWM functionality,
and isn't available from all timers/clocks/rtcs.

The only control path in scope of the RTC programming interface is
client/application code responding to a (periodic) IRQ by issuing
some type of command.


> > > 
> > >  Any app should be responsible to release what it has allocated, if appropriate,
> > >  and not rely on someone else to do on his behalf.

But exiting a task is responsible for freeing all of its kernel
resources ... closing file descriptors, releasing memory, and
so forth.  Programs rely on that, as in this case.


> > mplayer and aireplay-ng have never done so. And what about crashes? Am I
> 
>  that's not an excuse, they have been written on a false assumption. Unless
>  that behaviour is documented somewhere.

We can't rely on documentation for interfaces (like the legacy RTC
interface which the RTC framework is emulating) that never really
had complete documentation!!

In this case, we need to follow interface behavior, as observed, when
it's not a bug.  Like shutting down periodic IRQs on close()...


> > supposed to create a small "rtcpieoff" applications and make it into all
> > distributions so that everyone can clean up the mess?
> 
>  just send patches to mplayer and aireplay-ng and it will make in the distros.

Except ... that makes it even more clear that you're suggesting
changes to a well established userspace interface.  Which is not
something we like doing to the Linux userspace community.


> > Additionally, it has been a regression against the old rtc and drivers like
> > rtc-sh do so even today.
> 
>  Specific drivers might choice to do it on close. I believe rtc-cmos might
>  be one of the few that might have to do it in order to cope with badly
>  written programs. It's up to David to choice if it's appropriate too add it to
>  rtc-cmos. 

I want the framework to handle it, since that's how the RTC
programming interface has traditionally behaved and since there
should be as few driver-specific behaviors as practical.

Remember, those programs should not be growing needless
hardware dependencies.  In particular "only works on x86"
would be really nasty.

If it needs to be changed on x86 so that most Linux programs
behave correctly again, then it needs to be changed for all
RTC drivers.  Which means updating the framework is the most
effective way to solve the problem.

- Dave