All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Sage Weil <sage@newdream.net>
Cc: Yehuda Sadeh <yehuda@hq.newdream.net>,
	ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rbd: replace the rbd sysfs interface
Date: Wed, 1 Dec 2010 11:47:51 -0800	[thread overview]
Message-ID: <20101201194751.GA1171@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1012011117460.8183@cobra.newdream.net>

On Wed, Dec 01, 2010 at 11:25:16AM -0800, Sage Weil wrote:
> Hi Greg,
> 
> I'm sure you're busy and as tired of this thread as we are, but I think
> it's close and we have (I hope) just one remaining question.  The current
> patch (see below) gives us

Sorry, I got distracted by a snowstorm knocking out my power for a few
days and then a holliday :)

>  /sys/bus/rbd/{add,remove}
>  /sys/bus/rbd/devices/<devid>/                 <-- struct device
>  /sys/bus/rbd/devices/<devid>/{some dev attrs}
>  /sys/bus/rbd/devices/<devid>/snap_<snapid>/   <-- struct device
>  /sys/bus/rbd/devices/<devid>/snap_<snapid>/{some snap attrs}
> 
> This works, and I is (I hope) using struct device properly.  The only 
> problem, purely from a user interface standpoint, is that the snaps are 
> mixed in with attributes, so anybody wanting to iterate over snaps needs 
> to do something crufty like
> 
>  $ for snap in `ls /sys/bus/rbd/devices/$id | grep ^snap_ | cut -c 6-`; do ...

What's wrong with:
	for snap in `ls /sys/bus/rbd/devices/$id/snap_*`; do ...
instead?

And you would be using libudev ideally for a .c file, and iterating over
the devices is pretty trivial that way from what I have seen.

> Adding an intermediate snaps/ subdir would let them instead do
> 
>  $ for snap in `ls /sys/bus/rbd/devices/$id/snaps/`; do ...
> 
> without worrying about the (arbitrarily named) snaps from colliding with 
> device attributes.  Assuming that is a preferable interface, is the 
> "right" way to do that to make "snaps" a struct device?  Or is there a 
> good reason why that is not preferable?

It's not preferable as that "snaps" directory is a "blank" in the device
tree, not showing the heiarchy properly.  You can't walk the devices
back from the devices in snaps/ to the parent properly (i.e. you would
get stuck at the snaps/ directory as it's not a struct device, but a
random kobject.

Hope this helps,

greg k-h

  reply	other threads:[~2010-12-01 19:48 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-17  0:32 [PATCH] rbd: replace the rbd sysfs interface Yehuda Sadeh
2010-11-17 17:19 ` Greg KH
2010-11-17 23:00   ` Yehuda Sadeh Weinraub
2010-11-17 23:00     ` Yehuda Sadeh Weinraub
2010-11-18  1:30     ` Greg KH
2010-11-18 22:53       ` Yehuda Sadeh Weinraub
2010-11-18 22:53         ` Yehuda Sadeh Weinraub
2010-11-19  2:08         ` Greg KH
2010-11-19 20:42           ` Yehuda Sadeh Weinraub
2010-11-19 20:42             ` Yehuda Sadeh Weinraub
2010-11-23  0:14             ` Greg KH
2010-11-23  0:14               ` Greg KH
2010-11-23  0:48               ` Yehuda Sadeh Weinraub
2010-11-23  0:48                 ` Yehuda Sadeh Weinraub
2010-11-23  0:58                 ` Greg KH
2010-11-23  0:58                   ` Greg KH
2010-11-23  1:19                   ` Yehuda Sadeh Weinraub
2010-11-23  1:19                     ` Yehuda Sadeh Weinraub
2010-11-24  0:23                   ` Yehuda Sadeh
2010-12-01 19:25                     ` Sage Weil
2010-12-01 19:47                       ` Greg KH [this message]
2010-12-01 20:08                         ` Sage Weil
2010-12-01 20:23                           ` Greg KH
2010-12-02  0:11                             ` Sage Weil
2010-11-22 23:33           ` Yehuda Sadeh
2010-11-23  0:14             ` Greg KH
2010-11-23  0:45               ` Sage Weil
2010-11-23  0:56                 ` Greg KH

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=20101201194751.GA1171@kroah.com \
    --to=greg@kroah.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sage@newdream.net \
    --cc=yehuda@hq.newdream.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.