lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 10 Oct 2009 14:10:59 -0700
From:	Greg KH <greg@...ah.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	Sujit K M <sjt.kar@...il.com>, Matt Domsch <Matt_Domsch@...l.com>,
	Stephen Hemminger <shemminger@...tta.com>,
	netdev@...r.kernel.org, linux-hotplug@...r.kernel.org,
	Narendra_K@...l.com, jordan_hargrave@...l.com
Subject: Re: PATCH: Network Device Naming mechanism and policy

On Sat, Oct 10, 2009 at 08:00:30PM +0100, Ben Hutchings wrote:
> On the other hand, the netlink configuration APIs already use ifindex so
> it may be better just to say that the device ioctls are deprecated and
> applications should use netlink.

I thought that is what was already encouraged to happen.

> > > > That is why all distros name network devices based on the only
> > > > deterministic thing they have today, the MAC address. ?I still fail to
> > > > see why you do not like this solution, it is honestly the only way to
> > > > properly name network devices in a sane manner.
> > > 
> > > This is feature that needs to be implemented. As per the rules followed.
> > 
> > This feature is already implemented today, all distros have it.
> 
> No, see below.

Yes, if not, file a bug in your distro, all of the infrastructure is
already in place, and the udev rules and scripts are already written.

> > > > All distros also provide a way to easily rename the network devices, to
> > > > place a specific name on a specific MAC address, so again, this should
> > > > all be solved already.
> > > >
> > > > No matter how badly your BIOS teams mess up the PCI enumeration order :)
> > > 
> > > This is an problem, But I think this can be solved by implementing some of the
> > > routines in the network device.
> > 
> > I don't, see the rules that your distro ships today for persistant
> > network devices, it's already there, no need to change the kernel at
> > all.
> 
> The udev persistent net rules work tolerably well for a single system
> with a stable set of net devices.
> 
> They do not solve the problem Matt's talking about, which is lack of
> consistency between multiple systems, because the initial enumeration
> order is not predictable.

Again, you name the device as a MAC address.  Or something else that the
BIOS exports in a unique manner (PCI slot name, etc.).  That is
consistant.  If not, then fix the BIOS.

> They also result in name changes when a NIC (or motherboard) is swapped.
> For some users, that's fine; for others, it's not.
> 
> The ability to specify NICs by port name or PCI address should solve
> these problems.

That can be done today quite easily.  But note that PCI addresses are
not guaranteed to be stable.  As lots of machines are known to have
happen.

Again, none of this requires any kernel changes today at all, let alone
adding dummy char devices for network devices.

thanks,

greg k-h
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ