Re: [RFC PATCH] block: Add new generic block device naming interface

From: Tejun Heo
Date: Thu Apr 25 2013 - 17:15:15 EST


Hello,

On Thu, Apr 25, 2013 at 04:07:26PM -0500, scameron@xxxxxxxxxxxxxxxxxx wrote:
> > Hmmm... maybe I'm missing something but the names assigned this way
> > wouldn't have any kind of stability across boots. Is that good
> > enough?
>
> Perhaps not. I am open to suggestions on that front -- perhaps there's
> some way for udev to help sort things out?

udev already does that by adding names by types, connection, UUID,
what not. They aren't the names recognized by the kernel, so I
suppose aren't useful for your purpose? But then again udev can't
really do anything further.

> > But, if so, I'm kinda having hard time understanding what
> > it'd be able to do which any other name can't do.
> >
> > Can you please elaborate the use case?
>
> Sure.
>
> Right now, if you add a new block driver, if you want grub to be able
> to boot it, you also have to modify grub. This is true for each new
> block driver that comes along. This is not the case for SCSI HBA
> drivers, because they all get to share the sd driver and its device
> name space, and grub already knows about that. You can add all kinds
> of SCSI HBA drivers and never have to worry about needing to modify
> grub to get boot support.

So, the question, I suppose, is why grub needs to be changed when the
stem of device names changes. Why does it need to do that? Is it
just an implementation detail or is it something more fundamental?

Thanks.

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/