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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
