[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac3eb2510910280123g3c0e3d95wb38a239238906027@mail.gmail.com>
Date: Wed, 28 Oct 2009 09:23:57 +0100
From: Kay Sievers <kay.sievers@...y.org>
To: Matt Domsch <Matt_Domsch@...l.com>
Cc: dann frazier <dannf@...com>, linux-hotplug@...r.kernel.org,
Narendra_K@...l.com, netdev@...r.kernel.org,
Jordan_Hargrave@...l.com, Charles_Rose@...l.com,
Ben Hutchings <bhutchings@...arflare.com>
Subject: Re: [PATCH] udev: create empty regular files to represent net
interfaces
On Tue, Oct 27, 2009 at 21:55, Matt Domsch <Matt_Domsch@...l.com> wrote:
> On Thu, Oct 22, 2009 at 12:36:20AM -0600, dann frazier wrote:
>> Here's a proof of concept to further the discussion..
>>
>> The default filename uses the format:
>> /dev/netdev/by-ifindex/$ifindex
>>
>> This provides the infrastructure to permit udev rules to create aliases for
>> network devices using symlinks, for example:
>>
>> /dev/netdev/by-name/eth0 -> ../by-ifindex/1
>> /dev/netdev/by-biosname/LOM0 -> ../by-ifindex/3
>>
>> A library (such as the proposed libnetdevname) could use this information
>> to provide an alias->realname mapping for network utilities.
>
> yes, this could work, as IFINDEX is already exported in the uevents,
> and that's the primary value udev needs to set up the mapping.
>
> While I like the little ifindex2name script you've got, I think udev
> could simply call if_indextoname() to get this, and not call an
> external program? I suppose it could be a really really simple
> external program too.
What's the point of all this? Why would udev ever need to find the
name of a device by the ifindex? The device name is the primary value
for the kernel events udev acts on.
> I'd be fine with this approach. It has the advantages of not
> requiring a kernel change at all, and not creating a whole character
> device which would be useless. And it doesn't preclude someone in the
> future from creating a char device for network devices should they so
> choose.
>
> Kay, what say you as udev owner?
That all sounds very much like something which will hit us back some
day. I'm not sure, if udev should publish such dead text files in
/dev, it does not seem to fit the usual APIs/assumptions where /sys
and /dev match, and libudev provides access to both. It all sounds
more like a database for a possible netdevname library, which does not
need to be public in /dev, right?
Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists