On Fri, Jan 23, 2015 at 6:18 PM, Rob Landley <[email protected]> wrote: > On 01/22/15 23:11, enh wrote: >> This probably only seems worthwhile to those of us who spend a large >> part of every day staring at strace output, but in case you're >> interested... >> >> Before (on a device with only one RTC): > ... >> diff --git a/toys/pending/hwclock.c b/toys/pending/hwclock.c >> index 003174f..04f4770 100644 >> --- a/toys/pending/hwclock.c >> +++ b/toys/pending/hwclock.c >> @@ -35,6 +35,7 @@ static int check_hctosys(struct dirtree* node) >> FILE *fp; >> >> if (!node->parent) return DIRTREE_RECURSE; >> + if (!dirtree_notdotdot(node)) return 0; >> >> snprintf(toybuf, sizeof(toybuf), "/sys/class/rtc/%s/hctosys", node->name); >> fp = fopen(toybuf, "r"); > > > I'd actually like to follow your suggestion do the counting based > version, if I can assume that the rtcs aren't sparse (I.E. if > /sys/class/rtc/rtc3 doesn't exist, then there isn't an rtc4 or higher > either, so I can stop at the first one that isn't there).
i've never seen anything to imply that they can't be sparse. other parts of Android support sparse rtc ids, and although ids are given out sequentially, the kernel has a devm_rtc_device_unregister which would seem to introduce the possibility of creating gaps. > Do we have hot-unpluggable realtime clocks? they don't need to be physically unpluggable for OEMs to decide to do weird things with them. i've certainly had bad experiences with network interface ids in the past. one OEM thought that it's fine for an interface id to increment every time it goes down and comes back up, for example. --elliott _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
