[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] [RFC PATCH v3 3/4] virtio-rtc: Add alarm feature
On 22.12.23 19:57, Cornelia Huck wrote: > On Mon, Dec 18 2023, Peter Hilber <peter.hilber@opensynergy.com> wrote: > >> Add the VIRTIO_RTC_F_ALARM feature (without normative statements). >> >> The intended use case is: A driver needs to react when an alarm time has >> been reached, but the driver may be in a sleep state or powered off at >> alarm time. The alarm feature can resume and notify the driver in this >> case. Alarms may be retained across device resets (including reset on >> boot). > > Does the driver have some kind of control or information about whether > alarms are retained? I.e. to start with a clean slate, if wanted. As of now, the driver can disable the alarm through VIRTIO_RTC_REQ_SET_ALARM_ENABLED. If the driver does this before making buffers available to the alarmq, the device behaves like starting with a clean slate, with two exceptions: - VIRTIO_RTC_REQ_READ_ALARM might return a different alarm time than the one at the first reset (but the alarm would be disabled). If adding the minimum allowed alarm time to the spec, as was discussed in the "Open Questions" section of the patch, initializing to the minimum allowed alarm time could also become part of the "clean slate", so that this exception would be removed. - The requirements currently allow a "grace period" after disabling through VIRTIO_RTC_REQ_SET_ALARM_ENABLED, during which the device could still give the alarm notification, or execute custom alarm actions. The draft spec permits alarm actions to continue for a short time after the alarm has become obsolete, in order to not unnecessarily restrict implementations. While I would not consider a sporadic-looking alarm notification (which the driver can easily recognize as such) to be a problem, the spec does not require to immediately cancel an obsolete custom alarm action either. But the requirements could be tightened so that all the actions have to be completed or canceled before the device marks VIRTIO_RTC_REQ_SET_ALARM_ENABLED as used: If the driver successfully requests VIRTIO_RTC_REQ_SET_ALARM, or VIRTIO_RTC_REQ_SET_ALARM_ENABLED, for clock C, the device MUST stop serving any previous alarm expiration event for C before the device marks the message as used. This would remove the second exception. I think I will just do the two above changes, if nobody objects. Thanks for the comment, Peter
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]