All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Neil Brown <neilb@suse.de>
Cc: klibc list <klibc@zytor.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-raid@vger.kernel.org
Subject: Re: Exporting which partitions to md-configure
Date: Mon, 30 Jan 2006 18:05:16 -0800	[thread overview]
Message-ID: <43DEC5DC.1030709@zytor.com> (raw)
In-Reply-To: <17374.50399.1898.458649@cse.unsw.edu.au>

Neil Brown wrote:
> 
> Well, grepping through fs/partitions/*.c, the 'flags' thing is set by
>  efi.c, msdos.c sgi.c sun.c
> 
> Of these, efi compares something against PARTITION_LINUX_RAID_GUID,
> and msdos.c, sgi.c and sun. compare something against
> LINUX_RAID_PARTITION.
> 
> The former would look like
>   e6d6d379-f507-44c2-a23c-238f2a3df928
> in sysfs (I think);
> The latter would look like
>   fd
> (I suspect).
> 
> These are both easily recognisable with no real room for confusion.

Well, if we're going to have a generic facility it should make sense 
across the board.  If all we're doing is supporting legacy usage we 
might as well export a flag.

I guess we could have a single entry with a string of the form 
"efi:e6d6d379-f507-44c2-a23c-238f2a3df928" or "msdos:fd" etc -- it 
really doesn't make any difference to me, but it seems cleaner to have 
two pieces of data in two different sysfs entries.

> 
> And if other partition styles wanted to add support for raid auto
> detect, tell them "no". It is perfectly possible and even preferable
> to live without autodetect.   We should support legacy usage (those
> above) but should discourage any new usage.
> 

Why is that, keeping in mind this will all be done in userspace?

	-hpa


  reply	other threads:[~2006-01-31  2:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-31  0:52 Exporting which partitions to md-configure H. Peter Anvin
2006-01-31  1:10 ` Neil Brown
2006-01-31  1:42   ` H. Peter Anvin
2006-01-31  2:01     ` Neil Brown
2006-01-31  2:05       ` H. Peter Anvin [this message]
2006-02-06  1:46         ` Neil Brown
2006-02-06  3:29           ` Kyle Moffett
2006-02-07  2:47           ` [klibc] " H. Peter Anvin
2006-02-07  9:03             ` Neil Brown
2006-02-07 10:43             ` Luca Berra
2006-02-07 15:46               ` H. Peter Anvin
2006-02-07 16:47                 ` Luca Berra
2006-02-07 16:55                   ` H. Peter Anvin
2006-02-07 17:03                     ` Luca Berra
2006-01-31  6:49     ` Chris Wedgwood
2006-01-31  1:43   ` Kyle Moffett
2006-01-31  1:45     ` H. Peter Anvin
2006-01-31  2:01     ` Neil Brown
2006-01-31  2:38       ` H. Peter Anvin
2006-01-31  6:42       ` Kyle Moffett
2006-01-31  3:21 ` [klibc] " Greg KH
2006-01-31  3:24   ` Greg KH
2006-01-31  6:53     ` Kyle Moffett
2006-01-31  3:53   ` H. Peter Anvin

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=43DEC5DC.1030709@zytor.com \
    --to=hpa@zytor.com \
    --cc=klibc@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /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.