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]
Message-ID: <EDA0A4495861324DA2618B4C45DCB3EE589663@blrx3m08.blr.amer.dell.com>
Date:	Thu, 29 Oct 2009 22:52:52 +0530
From:	<Narendra_K@...l.com>
To:	<greg@...ah.com>
Cc:	<Matt_Domsch@...l.com>, <kay.sievers@...y.org>, <dannf@...com>,
	<linux-hotplug@...r.kernel.org>, <netdev@...r.kernel.org>,
	<Jordan_Hargrave@...l.com>, <Charles_Rose@...l.com>,
	<bhutchings@...arflare.com>
Subject: RE: [PATCH] udev: create empty regular files to represent netinterfaces


>Sure, it's never guaranteed by the kernel that this will 
>happen, especially as we speed up the boot process by doing 
>things async.

>So again, just fix your installer, or write a new udev rule 
>for your hardware platforms, or both.  But I still fail to see 
>why multiple names for network devices _in the kernel_ is a 
>solution for your issue.
>

The char device nodes solution does not propose having multiple names
for the network interfaces _in the kernel_. It is suggesting that we
have alternate names for kernel assigned names in user space and user
space utilities refer to the interface by these alternate names. The
userspace utilities would have to map the pathnames to kernel names
before issuing the ioctls. That way there is determinism without
embedding MAC or any other attribute. An Embedded_NIC_1 interface would
always refer to the Gb1 without having to depend on any attribute.

With regards,
Narendra K 

--
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