Messages in this thread | | | Subject | Re: Cryogenic: Enabling Power-Aware Applications on Linux | From | Joe Perches <> | Date | Thu, 20 Mar 2014 14:06:47 -0700 |
| |
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.
| |