All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kevin P. Fleming" <kpfleming@backtobasicsmgmt.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: Linux software RAID vs. udev
Date: Tue, 04 May 2004 03:59:22 +0000	[thread overview]
Message-ID: <4097151A.2000303@backtobasicsmgmt.com> (raw)
In-Reply-To: <409708C4.6070905@backtobasicsmgmt.com>

Neil Brown wrote:

>>looking through the md driver, I don't even see how the first unit (md0) 
>>is getting registered by default, unless for some reason the block layer 
>>is calling md_probe for unit 0 without even being asked to.
> 
> 
> init/do_mounts_md.c:md_run_setup

OK, I saw that file but disregarded it thinking it didn't apply if I 
didn't have any autostart arrays. I'll look again to satisfy my 
curiosity :-)

> I think it would be very poor form for udev to break established and
> working semantics.  If it doesn't let you pre-create devices in /dev
> and have then stay there, then I think that is a mistake.

udev does not prevent anyone from creating any nodes in /dev they wish. 
/dev is just any filesystem you want to use, you can put anything there 
you like. The issue is that those of us that are converting to 
hotplug-driven udev are using ramfs/tmpfs for /dev, so there is no 
persistence. That means (for now) manually creating all /dev/md nodes we 
might need to use during that boot, or manually creating any required 
nodes before attempting to run mdadm. Neither of these are horrible 
solutions, they're just not elegant :-)

Since all of this infrastructure is already in place for the dm 
subsystem, I guess this leads back to implementing the md personalities 
as dm targets, but that's a much larger issue. It would solve this 
problem completely, though.


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id149&alloc_idÅ66&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

  parent reply	other threads:[~2004-05-04  3:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-01  1:25 Linux software RAID vs. udev Kevin P. Fleming
2004-05-04  2:11 ` Neil Brown
2004-05-04  3:06   ` Kevin P. Fleming
2004-05-04  3:06     ` Kevin P. Fleming
2004-05-04  3:49     ` Neil Brown
2004-05-04  3:59     ` Kevin P. Fleming [this message]
2004-05-04  7:27     ` Olaf Hering
2004-05-04 21:26     ` Luca Berra
2004-05-11  4:22     ` 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=4097151A.2000303@backtobasicsmgmt.com \
    --to=kpfleming@backtobasicsmgmt.com \
    --cc=linux-hotplug@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.