LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Lukas Prediger <lumip@lumip.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers/cdrom: improved ioctl for media change detection
Date: Fri, 27 Aug 2021 21:18:16 -0600 [thread overview]
Message-ID: <5f3b7d8b-9e97-094b-efd1-cad6cab793b6@kernel.dk> (raw)
In-Reply-To: <f0d33ff3-6b9d-bbe7-1776-a22f9f271155@lumip.de>
On 8/27/21 11:30 AM, Lukas Prediger wrote:
>>> @@ -295,6 +297,19 @@ struct cdrom_generic_command
>>> };
>>> };
>>>
>>> +/* This struct is used by CDROM_TIMED_MEDIA_CHANGE */
>>> +struct cdrom_timed_media_change_info
>>> +{
>>> + __u64 last_media_change; /* Timestamp of the last detected media
>>> + * change. May be set by caller, updated
>>> + * upon successful return of ioctl.
>>> + */
>>> + __u8 has_changed; /* Set to 1 by ioctl if last detected media
>>> + * change was more recent than
>>> + * last_media_change set by caller.
>>> + */
>>> +};
>>>
>> The struct layout should be modified such that there are no holes or
>> padding in it. Probably just make the has_changed a flags thing, and
>> make it u64 as well. Then you can define bit 0 to be HAS_CHANGED, and
>> that leaves you room to add more flags in the future. Though the latter
>> probably isn't much of a concern here, but...
>
> 1. jiffies_to_msecs returns unsigned int. Should I reflect that in the
> struct (i.e., make the last_media_change and has_changed fields also
> of type unsigned int or should I keep them at a fixed bit width?
You can make it an u32. Always use explicitly sized types for user API
structures.
> 2. As the last_media_change field will be in ms now, is it safe to
> convert those back to jiffies for comparison or is there a risk of
> information loss (due to rounding or whatever) in either conversion?
> More technically, can I make the assumption that for any jiffies value
> x it holds that
The granularity of jiffies depends on the HZ setting, generally just
consider it somewhere in between 100 and 1000. That's where my initial
granularity numbers came from.
> time_before(msecs_to_jiffies(jiffies_to_msecs(x)), x) is always false ?
I don't think that matters. Internally, always keep things in jiffies.
That's what you use to compare with, and to check if it's changed since
last time. The only time you convert to ms is to pass it back to
userspace. And that's going to be a delta of jiffies always, just ensure
you assign last_checked = jiffies when it's setup initially.
--
Jens Axboe
next prev parent reply other threads:[~2021-08-28 3:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-05 19:44 Lukas Prediger
2021-08-26 18:01 ` Lukas Prediger
2021-08-26 22:38 ` Jens Axboe
2021-08-27 17:30 ` Lukas Prediger
2021-08-28 3:18 ` Jens Axboe [this message]
2021-08-28 10:27 ` Lukas Prediger
2021-08-28 13:22 ` Jens Axboe
2021-09-06 16:53 ` Lukas Prediger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5f3b7d8b-9e97-094b-efd1-cad6cab793b6@kernel.dk \
--to=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=lumip@lumip.de \
--subject='Re: [PATCH] drivers/cdrom: improved ioctl for media change detection' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).