* Arno Schuring [Mit Apr 06, 2011 at 01:00:23 +0200]: > Thusly spoke maximilian attems (maks@debian.org on 2011-04-05 06:44 +0000): [...] > > As you noticed the file is unowned and can be removed and the > > initramfs regenerated. > > Nevertheless your fail in MODULES=dep is interesting and didn't have > > time yet to properly read this corresponding bug. > Since I had already spent so much time reading into the source, I spent > another hour yesterday to rewrite hook-functions to my liking. Patch > attached. It basically replaces the entire sysfs-from-dev divination > with a walker that uses sysfs' slave links to reach the underlying > device, collecting modules along the way. > Please treat this as an FYI, not a push. The exercise is academic > anyway, since this is not in any way a resource-constrained device. I'm > not comfortable signing off on this code, because > a) I simply can't test and have no experience with block devices other > than lvm, md and plain partitions. > b) the code assumes a lot about sysfs that I have not been able to > support with documentation: > - there appears to be no guarantee about the existence of a block > device at all (maybe it's driver-dependent?) > - no guarantee about whether following slaves/ in /block/ will always > reach an endpoint under /devices/ > - "Never depend on the "device"-link" is mentioned explicitly in the > document, but there appears to be no other way to reach driver/ from > /block/ (?). It also explicitly says "Accessing > /sys/class/net/eth0/device is a bug in the application" > c) initramfs is not exactly the place where you can afford to be naive > without consequence > That said, this code WorksForMe(tm), I've tried very hard not to > break any old code paths. It can't replace the existing code anyway > because it relies on udev, which is non-essential. I think > sys_walk_device might be useful though. > Oh, and there's several indentation violations to avoid huge > whitespace-only changes. Like I said, it's not a submission. So, maximilian (and other kernel devs reading this) - how do we plan to proceed with this issue? a) Align/integrate this patch? b) Further investigate? c) Mark won't fix? d) ...? Please comment. :) regards, -mika-
Attachment:
signature.asc
Description: Digital signature