Neil Brown wrote:
[/dev/mdx...]
(much like how /dev/ptmx is used to create /dev/pts/N entries.)
[]
I have the following patch sitting in my patch queue (since about
March).
It does what you suggest via /sys/module/md-mod/parameters/MAGIC_FILE
which is the only md-specific part of the /sys
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
On Mon, 2006-11-06 at 11:18 +1100, Neil Brown wrote:
On Friday November 3, [EMAIL PROTECTED] wrote:
The persistent naming rules for /dev/disk/by-* are causing this. Md
devices will probably just get their own rules file, which will handle
this and which can be packaged and installed along
On Wednesday November 8, [EMAIL PROTECTED] wrote:
Is there a sysfs file or something similar(we could also call a md-tool)
udev could look at, before it tries to open the device? Like:
KERNEL==md*, ATTR{state}==active, IMPORT{program}= ...
If the /sys/block/mdX directory exists at all, it
On Mon, 6 Nov 2006, Neil Brown wrote:
This creates a deep disconnect between udev and md.
udev expects a device to appear first, then it created the
device-special-file in /dev.
md expect the device-special-file to exist first, and then created the
device on the first open.
could you create
On Monday November 6, [EMAIL PROTECTED] wrote:
On Mon, 6 Nov 2006, Neil Brown wrote:
This creates a deep disconnect between udev and md.
udev expects a device to appear first, then it created the
device-special-file in /dev.
md expect the device-special-file to exist first, and then
On Friday November 3, [EMAIL PROTECTED] wrote:
Hmm, why does the open() of device node of a stopped device cause an add?
Shouldn't it just return a failure, instead of creating a device?
Because that is the API I inherited. To create an MD array, you open
/dev/mdX and issue some IOCTLs.
On Fri, 2006-11-03 at 17:57 +1100, Neil Brown wrote:
On Thursday November 2, [EMAIL PROTECTED] wrote:
On Thu, 2006-11-02 at 23:32 +1100, Neil Brown wrote:
We couldn't think of any use of an offline event. So we removed the
event when the device-mapper device is suspended.
Should
On 10/31/06, Greg KH [EMAIL PROTECTED] wrote:
On Tue, Oct 31, 2006 at 05:00:46PM +1100, NeilBrown wrote:
This allows udev to do something intelligent when an
array becomes available.
cc: [EMAIL PROTECTED]
Signed-off-by: Neil Brown [EMAIL PROTECTED]
Acked-by: Greg Kroah-Hartman [EMAIL
On Thursday November 2, [EMAIL PROTECTED] wrote:
On 10/31/06, Greg KH [EMAIL PROTECTED] wrote:
On Tue, Oct 31, 2006 at 05:00:46PM +1100, NeilBrown wrote:
This allows udev to do something intelligent when an
array becomes available.
cc: [EMAIL PROTECTED]
Signed-off-by: Neil
On Thu, 2006-11-02 at 23:32 +1100, Neil Brown wrote:
On Thursday November 2, [EMAIL PROTECTED] wrote:
On 10/31/06, Greg KH [EMAIL PROTECTED] wrote:
On Tue, Oct 31, 2006 at 05:00:46PM +1100, NeilBrown wrote:
This allows udev to do something intelligent when an
array becomes available.
On Thursday November 2, [EMAIL PROTECTED] wrote:
On Thu, 2006-11-02 at 23:32 +1100, Neil Brown wrote:
and I don't remember
you suggesting change, but my memory isn't what it used to be(*), so you
probably did.
It was in the Czech Republic, but we got a few beers... :) And in the
virtual
On Tue, Oct 31, 2006 at 05:00:46PM +1100, NeilBrown wrote:
This allows udev to do something intelligent when an
array becomes available.
cc: [EMAIL PROTECTED]
Signed-off-by: Neil Brown [EMAIL PROTECTED]
Acked-by: Greg Kroah-Hartman [EMAIL PROTECTED]
-
To unsubscribe from this list: send
13 matches
Mail list logo
