[Toybox] [New Toys] - ipcrm & hwclock

[Rob Landley]

On 11/06/14 01:58, Ashwini Sharma wrote:
> Hi Rob, List,
> 
> Attached are the patches for two new toys.
> 
> ipcrm : remove msg que, sem or shared memory
> hwclock: get and set the hwclock
> 
> Your inputs are welcome.
> Please add these to tree.

Added, and first cleanup pass on hwclock:

  use [!rsw] instead of open coding all six pairs

  Tighten up help text a bit. (The usage: line was longer than 80 chars.)

  rtc_open() can just use TT.fname directly instead of having it passed
  in by every caller.

  inline rtc_adjtime() at its only caller.

  inline display_hwclock() at its only caller.

  Make inlined rtc_adjtime() use getline() instead of get_line() (meaning
  fopen(FILE *) instead of open(fd)).

  Use >0 in option string instead of "invalid option" check.

  In both musl and uclibc, ctime() can't ever return null. SUSv3 defined
  it as equivalent to asctime(localtime(0)) and asctime is #defined to
  print into a static buffer and return that buffer (overflowing it if
  stuff won't fit). In uClibc the "return NULL" stanzas are commented out,
  and this is the only assert(exit) I've seen in musl so far. Both have
  longish comments bitching about the bad standard. :)

We print 0.000000 seconds. We could spin redoing the ioctl until the
time changes (eating CPU for no real reason), or we could do the
ioctl(RTC_UIE_ON) thing to request the read block until the start
of the next second.

Hmmm, that requires a sigatexit() call to make sure we switch it back _off_
(why is this a global property?) which means the sigatexit infrastructure
should have a signal handler function calling a linked list...

[wanders off muttering about design issues...]

Oh: I want to add a --fast flag to _not_ provide sub-second accuracy.
The ubuntu one doesn't have the option to return less accuracy fast
(like busybox always does), so there's no obvious command line
option except making up a new one...

> PS: There are few patches (bug fixes and static analysis fixes) pending
> with you. Please have a glance at those too.

I haven't forgotten. I'm just trying to finish sed and understand the tail
fix (never a good sign when I have to reverse engineer my own code, it
means at the very least I need a lot more comments).

> Thanks,
> Ashwini

Still aiming for a release friday...

Rob

 1415681826.0