Re: [1/4] DST: Distributed storage documentation.

On Mon, 2007-12-10 at 22:33 +0300, Evgeniy Polyakov wrote:
On Mon, Dec 10, 2007 at 08:02:28PM +0100, Kay Sievers (kay.sievers@xxxxxxxx) wrote:
uganda:~/codes# ls -l /sys/devices/storage/n-0-ffff81003ebc220/
total 0
drwxr-xr-x 2 root root 0 2007-12-10 13:23 power
-r--r--r-- 1 root root 4096 2007-12-10 13:30 size
-r--r--r-- 1 root root 4096 2007-12-10 13:30 start
-r--r--r-- 1 root root 4096 2007-12-10 13:30 type
-rw-r--r-- 1 root root 4096 2007-12-10 13:30 uevent

This is a "struct device" instance without a subsystem (bus/class),
right? It will not send an uevent to userspace. Is that intended? Why
don't you add them all to the dst bus?

I created dst bus for storage devices only, nodes are very different
objects, and actually they do not need any events from above, but I need
to put some attributes somewhere, so it is 'empty' device.

Ok.

Actually not - I have to set reference counter to something other than 1
or +/- 1, and thus will have to call kref_get() in a loop, which is a
very ugly step. Is there kref_set() or somethinglike that? At least not
in 2.6.22 what I'm using for now.

Yeah, a loop would look pretty ugly. How about just adding kref_set(),
if you need it.

Well, then it distributed storage will not be able to build as
standalone module, and kref_set() itself will not be accepted as a single
patch, since there are no in-kernel users :)
It is easily doable though.

Most rules have exceptions. :) Send a patch, so we can see how it looks
like.

Why don't you use groups for the attributes?

For 3-4 attributes it is faster to register them in a loop than typing
another structure :)

Yeah, but if you would need to recover from an error when the creation
of a file fails, a group would do the proper "rollback".

I do not care about such errors - if there is such an error for a file,
which exports information about type of the node (i.e. string "L" or "R")
or some other very meaningful info, then system has enough to care about
instead of this, so dst does not do anything special - it ignores such
errors :)

On exit path it will be checked and removed correctly.
If there will be additional sysfs files, I think group is a good way to
implement them.

Why don't you use default attributes for the device, where you get all
error handling done by the core.

What is 'default attributes' and for what devices?
All my sysfs files are so much trivial, so they do not need anything
special and I do not see what is error handling you mentioned.

If all devices of a subsystem (bus/class) are of the same type, you can
set a default array of attributes in the "struct bus/class" to be
created at every device. If you have multiple types of devices in the
same subsytem (bus/class) you can to assign a the "device_type", which
has the default attribute group.
That way the core will create the files before the event is sent out to
userspace, and the files can be access from the event itself. Not sure
if that is needed for dst.

Ok, I see.

DST right now has 3 types of files - storage files, it is common for
every storage device; node files, which are the same for every node; and
per-algorithm private devices - they can be different (actually only
mirroring algorithm exports something to userspace).

I think it is possible to use default attributes for storage devices,
but node device does not have a bus/class, so they will be untouched.

Sounds fine.

Thanks,
Kay

--
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/

Relevant Pages

  • Re: [1/4] DST: Distributed storage documentation.
    ... This is a "struct device" instance without a subsystem, ... It will not send an uevent to userspace. ... I created dst bus for storage devices only, ... I think it is possible to use default attributes for storage devices, ...
    (Linux-Kernel)
  • Re: New distributed storage release.
    ... I am pleased to announce new Distributed Storage (DST) project release. ... without even the implied warranty of ... * GNU General Public License for more details. ... +struct dst_crypto_completion ...
    (Linux-Kernel)
  • [PATCH/RFC] ummunot: Userspace support for MMU notifications
    ... the issue is unfixable without kernel help. ... A userspace process can open this node read-only and use the fd ... +struct ummunot_reg { ... * kernel's feature mask. ...
    (Linux-Kernel)
  • New distributed storage release.
    ... I am pleased to announce new Distributed Storage (DST) project release. ... without even the implied warranty of ... * GNU General Public License for more details. ... +struct dst_crypto_completion ...
    (Linux-Kernel)
  • [patch 10/13] signalfd/timerfd/asyncfd v5 - asyncfd core ...
    ... This is the asyncfd implementation. ... buffer results, and exposes a readinterface to userspace, and this one, ... int asyncfd(int ufd, struct asyncfd_uring *urng); ... or an error if the userspace ring is invalid. ...
    (Linux-Kernel)