linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Karel Zak <kzak@redhat.com>
Cc: Milan Broz <mbroz@redhat.com>,
	device-mapper development <dm-devel@redhat.com>,
	Jun'ichi Nomura <j-nomura@ce.jp.nec.com>,
	Valdis.Kletnieks@vt.edu, linux-kernel@vger.kernel.org,
	linux-raid@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, Kay Sievers <kay.sievers@vrfy.org>
Subject: Re: [dm-devel] linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
Date: Thu, 13 Jan 2011 14:37:22 +0100	[thread overview]
Message-ID: <20110113133722.GG30719@htj.dyndns.org> (raw)
In-Reply-To: <20110113132637.GH16523@nb.net.home>

Hello, Karel.

On Thu, Jan 13, 2011 at 02:26:37PM +0100, Karel Zak wrote:
> > Yeah, sure, it's not like I can afford to avoid fixing it at this
> > point anyway, but I still want to point out it's at the wrong layer
> > and shouldn't have been added like this, really.  If you want blkid to
> > identify it, the proper thing to do would be querying blk device for
> > the claimer and then use claimer-specific method to query them.  It's
> 
>  It seems that dependencies (holders/slaves) between devices is pretty
>  generic thing. Why do you think that we need claimer-specific method?
>  The /sys filesystem is better that ictls in many ways.

Because sysfs is already complex enough without representing
dependency information without strictly defined strcture in it.  It's
for exporting the device tree to users.  We have developed interesting
ways to exploit it but it generally has proven to be a bad idea to add
symlinks without clearly defined structure beneath it.  People end up
using them differently and often they don't understand how the kobject
sysfs things are wired and it ends up with a lot of cruft exporting
something which is designed by small number of people without really
considering what's going on in the rest of the hierarchy.

> > not like the current method would make sense for btrfs or whatnot.
> 
>  Could you be more verbose, please?

If the symlinkery was something which could properly replace
configuration and query, sure, let's standardize it and share it among
all possible claimers of block devices, but it's not.  md, dm, btrfs
need to export and process way more information than can be represnted
in these symlinks and it's there more as a pretty thing than anything
which is actually necessary and useful.  And the original
implementation directly played with kobjects (in an unnecessarily
complicated way too) and allowed any kobject to be linked.  Things
like that just never end up pretty.

So, just don't do it.  Sysfs is for device hierarchy.  Don't try to
shove pretty looking things there (unless it's something widely agreed
on and necessary, of course).

Thanks.

-- 
tejun

  reply	other threads:[~2011-01-13 13:37 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-12 17:34 linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac() Valdis.Kletnieks
2011-01-13  0:23 ` Milan Broz
2011-01-13  2:19   ` Jun'ichi Nomura
2011-01-13 11:06     ` Tejun Heo
2011-01-13 11:26       ` [dm-devel] " Milan Broz
2011-01-13 12:27         ` Karel Zak
2011-01-13 13:12           ` Tejun Heo
2011-01-13 13:26             ` Karel Zak
2011-01-13 13:37               ` Tejun Heo [this message]
2011-01-13 13:52                 ` Tejun Heo
2011-01-13 13:58                 ` Milan Broz
2011-01-13 14:11                   ` Tejun Heo
2011-01-13 14:25                     ` Milan Broz
2011-01-13 14:30                       ` Tejun Heo
2011-01-13 14:43                         ` Kay Sievers
2011-01-13 15:03                           ` Milan Broz
2011-01-14  7:38                             ` Jun'ichi Nomura
2011-01-13 15:59                           ` Karel Zak
2011-01-13 16:10                             ` [dm-devel] " Kay Sievers
2011-01-14 15:07                               ` Karel Zak
2011-01-14 15:23                                 ` Kay Sievers
2011-01-13 14:45                         ` Theodore Tso
2011-01-13 20:18                           ` NeilBrown
2011-01-13 20:41                             ` Ted Ts'o
2011-01-14 16:20                               ` Tejun Heo
     [not found]                               ` <20110114162022.GC978@htj.dyndns.org>
2011-01-14 17:59                                 ` Ted Ts'o
2011-01-14 18:23                                   ` Tejun Heo
2011-01-13 14:49                         ` Milan Broz
2011-01-14 16:35                           ` Tejun Heo
2011-01-13 17:21     ` [PATCH] block: restore multiple bd_link_disk_holder() support Tejun Heo
2011-01-13 18:42       ` Milan Broz
2011-01-14  7:31         ` Jun'ichi Nomura
2011-01-14 16:10           ` [PATCH UPDATED] " Tejun Heo
2011-01-14 21:09             ` Milan Broz
2011-01-17  0:18               ` Jun'ichi Nomura

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=20110113133722.GG30719@htj.dyndns.org \
    --to=tj@kernel.org \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=dm-devel@redhat.com \
    --cc=j-nomura@ce.jp.nec.com \
    --cc=kay.sievers@vrfy.org \
    --cc=kzak@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=mbroz@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).