Re: [PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values
Hi, Le jeudi 05 juillet 2012 04:44:33, Andy Green a écrit : The following series adds some code to generate legal, locally administered MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at net/ethernet taking care of accepting device path / MAC mapping registrations and running a notifier to enforce the requested MAC when the matching network device turns up. This looks like something you can solve by user-space entirely. Expose the OMAP4 CPU Die ID using a sysfs attribute, and let user-space manage the MAC address pool. If you tell me you want to use this for nfsroot booting, what prevents you from using an initramfs, assign a valid MAC to your interface and switch over your nfsroot once the interface setup is done? On PandaBoard / ES, two devices have no board-level MAC either assigned by the manufacturer or stored on the board, the last patch in the series adds these device paths and gets them set when the network device is registered. Lastly for convenient testing, there's a little patch on omap2plus_defconfig that will get Ethernet and WLAN up on Pandaboard. The patches are against today's linux-omap. Thanks to Tony Lindgren and Arnd Bergmann for comments leading to the helper in net/ethernet. --- Andy Green (4): OMAP: add cpu id register to MAC address helper NET ethernet introduce mac_platform helper OMAP4 PANDA register ethernet and wlan for automatic mac allocation config test config extending omap2plus with wl12xx etc arch/arm/configs/omap2plus_defconfig | 35 +++ arch/arm/mach-omap2/Kconfig|1 arch/arm/mach-omap2/board-omap4panda.c | 30 ++ arch/arm/mach-omap2/id.c | 39 arch/arm/mach-omap2/include/mach/id.h |1 include/net/mac-platform.h | 39 net/Kconfig|5 + net/ethernet/Makefile |3 + net/ethernet/mac-platform.c| 151 9 files changed, 282 insertions(+), 22 deletions(-) create mode 100644 include/net/mac-platform.h create mode 100644 net/ethernet/mac-platform.c ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Florian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values
On 10/07/12 20:37, the mail apparently from Florian Fainelli included: Hi - Le jeudi 05 juillet 2012 04:44:33, Andy Green a écrit : The following series adds some code to generate legal, locally administered MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at net/ethernet taking care of accepting device path / MAC mapping registrations and running a notifier to enforce the requested MAC when the matching network device turns up. This looks like something you can solve by user-space entirely. Expose the That might seem so from a openwrt perspective, where you custom cook the whole userland thing per-device, but it ain't so from a generic rootfs perspective. Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific workarounds? And Panda is not the only device with this issue. -Andy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values
On Tue, 2012-07-10 at 20:58 +0800, Andy Green (林安廸) wrote: On 10/07/12 20:37, the mail apparently from Florian Fainelli included: Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific workarounds? And Panda is not the only device with this issue. Actually I think you just answered your own question ;-) Anyway, I don't think an initrd solution is the best. Yeah, it's fine for a work around, but then I need to go and screw with the initrd if it doesn't have support for the board. If the network card already has a MAC address, why should the kernel give it another *random* one? This isn't a complex patch set, where the complexity should be put into userspace. And it makes it very convenient for people that just want the board to boot so they can test it. I'm not developing any SoC or BSP, I'm just using it to make sure my kernel changes can also be implemented for ARM. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values
Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific workarounds? And Panda is not the only device with this issue. Why should we crap all over the kernel for all these board specific problems ? Userspace code is at least pageable and generally less security critical. So your argument from that point of view is bunk. There are tons and tons of boards doing tons of horrible hacks. If we mangled the generic code for all of them the result would be a complete unmanagable pile of turd. The use of locally administered MAC addressing is policy. The helper belongs in userspace as it's clearly part of what udev is supposed to be doing via device notifications, instead of your custom mini kernel-udev hack which is what you've basically created. We've said no to lots of people (several a year). We've done so for good reasons. Most of them had more taste than your hack too (ok except the Pi which was even more broken) You need a udev rule, one single tiddly udev rule, and perhaps to expose a sysfs node somewhere if the required generation data is on the board. Hardly stinking up the userspace is it. That would also then fix any races with userspace trying to set the MAC, it would remove the need for the helper. It will avoid encoding ultra-crappy assumptions like To make use of this safely you also need to make sure that any drivers that may compete for the bus ordinal you are using (eg, mUSB and ehci in Panda case) are loaded in a deterministic order. What are you going to do when speeding up booting by parallelising more probes breaks this kind of garbage assumption ? To be honest if Fedora needs to deal with an army of craptastic devices whose vendors can't get a MAC address on the board then they probably need a single common change to ifup so that if you ifup an interface that has no MAC it generates a local one. Thats about 6 lines of userspace code in the config scripts. It's also probably a good default end user behaviour. And if you have a real MAC but it's not loaded into the device you can just shove it into the platform device. End of problem. Alan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values
The following series adds some code to generate legal, locally administered MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at net/ethernet taking care of accepting device path / MAC mapping registrations and running a notifier to enforce the requested MAC when the matching network device turns up. On PandaBoard / ES, two devices have no board-level MAC either assigned by the manufacturer or stored on the board, the last patch in the series adds these device paths and gets them set when the network device is registered. Lastly for convenient testing, there's a little patch on omap2plus_defconfig that will get Ethernet and WLAN up on Pandaboard. The patches are against today's linux-omap. Thanks to Tony Lindgren and Arnd Bergmann for comments leading to the helper in net/ethernet. --- Andy Green (4): OMAP: add cpu id register to MAC address helper NET ethernet introduce mac_platform helper OMAP4 PANDA register ethernet and wlan for automatic mac allocation config test config extending omap2plus with wl12xx etc arch/arm/configs/omap2plus_defconfig | 35 +++ arch/arm/mach-omap2/Kconfig|1 arch/arm/mach-omap2/board-omap4panda.c | 30 ++ arch/arm/mach-omap2/id.c | 39 arch/arm/mach-omap2/include/mach/id.h |1 include/net/mac-platform.h | 39 net/Kconfig|5 + net/ethernet/Makefile |3 + net/ethernet/mac-platform.c| 151 9 files changed, 282 insertions(+), 22 deletions(-) create mode 100644 include/net/mac-platform.h create mode 100644 net/ethernet/mac-platform.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
