On Sat, 2012-12-08 at 15:06 +0100, Felix Fietkau wrote: > >> The proper long term solution is to make sure that the kernel does the > >> right thing and doesn't require userspace fixup for these devices. >> > > As per previous discussion, this just isn't going to happen on lantiq. > > Well, doing a userspace fixup is a hack and no amount of dressing it up > to appear clean will change that.
It's a hack wherever we do it. The "proper" solution is for the Ethernet devices (and ATM devices) to have their own EEPROM or whatever which stores their MAC/ESI, and for the device driver to pick it up directly as $DEITY intended. But populating each device with its own EEPROM adds to the BOM, so it's entirely understandable that they *don't* do this, and they add it into the system flash. But it means that we end up with a system-wide hack necessary to get that information from the system flash storage into the device/driver somehow. Doing this in the kernel requires hacking each and every driver on affects boards, to pick its MAC address up from some special place which may differ from platform to platform. It's painful, and any kernel hacker is likely to suggest quite strongly that it *doesn't* live in the kernel. The kernel provides an API for userspace to set the MAC/ESI on Ethernet and ATM devices, and userspace already *has* stuff in place to support that and to override the MAC in cases where the device's own one isn't sufficient for some reason. To me, it doesn't seem to make much sense *not* to use/extend that existing setup. I really don't want to see this done in the kernel. It lives in userspace. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
