Op woensdag 20 maart 2013 21:28:51 schreef Thierry Vignaud: > On 20 March 2013 21:22, AL13N <[email protected]> wrote: > >> > > That's because modules.alias enables to match through wildchars. > >> > > > >> > > eg for ehci (see either /sbin/modinfo ehci_pci or > >> > > "fgrep ehci /lib/modules/3.8.3-desktop-2.mga3/modules.alias"): > >> > > > >> > > alias pci:v0000104Ad0000CC00sv*sd*bc*sc*i* ehci_pci > >> > > alias pci:v*d*sv*sd*bc0Csc03i20* ehci_pci > >> > > > >> > > That means that ehci matches both: > >> > > - 0x104A 0xCC00 (probably a device that reports a broken/bogus class) > >> > > - any PCI device whose class is PCI_CLASS_SERIAL_USB_EHCI > >> > > > >> > > Note that for this one: > >> > > - lsmod reports ehci_pci > >> > > - modinfo reports the real fs path: ehci-pci > >> > > - lspci -vvk reports: ehci-pci > >> > > >> > I understand. It is the kernel itself (and associated tools) that mix > >> > and match underscore and dash. Hence the need for a conversion patch. > >> > >> not really, it just means that in the kernel - are mapped to _; modprobe > >> tools handle both cases, just modinfo reports the filename which can > >> include '-', but it can still handle both. > >> > >> lspci and most tools just report it as it's really named (depending on > >> filename). modules.dep and modules.descr, etc... has the name as it is as > >> well, meaning there can be '-' in the name. > >> > >> i just see this workaround being effective to handle lstdetect, which > >> somehow forces all of it being lowercase... > >> > >> i don't know how much of lstdetect is hardcoded and how much of it is > >> generated, but imho the cleanest way would be to fix lstdetect, so that > >> it > >> gives the proper module names... > >> > >> i've been looking at a way to fix the module list window for choosing, > >> but > >> the problem isn't as simple as i thought, since insmod looks at > >> filenames... which is another workaround. > >> > >> @thierry: i donno what you think of it, but imo: > >> A) fixing lstdetect would be the cleanest way (maybe not the simplest) > >> B) perhaps in the comparing i can workaround this, but the compare code > >> will not be as simple as it should... > > > > forgot to mention option C: > > > > C) using kmod in stage1 > > > > but option C might not be as easy and will increase the stage1 size; and > > raises the question if stage2 is actually still needed then...? > > As already said, stage1 uses ldetect which use libkmod, thus we already > are linked to it. > mdv switched to kmod. > You can look at it. > But show me the patch before commiting it. > In the meantime please upload a stage1 with your change revertd
yeah, this might be over my head as a beginner in this kind of code... I was hoping a simple workaround would do for now, since we're already this late... but i guess since we're linking into libkmod anyway, it might as well be done. i'm not confident, but i'll give it a try. PS: i commited the revert.
