Re: [PATCH] rbd: replace the rbd sysfs interface
From: Greg KH
Date: Wed Dec 01 2010 - 14:48:22 EST
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/