[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091013173638.GE1119@ldl.fc.hp.com>
Date: Tue, 13 Oct 2009 11:36:38 -0600
From: dann frazier <dannf@...com>
To: Narendra_K@...l.com
Cc: netdev@...r.kernel.org, linux-hotplug@...r.kernel.org,
Matt_Domsch@...l.com, Jordan_Hargrave@...l.com,
Charles_Rose@...l.com
Subject: Re: PATCH: Network Device Naming mechanism and policy
1;2202;0cOn Tue, Oct 13, 2009 at 10:43:49PM +0530, Narendra_K@...l.com wrote:
>
> >> These device nodes are not functional at the moment - open() returns
> >> -ENOSYS. Their only purpose is to provide userspace with a kernel
> >> name to ifindex mapping, in a form that udev can easily manage.
> >
> >If the idea is just to provide a userspace-visible mapping
> >(and presumably take advantage of udev's infrastructure for
> >naming) does this need kernel changes? Could this be a
> >hierarchy under e.g. /etc/udev instead, using plain text
> >files? It still means we need something like libnetdevname for
> >apps to do the translation, but I'm not seeing why it matters
> >how this map is stored. Is there some special property of the
> >character devices (e.g. uevents) that we're not already
> >getting with the existing interfaces?
>
> Yes. The char device by itself doesn't help in any way. But it provides
> a flexible mechanism to provide multiple names for the same device, just
> the way it is for disks.
Right - so any reason this couldn't be implemented completely in
userspace by having udev manipulate plain text files under say
/etc/udev/net/?
I do agree that it would be nice for admins/installers to tweak/use
nic names in a similar way to storage names (udev rules), and it might
let us take advantage of a lot of the existing udev code.
--
dann frazier
--
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