Talk:Ioctl

2007–2009

I think this is a fantastic article but may have to rewritten more for the general audience. I sorry I get it but some may not.

I'm not married to it; what was there before was inaccurate. What do you think it needs? --- tqbf 03:37, 20 November 2007 (UTC)

Hi, please add some examples of ioctl function calls. It would be nice to see the inputs and outputs. Thanks! —Preceding unsigned comment added by 206.114.9.2 (talk) 15:28, 21 October 2009 (UTC)

Unfortunately, for experts it is really hard to determine, what bits of knowledge a general audience would lack. As they are so natural to us, we can’t see them anymore. So: The better you can describe all the points where you got stuck, and the questions unanswered (or even if you didn’t even know what to ask there), the better we can improve the article. :) — 2A0A:A546:3214:1:13C4:FA28:421:E907 (talk) 14:17, 28 November 2024 (UTC)

References

User:Widefox recently tagged this article with {{refimprove}}. I've just added a list of references to the article, but they don't cover the whole article. Actually, I suspect that there many not be any WP:Reliable Sources for some of the claims, even they they are common knowledge amongst experienced Unix programmers.

I did not mention The Art of Unix Programming by Eric S. Raymond, which has a subsection titled "ioctl(2) and fcntl(2) Are an Embarrassment" (in chapter 20, online here). Should we use that in the article? If so, how? Does anyone have more sources? Cheers, CWC 11:34, 8 March 2010 (UTC)

If ioctls are an embarassment, then netlink is an eyesore from hell. :) … Thing is: It’s all the result of refusing to just have a real microkernel and a clean general higly emergent interface like Plan 9 had. Even though the speed problems are well solved, as QNX proved, a long time ago. … I would like if the article would fully reflect that. There are too many people nowadays who grew up never having been taught any better, inventing various solutions that all are inferior (and not even faster anymore) to the ancient clean design. :) We would benefit the new kids of today, by teaching that from the beginning. — 2A0A:A546:3214:1:13C4:FA28:421:E907 (talk) 14:25, 28 November 2024 (UTC)

Complexity of ioctl()

In the complexity paragraph it is said that one needs a "tangled mess of ioctl()s" to get an IP. That's BS. You only need one. Like so: ioctl(int sockfd, SIOCGIFADDR, struct ifreq *req); And voila, ((struct sockaddr_in *)&req.ifr_addr)->sin_addr yields the IP. Seriously, ioctl()s aren't complex, they are very easy to use and understand. It's only that there are hundreds of request codes(see /usr/include/linux/sockios.h on a Linux machine for a reference).

Maybe some example program should be shown.

That program below will output the IPv4 of the device 'lo' (local loopback on Linux, called lo0 on *BSD), which is of cource 127.0.0.1. Substitute lo in the macro definition with any device you want the IPv4 address from. The program will compile cleanly and can be run without rootr ights on Linux(and probably every other UNIX-like OS).

#include <sys/ioctl.h>  /* ioctl() */
#include <sys/socket.h> /* socket types, address families */
#include <net/if.h>     /* struct ifreq */
#include <arpa/inet.h>  /* inet_ntop() */
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h> /* close() */

#define DEVICE "lo"

int main()
{
    int sockfd; /* file descriptor returned by socket(), it must be passed to ioctl() */
    char buf[INET_ADDRSTRLEN]; /* buffer for inet_ntop() */
    struct ifreq req = { 0 }; /* initialize to everything 0/NULL(better then memset()) */
    struct in_addr ip;

    strncpy(req.ifr_name, DEVICE, IF_NAMESIZE); /* logically, the name of the device must be passed to ioctl() */

    sockfd = socket(AF_INET, SOCK_DGRAM, 0); /* SOCK_DGRAM or SOCK_RAW .... doesn't matter */
    if (sockfd == -1) {
        perror("Error: socket()");
        exit(EXIT_FAILURE);
    }

    if (ioctl(sockfd, SIOCGIFADDR, &req) == -1) { /* SIOCGIFADDR: gets us the address(see netdevice(7) on Linux) */
        perror("Error: ioctl()");
        close(sockfd);
        exit(EXIT_FAILURE);
    }

    close(sockfd);

    ip = ((struct sockaddr_in *)&req.ifr_addr)->sin_addr; /* ifr_addr is just a generic sockaddr structure; must be cast to sockaddr_in to get IPV4 */

    printf("IP for device " DEVICE ": %s\n", inet_ntop(AF_INET, &ip, buf, INET_ADDRSTRLEN));

    return EXIT_SUCCESS;
}

Maybe that code, with (now added) commentary, could make it as an example of ioctl() usage?

80.226.24.13 (talk) 21:47, 25 January 2013 (UTC)

I fixed the paragraph. You are correct. I just looked into this for the past week, and: Nobody calls ioctls directly. At least no normal developer (except for driver developers) should. There’s pretty much always a nice library with very normal function calls that wrap them, the same way that libc wraps syscalls. I also added Mesa as a large (Linux) example. (There is no accelerated X or Wayland without Mesa. I literally just wrote my own “display server” using Mesa, that doesn’t require either X nor Wayland. Evidence can’t get much harder than that. :) — 2A0A:A546:3214:1:13C4:FA28:421:E907 (talk) 14:13, 28 November 2024 (UTC)

Request for sources…

Hi, I improved the “Security” section. But it implied that ioctls are less heavily audited than syscalls. I have kept that implication, as the given arguments are good, and removing it would imply it is false, which is just as much problematic. But I feel uneasy with just having the statement “In practice, this is not the case.” based merely on arguments. It would be better if we had some actual sources. (E.g. auditing reports.)
Can somebody who is closer to the auditing industry add some? They should be easy to find if one deals with this on a professional basis.
— 2A0A:A546:3214:1:13C4:FA28:421:E907 (talk) 14:09, 28 November 2024 (UTC)