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
next prev parent reply other threads:[~2010-12-01 19:48 UTC|newest]
Thread overview: 21+ 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-18 1:30 ` Greg KH
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-23 0:14 ` Greg KH
2010-11-23 0:48 ` Yehuda Sadeh Weinraub
2010-11-23 0:58 ` Greg KH
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox