[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1320859800.8294.27.camel@dabdike.int.hansenpartnership.com>
Date: Wed, 09 Nov 2011 11:30:00 -0600
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Tejun Heo <tj@...nel.org>
Cc: Jens Axboe <axboe@...nel.dk>,
Nao Nishijima <nao.nishijima.xt@...achi.com>,
Kay Sievers <kay.sievers@...y.org>,
Greg Kroah-Hartman <gregkh@...e.de>,
Alan Cox <alan@...ux.intel.com>,
Al Viro <viro@...iv.linux.org.uk>,
linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [PATCH] block: Revert "[SCSI] genhd: add a new attribute
"alias" in gendisk"
On Wed, 2011-11-09 at 08:25 -0800, Tejun Heo wrote:
> This reverts commit a72c5e5eb738033938ab30d6a634b74d1d060f10.
>
> The commit introduced alias for block devices which is intended to be
> used during logging although actual usage hasn't been committed yet.
> This approach adds very limited benefit (raw log might be easier to
> follow) which can be trivially implemented in userland but has a lot
> of problems.
It has the specific benefit that on snipped logs we don't get a mismatch
between device name and actual device.
We already had this discussion at the kernel summit. The structured
logging that might give us this facility in userspace isn't there yet
(and may not be for a while), so while users cut and paste logs it's
useful for the logs to show the device preferred name.
With just logs, we can't solve the cross reference problem, since the
cross references appear at different points in the log files.
> It is much worse than netif renames because it doesn't rename the
> actual device but just adds conveninence name which isn't used
> universally or enforced. Everything internal including device lookup
> and sysfs still uses the internal name and nothing prevents two
> devices from using conflicting alias - ie. sda can have sdb as its
> alias.
>
> This has been nacked by people working on device driver core,
Which is why it went into gendisk rather than the driver core
> block
> layer and kernel-userland interface and shouldn't have been
> upstreamed. Revert it.
No, I can't agree with this ... if you propose a working alternative,
I'm listening, but in the absence of one, I think the hack fills a gap
we have in log analysis and tides us over until we have an agreed on
proper solution (at which point, I'm perfectly happy to pull the hack
back out).
James
--
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/
Powered by blists - more mailing lists