[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061206173245.GA23405@filer.fsl.cs.sunysb.edu>
Date: Wed, 6 Dec 2006 12:32:45 -0500
From: Josef Sipek <jsipek@....cs.sunysb.edu>
To: Jan Engelhardt <jengelh@...ux01.gwdg.de>
Cc: "Josef 'Jeff' Sipek" <jsipek@...sunysb.edu>,
linux-kernel@...r.kernel.org, torvalds@...l.org, akpm@...l.org,
hch@...radead.org, viro@....linux.org.uk,
linux-fsdevel@...r.kernel.org, mhalcrow@...ibm.com
Subject: Re: [PATCH 26/35] Unionfs: Privileged operations workqueue
On Tue, Dec 05, 2006 at 02:50:13PM -0500, Josef Sipek wrote:
> On Tue, Dec 05, 2006 at 08:27:51PM +0100, Jan Engelhardt wrote:
> >
> > On Dec 4 2006 07:30, Josef 'Jeff' Sipek wrote:
> > >+#include "union.h"
> > >+
> > >+struct workqueue_struct *sioq;
> > >+
> > >+int __init init_sioq(void)
> >
> > Although it's just me, I'd prefer sioq_init(), sioq_exit(),
> > sioq_run(), etc. to go in hand with what most drivers use as naming
> > (i.e. <modulename> "_" <function>).
>
> That makes sense.
Hrm. Looking at the code, I noticed that the opposite is true:
destroy_filldir_cache();
destroy_inode_cache();
destroy_dentry_cache();
unregister_filesystem(&unionfs_fs_type);
The last one in particular...
> > >+void __unionfs_mknod(void *data)
> > >+{
> > >+ struct sioq_args *args = data;
> > >+ struct mknod_args *m = &args->mknod;
> >
> > Care to make that: const struct mknod_args *m = &args->mknod;?
> > (Same for other places)
>
> Right.
If I make the *args = data line const, then gcc (4.1) yells about modifying
a const variable 3 lines down..
args->err = vfs_mknod(m->parent, m->dentry, m->mode, m->dev);
Sure, I could cast, but that seems like adding cruft for no good reason.
Josef "Jeff" Sipek.
--
Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein
-
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