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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130425211459.GC10990@mtj.dyndns.org>
Date:	Thu, 25 Apr 2013 14:14:59 -0700
From:	Tejun Heo <tj@...nel.org>
To:	scameron@...rdog.cce.hp.com
Cc:	axboe@...nel.dk, neilb@...e.de, hch@...radead.org,
	jmoyer@...hat.com, hare@...e.de, shaohua.li@...el.com,
	vgoyal@...hat.com, stephenmcameron@...il.com,
	linux-kernel@...r.kernel.org, lsorense@...lub.uwaterloo.ca
Subject: Re: [RFC PATCH] block: Add new generic block device naming interface

Hello,

On Thu, Apr 25, 2013 at 04:07:26PM -0500, scameron@...rdog.cce.hp.com 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/