Michael Tokarev wrote:
> Neil Brown wrote:
> [/dev/mdx...]
[]
>> An in any case, we have the semantic that opening an md device-file
>> creates the device, and we cannot get rid of that semantic without a
>> lot of warning and a lot of pain. And adding a new semantic isn't
>> really going to help.
>
> I don't think so. With new semantic in place, we've two options (provided
> current semantics stays, and I don't see a strong reason why it should be
> removed except of the bloat):
>
> a) with new mdadm utilizing new semantics, there's nothing to change in udev --
> it will all Just Work, by mdadm opening /dev/md-control-node (how it's called)
> and assembling devices using that, and during assemble, udev will receive proper
> events about new "disks" appearing and will handle that as usual.
>
> b) without new mdadm, it will work as before (now). And in this case, let's not
> send any udev events, as mdadm already created the nodes etc.
Forgot to add. This is important point: do NOT change current behavour wrt uevents,
ie, don't add uevents for current semantics at all. Only send uevents (and in this
case it will be normal "add" and "remove" events) when assembling arrays "the new way",
using (stable!) /dev/mdcontrol misc device, after RUN_ARRAY and STOP_ARRAY actions has
been performed.
/mjt
> So if a user wants neat and nice md/udev integration, the way to go is case "a".
> If it's not required, either case will do.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
