On 09/13/2013 02:18 AM, Dan Williams wrote: > On Wed, Sep 11, 2013 at 2:00 PM, Martin Wilck <mwilck@xxxxxxxx> wrote: >> Hi Neil, >> >> I thought I might come up with an implementation of mdadm >> --detail-platform for DDF, but I encountered a problem I'd like to discuss. >> >> For DDF, we can't scan PCI devices like IMSM does, because we don't know >> all controllers supporting DDF. Thus I considered scanning block devices >> instead and looking at "foreign" vendor strings in the meta data; >> possibly also filtering by device names or types. It occured to me that >> it might be elegant to simply call conf_get_devs() for a list of devices >> to be scanned. But if I do that, config.o and its dependencies must be >> linked with mdmon, blowing up its size considerably. I figure that >> that's a no-go. But I'm also reluctant to write my own DDF-specific >> block device scanning code while there is conf_get_devs() already. >> >> Perhaps I am misunderstanding the purpose of --detail-platform? >> I wouldn't bother with it if YaST2/libstorage didn't call it in order to >> check if a "fake RAID" platform is present. > > --detail-platform is more about finding the presence of the raid > option-rom / firmware support. I can imagine the installer may want > to confirm that an array is bootable before installing to it. > > Is it enough to scan for devices that self-report as raid controllers? > Problem then becomes finding a cross-implementation method to parse > the firmware signature to detect DDF capabilities. That'd certainly be nice to have, but I can't imagine a way how to collect these data unless the vendors contribute directly, as Intel did. For LSI I'd be able to dig up a list of PCI IDs of RAID-capable controllers, but that's about all I can think of. For other vendors I have no information. Regards Martin > > -- > Dan -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
