Re: Cryogenic: Enabling Power-Aware Applications on Linux

[Joe Perches <joe@perches.com>]

On Thu, 2014-03-20 at 13:31 -0700, H. Peter Anvin wrote:
> On 03/19/2014 08:55 AM, Alejandra Morales wrote:
> > 1) Open the character device corresponding to the active interface that is sending
> > the packets, which we need to know beforehand.
> > 2) Within the main loop, and before the transmission, calculate the delay and the
> > timeout and pass it to Cryogenic by calling ioctl.
> > 3) Call select before the transmission. The call to select will block until one of the
> > events that are meant to allow the resumption of the task happen: an I/O operation
> > requested by other applications or the expiration of the timeout that we set previously.
> > 4) After the loop, close the file descriptor.
> > 
> > The resulting code looks like this:
> > 
> >  1 main()
> >  2 {
> >  3     sock_fd = create_socket();
> >  4     fd = open("/dev/cryogenic/wlan0");
> >  5     while() {
> >  6         times = calculate_delay_timeout(period);
> >  7         ioctl(fd, times);
> >  8         select(fd);
> >  9         send(sock_fd);
> > 10     }
> > 11     close(fd);
> > 12     close(sock_fd);
> > 13 }
> > 
> > The call to sleep() has been removed since it is assumed now that the delay and the
> > timeout completely determine the transmission time. Nevertheless, this is just an
> > example and programmers may still want to keep it depending on the behavior
> > they want to achieve.
> 
> This looks quite interesting, but the API seems clumsy as hell.  It
> would probably make more sense to simply make the timeout an fcntl() per
> file descriptor.
> 
> > I would like to submit the module as a patch now, do you have any suggestions to
> > do this properly? Also, I would really appreciate any feedback about the code, which
> > you can find at the end of the e-mail. Thank you.
> 
> Please see Documentation/SubmittingPatches first.  Since this is a very
> ambitious piece of work, expect to get some pushback.  This is NOT a
> negative, but rather an indication that the work is valuable enough to
> work with to integrate it into the kernel.  Most likely, in my opinion,
> making this a standalone driver just isn't going to fly, but rather we
> will want to integrate it into the core I/O model.

Perhaps a similar thing be done by exposing a
user-space aggregating sleep like [u]sleep_range.