linux-kernel - Re: [PATCH] rbd: replace the rbd sysfs interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101123001439.GB31294@kroah.com>
Date:	Mon, 22 Nov 2010 16:14:39 -0800
From:	Greg KH <greg@...ah.com>
To:	Yehuda Sadeh <yehuda@...newdream.net>
Cc:	sage@...dream.net, ceph-devel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rbd: replace the rbd sysfs interface

On Mon, Nov 22, 2010 at 03:33:07PM -0800, Yehuda Sadeh wrote:
> 
> 
> On Fri, Nov 19, 2010 at 12:42 PM, Yehuda Sadeh Weinraub <yehuda@...newdream.net> wrote:
> > One solution would be to create kobjects for (3) and for (4), without
> > using a group name. Another way, we can create groups for (2), and (3)
> > under (1), but that's about it, you can't create the snap specific
> > directory this way without resorting to some internal sysfs directory
> > creation, which will be horribly wrong. At that point we don't have
> > anything for 'snaps', and we don't really need to do any operations
> > under that directory, we just need it to exist so that it contains the
> > snapshot-specific directories.
> >
> > Another way would be to create a group for (2) under (1) and create a
> > kobject for (3), for which you can create group per snapshot.
> >
> > Am I missing something? We already have the first solution (kobjects
> > only) implemented, is there some real benefit for using the third
> > method? We'll have to manually add remove groups anyway, as snapshots
> > can be removed and new snapshots can be added.
> >
> 
> And following is the implementation for the first solution. It has a device
> for the rbd_dev, a kobject for the top snapshot directory and a kobject per
> snapshot. Please let me know if there's any issue with this implementation.
> We'd like to get this fixed for 2.6.37 and considering the large patch,
> it'd be nice getting an ack for it.

It's way too late for .37, as this is new stuff, right?

Anyway, see my previous message about why you should not use kobjects
here at all.

thanks,

greg k-h
--
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/