[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1395349607.7776.51.camel@joe-AO722>
Date: Thu, 20 Mar 2014 14:06:47 -0700
From: Joe Perches <joe@...ches.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Alejandra Morales <alejandra.morales@....de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"christian@...thoff.org" <christian@...thoff.org>
Subject: Re: Cryogenic: Enabling Power-Aware Applications on Linux
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists