linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: "Hawrylewicz Czarnowski,
	Przemyslaw" <przemyslaw.hawrylewicz.czarnowski@intel.com>
Cc: Neil Brown <neilb@suse.de>,
	"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
	"Neubauer, Wojciech" <Wojciech.Neubauer@intel.com>,
	"Ciechanowski, Ed" <ed.ciechanowski@intel.com>,
	"Labun, Marcin" <Marcin.Labun@intel.com>,
	"Czarnowska, Anna" <anna.czarnowska@intel.com>
Subject: Re: Autorebuild, new dynamic udev rules for hot-plugs
Date: Mon, 22 Nov 2010 16:11:41 -0800	[thread overview]
Message-ID: <4CEB06BD.9090407@intel.com> (raw)
In-Reply-To: <66C59AD0932712458090B447266D638C0109E6AE6C@irsmsx504.ger.corp.intel.com>

On 11/22/2010 3:50 PM, Hawrylewicz Czarnowski, Przemyslaw wrote:
>> Four comments.
>>
>> 1/ I wouldn't write a file in /lib/udev/rules.d/
>>    I think it should be written to "/dev/.udev/rules.d/"
>>    which is referred to as the "temporary rules directory"
>>    in the udev documentation.
> I am not sure if it is what we are looking for. Temporary means they disappear after reboot. It is OK as cold-plug does not need support for bare disks (or maybe I am wrong?). But in such case, one who wants to use autorebuild should invoke mdadm --activate-domains for example in /etc/init.d/local.boot or somewhere else. Second idea here is to use ActivateDomain() when one starts monitor with autorebuild enabled. Which one? I would prefer to leave it as it was written initially (considering comment #4). Then, if one removes policies from config, invoking --activate-domains should reset/remove rules (but see #3)

The intent was always to have this be something reinitialized at boot. 
Putting these in the temporary rule directory also precludes them from 
being added to the initramfs where they are not needed / potentially 
confusing.

The other intent was to only match the pci paths for the controllers we 
cared about.  That does not appear to be a part of this patch.

>
>>
>> 2/ I would be good to process the type=disk or type=part part of the
>>     policy into the rules file as well.
> OK
>
>>
>> 3/ I'm not very comfortable with hard-coding the name of the
>>     file to be created in the rules.d directory.  Maybe usage could be
>>        --activate-domains=63-md-whatever
> Good idea, but only if we store our rules in /dev/.udev/rules.d. Otherwise it would be difficult to maintain all generated rules and remove the old ones... I would leave default if not given by user, but one can pass any file name.

The issue is that this namespace belongs to the distro and since they 
need to modify initscripts to turn this feature on might as well dump 
the entirety of the naming responsibility to the user.

>> 4/ I don't think it is good to have an incomplete file in rules.d that udev
>>     might accidentally read.  We should create the file with a name with a
>>     leading '.' (assuming udev ignores those, I haven't checked) and then
>>     rename it after it has been completely written.
> You're right. In theory, such partial udev rules are excluded when udev can't interpret them properly. I have looked into udev's sources and found that it looks for "*.rules" files. All other file extensions are ignored. Files with leading dots are also omitted. I would prefer to create<name>.temp file and then rename it into<name>.rules.

There must be an existing convention for this sort of the thing, if so 
let's not invent another one.

--
Dan

  reply	other threads:[~2010-11-23  0:11 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-29 14:13 [Patch 00/17] Autorebuild Czarnowska, Anna
2010-11-17 10:22 ` Neil Brown
2010-11-17 16:04   ` Labun, Marcin
2010-11-18 23:14   ` Czarnowska, Anna
2010-11-19 12:43     ` Devel 3.2 branch issues Czarnowska, Anna
2010-11-22  3:29       ` Neil Brown
2010-11-22 17:18         ` Labun, Marcin
2010-11-22 18:47           ` Dan Williams
2010-11-23 17:34         ` Labun, Marcin
2010-11-19 15:12     ` Autorebuild, new dynamic udev rules for hot-plugs Hawrylewicz Czarnowski, Przemyslaw
2010-11-22  5:02       ` Neil Brown
2010-11-22 23:50         ` Hawrylewicz Czarnowski, Przemyslaw
2010-11-23  0:11           ` Dan Williams [this message]
2010-11-23  1:17             ` Neil Brown
2010-11-23  5:04               ` Dan Williams
2010-11-23  5:27                 ` Neil Brown
2010-11-23  6:17                   ` Dan Williams
2010-11-23 17:01               ` Hawrylewicz Czarnowski, Przemyslaw
2010-12-23 15:44                 ` Hawrylewicz Czarnowski, Przemyslaw
2010-11-22  2:16     ` [Patch 00/17] Autorebuild Neil Brown
2010-11-22 15:08       ` Czarnowska, Anna
2010-11-23  1:34         ` Neil Brown
2010-11-23 18:20           ` Labun, Marcin
2010-12-09 11:40             ` Czarnowska, Anna
2010-12-13  0:21               ` Neil Brown
2010-12-14 14:47                 ` [PATCH] fix: Monitor doesn't return after starting daemon Czarnowska, Anna
2010-12-14 21:58                   ` Neil Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CEB06BD.9090407@intel.com \
    --to=dan.j.williams@intel.com \
    --cc=Marcin.Labun@intel.com \
    --cc=Wojciech.Neubauer@intel.com \
    --cc=anna.czarnowska@intel.com \
    --cc=ed.ciechanowski@intel.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=przemyslaw.hawrylewicz.czarnowski@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).