Re: consistent ioctl for getting all net interfaces?

[Albert Cahalan]

Viro cluelessly writes:
On Sat, May 22, 2004 at 09:28:28PM -0700, Joshua Kwan wrote:
 
>> I'm interested in not having to parse /proc/net/dev to get
>> a list of all available (not necessarily even up) interfaces
>> on the system. I investigated the ioctl SIOCGIFCONF, but it
>> seems to behave differently on 2.4 and 2.6 series kernels,
>> e.g. sometimes it won't return all interfaces.
>>
>> Is there some end-all ioctl that does what I want, or am
>> I forever doomed to process /proc/net/dev (in C, no less..)?
>
> ASCII is tough, let's go shopping?
>
>  char name[17];
>  FILE *in = fopen("/proc/net/dev", "r");
>  if (!in)
>   die("can't open");
>  fscanf(in, "%*[^\n]\n%*[^\n]");  /* skip two lines */
>  while (fscanf(in, " %16[^:]:%*[^\n]", name) == 1)
>   do_whatever_you_want(name);
>
> That you are calling "forever doomed"?  Wimp...

What makes you think you got that right? Do you have a
specification for the grammar? Let's look at an example
of /proc/net/dev, and I'll use my extensive /proc-parsing
experience to count your errors. Here is a sample:

Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
  eth0:3077476015 33231846    0    0    0     0          0         0 101565261  774586    0    0    0     0       0          0
    lo:    1360      24    0    0    0     0          0         0     1360      24    0    0    0     0       0          0
  tap0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
  eth1:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
  eth2:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0

Excuse me while I vomit.

Let's start with the device names. Users can change
them at will, and some driver authors aren't normal.
So, in C notation, a name could be "x1: 1 2 3\n".

It doesn't even need to that evil to screw up your
wimpy parser. A simple "av6:3" would do nicely.
Think it won't happen? Sorry, but it does and will.
This is the nature of /proc crap.

Now we get to format changes. Don't you think the
above is kind of ugly? I sure do. I'm not crazy
enough to touch the formatting, but that readable
ASCII is a temptation for many. Just look at the
history of /proc/cpuinfo, which long ago looked a
bit more like the above in terms of ':' placement.
Also, it's foolish to rely on that leading space.

Here is what my data might look like in a few years:

Iface |   Receive                                                |  Transmit
name  |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
eth0  :3077476015 33231846    0    0    0     0          0         0 101565261  774586    0    0    0     0       0          0
lo    :    1360      24    0    0    0     0          0         0     1360      24    0    0    0     0       0          0
tap0  :       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
eth1  :       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
eth2  :       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0

Subtle, isn't it? Your parser broke.

(then there is performance, or lack of it...)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/