[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080129185448.GA358@suse.de>
Date: Tue, 29 Jan 2008 10:54:48 -0800
From: Greg KH <gregkh@...e.de>
To: Mark Fasheh <mark.fasheh@...cle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, ocfs2-devel@....oracle.com
Subject: Re: [git pull] Fix recent Ocfs2 breakage
On Mon, Jan 28, 2008 at 11:44:02PM -0800, Joel Becker wrote:
> On Mon, Jan 28, 2008 at 09:08:04PM -0800, Greg KH wrote:
> > And please please please please document stuff like this, and all of the
> > different files you have in this subdirectory in Documentation/ABI/ so
>
> Huh, I didn't know Documentation/ABI existed. That would
> certainly help in the future.
Yeah, not many people know about it, despite being present for over a
year now :(
So I'm starting to poke people to fix this. I'd like to see all new
sysfs attributes (and syscalls and other stuff that is an ABI) be
documented here. As well as creating the information for the ABI we
currently have, but I know that will take longer.
> > those of us who are trying to figure out the code (and there's still
> > parts of the kobject usage I'm pretty sure is not correct) can have a
>
> ocfs2 kobject usage, or other folks'? If there's anything in
> the ocfs2 usage that you are unsure of, feel free to ask!
Ok, great. Here's a few questions:
- ocfs2/cluster/sys.c creates a single kset, o2cb, that is in
/sys/o2cb (and I had moved it to /sys/fs/o2cb/) In that directory
it seems there is only 1 file, O2NM_API_VERSION. Is that really all
that goes into that directory? If so, this can be cleaned up even
further and only a single kobject is needed, a kset is overkill.
- that kset is then passed to the mlog_sys_init() file to chain
another subdirectory off of this. Here's where the meat of the
sysfs files are. You use a custom kset and show/store operations to
describe some bit fields? You never use the kobject here, but only
go off of the name of the attribute file, which is fine. But again,
using a ktype/kset is way overkill for this. It can be all
simplified to only have 1 kobject for the directory, and then the
individual attributes can be a kobj_attribute.
Actually that wasn't too bad. It was gfs2 that I was thinking about
with regard to totally strange kobject abuse, I'll go poke those
developers about it while I'm remembering :)
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/
Powered by blists - more mailing lists