Message-ID: <20071210193304.GA24737@2ka.mipt.ru>
Date:	Mon, 10 Dec 2007 22:33:05 +0300
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	lkml <linux-kernel@...r.kernel.org>, netdev@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, Greg KH <greg@...ah.com>
Subject: Re: [1/4] DST: Distributed storage documentation.

On Mon, Dec 10, 2007 at 08:02:28PM +0100, Kay Sievers (kay.sievers@...y.org) 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.

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

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

> Thanks,
> Kay

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists