Re: alarm?

OK. These are important issues and good thoughts (I forgive you now for
not finishing the rtcd ;)

The issues seems to be primarily with :

1. talking back to the application that set the alarm
2. the whole uid issue.

I think the uid issue is the easiest to solve. If a user logs out, they
essentially relinquish their "right" to wake up the ipaq or signal
alarms. Now how to do this? Several ways really, but probably the best
is that the rtcd will only pay attention to alarms set by the uid of the
*owner* of the rtcd (so we will have the rtcd start/stop with
login/logout). By doing this we of course need to worry about users
trying to *set* alarms when they are not logged in at the "touchscreen"
(but dont you have the same issues on a desktop with who owns a floppy
drive for example? so maybe who cares) so maybe we just ignore everyone
who isnt logged in from the touchscreen (we can change this for "custom"
setups by simply chown-ing the /dev/rtc for anyone who needs serial or
net support)

2. bottom line: whoever owns /dev/rtc rund rtcd and only they can set
and get alarms

the talking back to applications is a bit trickier. Perhaps the best way
to do this is to do the following....

a. do *not* simply save alarm info in memory. actually write files
somewhere that correspond to each alarm (and are named and located in
such a way that other apps know where they would look for this
information (this would help with the over reboot issue too)

b. have the rtc do *something* to the files when it triggers and alarm
and use something like imon in apps to determine when it should update
the state of its own alarms

These may be dumb ideas, but I think they "fix" the issues as I see
them.

Regards..

joe

> We have the followin restrictions:
> 1. We only have _one_ RTC alarm.
> 2. We have potentially several users using the alarm service.
> 3. We have to have some means of notification.
> 4. Alarms should be persistent even after reboots.
>
> The 1st restriction leads directly to a central service application that
> manages the whole sum of alarms from all users and applications (2.) and
> program the timely next alarm into the RTC. Thus this central
> application will also be the application that watches the RTC and gets
> notified upon alarm time arrival and after that has to notify (3.) a
> user application.
>
> The forward way, i.e. from application to service daemon and to RTC, is
> quite straight forward. An application simply contacts the daemon, for
> example using Unix Domain socket, and requests the corresponding alarm.
> After that the socket is closed again.
>
> The more dificult part is getting back from the daemon to the
> application. The daemon needs to notify the process that registered the
> alarm. Here we get several new problems:
>
> 1. The process that registered the alarm might not be running anymore,
> i.e. simply signalling the PID does not work. We could now also store
> the application name along with the alarm data into the daemon. But this
> leads to
>
> 2. If the calling process does not longer exists we could start a new
> instance of it using xsi. But what if the calling process was running
> with a different UID? Or in other words, you logged in as user XY and
> registered an alarm then log out. After that user YZ logs in and the
> alarm goes off. What does happen now? Assume the alarm came from
> gpe-calendar. Should the RTC daemon now spawn the calendar application
> as user XY and present user YZ with the application window?
>
> 3. Doing alarm notification using signals is not very nice; signals are
> evil :( It took me quite some time to get gpe-alarm to behave properly.
> Maybe setting of an X resource that apps can query might be an option;
> or an X-event?
>
>
> So, those are basically my current problems that I right now don't know
> how to solve properly. If anyone has a good idea on it, please let me
> know and I'll do that ASAP!
>
> > Thanks in advance,
> > /sorin gherman
> CU
> nils faerber
>
> --
> kernel concepts Tel: +49-271-771091-12
> Dreisbachstr. 24 Fax: +49-271-771091-19
> D-57250 Netphen D1 : +49-170-2729106
> --
> _______________________________________________
> GPE mailing list
> GPE_at_handhelds.org
> http://handhelds.org/mailman/listinfo/gpe
>

-- 
Joseph J. McCarthy, Assistant Professor
Department of Chemical and Petroleum Engineering
University of Pittsburgh
1249 Benedum Hall Pittsburgh, Pennsylvania 15261
Ph. 412-624-7362
Fax 412-624-9639
mccarthy_at_engrng.pitt.edu
http://granular.che.pitt.edu