From: "H. Peter Anvin" <hpa@zytor.com>
To: Alejandra Morales <alejandra.morales@tum.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "christian@grothoff.org" <christian@grothoff.org>
Subject: Re: Cryogenic: Enabling Power-Aware Applications on Linux
Date: Thu, 20 Mar 2014 13:31:19 -0700 [thread overview]
Message-ID: <532B5017.2070400@zytor.com> (raw)
In-Reply-To: <9E3F9C2076C45D4783F09B90D5BE77CE1AEF7A@BADWLRZ-SWMBX13.ads.mwn.de>
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.
-hpa
next prev parent reply other threads:[~2014-03-20 20:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-19 15:55 Cryogenic: Enabling Power-Aware Applications on Linux Alejandra Morales
2014-03-20 20:31 ` H. Peter Anvin [this message]
2014-03-20 21:06 ` Joe Perches
2014-04-11 10:19 ` Pavel Machek
2014-04-11 18:48 ` Christian Grothoff
2014-04-11 22:05 ` Pavel Machek
2014-04-11 23:51 ` Christian Grothoff
2014-04-12 0:10 ` David Lang
2014-04-12 11:36 ` Pavel Machek
2014-04-12 22:39 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=532B5017.2070400@zytor.com \
--to=hpa@zytor.com \
--cc=alejandra.morales@tum.de \
--cc=christian@grothoff.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox