mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Hannes Reinecke <hare@suse.de>
Cc: scameron@beardog.cce.hp.com, axboe@kernel.dk, neilb@suse.de,
	hch@infradead.org, jmoyer@redhat.com, vgoyal@redhat.com,
	stephenmcameron@gmail.com, linux-kernel@vger.kernel.org,
	lsorense@csclub.uwaterloo.ca
Subject: Re: [RFC PATCH] block: Add new generic block device naming interface
Date: Mon, 29 Apr 2013 09:06:04 -0700	[thread overview]
Message-ID: <20130429160604.GA19814@mtj.dyndns.org> (raw)
In-Reply-To: <517E8A26.7060705@suse.de>

Hey,

On Mon, Apr 29, 2013 at 04:56:38PM +0200, Hannes Reinecke wrote:
> grub requires you to re-implement _every_ device naming scheme which
> is present in the kernel.

Are you saying that it's just a limitation in grub?

> And no, you cannot use the kernel itself as grub is run _prior_ to
> the kernel.

I don't get this part.  While booting, it's all about the number BIOS
assigned to disks.  After boot, we might as well just do mknod
/dev/grub-device-N if grub is picky about the names it accept.  What
am I missing here?

> As there is no common naming scheme for block devices each and
> every block device driver has implemented it own.
> So grub need to re-implement each and every device naming
> for these drivers.

Sure, I heard that a couple times but nobody really explained why
that's the case.  Is it something fundamental or is it just an
implementation artifact?  Can't it be fixed from grub side?  If not,
why?

> The approach from Stephen would solve that.

At the cost of losing per-driver semi-stable enumeration.  I don't
think we want to lose that in favor of working around an
implementation detail in grub.

Thanks.

-- 
tejun

  parent reply	other threads:[~2013-04-29 16:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-25 20:22 Stephen M. Cameron
2013-04-25 20:40 ` Tejun Heo
2013-04-25 21:07   ` scameron
2013-04-25 21:14     ` Tejun Heo
2013-04-25 22:12       ` scameron
2013-04-26 19:03         ` Tejun Heo
2013-04-29 14:56           ` Hannes Reinecke
2013-04-29 15:17             ` Vivek Goyal
2013-04-29 16:06             ` Tejun Heo [this message]
  -- strict thread matches above, loose matches on Subject: below --
2013-03-28 16:18 Stephen M. Cameron
2013-03-11 19:00 Stephen M. Cameron

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=20130429160604.GA19814@mtj.dyndns.org \
    --to=tj@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=hare@suse.de \
    --cc=hch@infradead.org \
    --cc=jmoyer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lsorense@csclub.uwaterloo.ca \
    --cc=neilb@suse.de \
    --cc=scameron@beardog.cce.hp.com \
    --cc=stephenmcameron@gmail.com \
    --cc=vgoyal@redhat.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

Powered by JetHome