Re: [mdadm git pull] support for detecting platform raid capabilities and some fixes

["Dan Williams" <dan.j.williams@intel.com>]

On Wed, Nov 26, 2008 at 5:13 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, Nov 27, 2008 at 00:45, Dan Williams <dan.j.williams@intel.com> wrote:
>> This implementation crawls through sysfs to put this information
>> together, I believe it is crawling in a future proof fashion, but here
>> are my assumptions:
>> 1/ /sys/bus/pci/drivers/ahci/<x>/device will identify a pci ahci device
>
> Why "device"? You just check for the "device" attribute file of the PCI device?
>

$ ls /sys/bus/pci/drivers/ahci/
0000:00:1f.2/	module/	uevent
bind			new_id	unbind

I look for the 'device' file to disambiguate '0000:00:1f.2' from
'module' or some other object that appears in the future.  The other
attributes are discarded because they are not directories.

>> 1/ An attempt to cover the delay between mdadm creating an array and the
>> friendly-named device node showing up in /dev/md/ by calling 'udevadm
>> settle' before starting starting Incremental assembly.  This
>> specifically fixes scripts that do:
>> mdadm -A /dev/md/<container>
>> mdadm -I /dev/md/<container>
>> There is a good chance there is a better place to put this call, but
>> putting it in create_mddev didn't work, and moving it up in main()
>> resulted in a hang.  I didn't want to hold up the other patches for this
>> debug.
>
> If mdadm calls "udevadm settle", we can not call mdadm (which we do
> already) from udev rules because it will just deadlock.
>
> We need to make "udevadm settle" smarter and not to wait for its own
> event, or make it wait for something specific and not just "all"
> events, or find a different way for mdadm to sync with udev.
>

It just sounds like we need to be careful that the path that udev
triggers when it calls mdadm does not result in another call to
"udevadm settle" which should be ok because udev should never be
creating md devices, right?

Thanks,
Dan