Re: alarm?

On 12 Sep 2002 11:49:30 -0400
"Joseph J. McCarthy" <mccarthy_at_engrng.pitt.edu> wrote:
> OK. These are important issues and good thoughts (I forgive you now
> for not finishing the rtcd ;)

You are allowed to name it: I am lazy, sometimes ... :(

> 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

Like Jay Sekora already wrote, I would also not want to miss an alarm
because someone (or myself) accidentially logged out.

> 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)

Hmm ... I would rather like the global approach, i.e. to have one daemon
used by any user and running all the time.

> 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)

Yes, that's defeninetly the way to go. The current memory-only-list is
not that good ;) Hopefully I'll have some time over the weekend to
change this. Maybe some directory in /etc/gpe/* would be the apropriate
place?

> 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

Sorry, but what is "imon"?
I like the idea of forking an arbitrary process that Jay proposed. I had
thought of something like this too but did not yet do so because of the
security issues involved (see next posting within the next 5-10 minutes
;)

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

No idea is really dumb ;) And especially the above were not!

> Regards..
> joe
CU
  nils faerber

-- 
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          D1 : +49-170-2729106
--