LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org> To: Ian Kent <raven@themaw.net> Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, autofs@linux.kernel.org Subject: Re: [PATCH 4/6] autofs4 - make autofs type usage explicit Date: Mon, 27 Oct 2008 13:40:50 -0700 [thread overview] Message-ID: <20081027134050.c85a28dd.akpm@linux-foundation.org> (raw) In-Reply-To: <20081023023532.4508.56823.stgit@raven.themaw.net> On Thu, 23 Oct 2008 10:35:32 +0800 Ian Kent <raven@themaw.net> wrote: > This patch further improves autofs mount type usage and provides > supplementry explanation of the changes made in the previous patch > "autofs4 - cleanup autofs mount type usage". > > Changes introduced in "autofs4 - cleanup autofs mount type usage": > > - the type assigned at mount when no type is given is changed > from 0 to AUTOFS_TYPE_INDIRECT. This was done because 0 and > AUTOFS_TYPE_INDIRECT were being treated implicitly as the same > type. > > - previously, an offset mount had it's type set to > AUTOFS_TYPE_DIRECT|AUTOFS_TYPE_OFFSET but the mount control > re-implementation needs to be able distinguish all three types. > So this was changed to make the type setting explicit. > > - a type AUTOFS_TYPE_ANY was added for use by the re-implementation > when checking if a given path is a mountpoint. It's not really a > type as we use this to ask if a given path is a mountpoint in the > autofs_dev_ioctl_ismountpoint() function. > > Changes introduced in this patch: > > - macros to set and test the autofs mount types have been added to > improve readability and make the type usage explicit. ^^^^^^^^^^^^^^^^^^^ <<-- ?? > - the mount type is used from user space for the mount control > re-implementtion so, for consistency, all the definitions have > been moved to the user space include file include/linux/auto_fs4.h. > > ... > > - if (sbi->type == AUTOFS_TYPE_INDIRECT) > + if (autofs_type_indirect(sbi->type)) spose so. > - *type = AUTOFS_TYPE_INDIRECT; > + set_autofs_type_indirect(*type); That's pretty nasty. One doesn't expect a "function" to modify a variable which was passed by value. This interface _requires_ that set_autofs_type_indirect() be implemented as a macro. This didn't improve readability. > > ... > > +#define set_autofs_type_indirect(type) (type = AUTOFS_TYPE_INDIRECT) You'll find very few places in the kernel pull tricks like this, for good reasons. The obnoxious exceptions include local_irq_save() and friends. > +#define autofs_type_indirect(type) (type == AUTOFS_TYPE_INDIRECT) I guess that's OK. But why was it implemented as a macro? It didn't _need_ to be implemented in cpp - it could have been implemented in C. > + > +#define set_autofs_type_direct(type) (type = AUTOFS_TYPE_DIRECT) > +#define autofs_type_direct(type) (type == AUTOFS_TYPE_DIRECT) > + > +#define set_autofs_type_offset(type) (type = AUTOFS_TYPE_OFFSET) > +#define autofs_type_offset(type) (type == AUTOFS_TYPE_OFFSET) > + > +#define autofs_type_trigger(type) \ > + (type == AUTOFS_TYPE_DIRECT || type == AUTOFS_TYPE_OFFSET) And this one is dangerous. If passed an expression-with-side-effects it will evaluate that expression either once or twice. Bad. Should be implemented in C.
next prev parent reply other threads:[~2008-10-27 20:43 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-10-23 2:35 [PATCH 1/6] autofs4 - correct offset mount expire check Ian Kent 2008-10-23 2:35 ` [PATCH 2/6] autofs4 - remove string terminator check Ian Kent 2008-10-27 20:31 ` Andrew Morton 2008-10-28 0:27 ` Ian Kent 2008-10-28 0:55 ` Andrew Morton 2008-10-28 1:04 ` Ian Kent 2008-10-28 1:02 ` Ian Kent 2008-10-23 2:35 ` [PATCH 3/6] autofs4 - collect version check return Ian Kent 2008-10-23 2:35 ` [PATCH 4/6] autofs4 - make autofs type usage explicit Ian Kent 2008-10-27 20:40 ` Andrew Morton [this message] 2008-10-28 0:28 ` Ian Kent 2008-10-28 13:24 ` Jeff Moyer 2008-10-23 2:35 ` [PATCH 5/6] autofs4 - improve parameter usage Ian Kent 2008-10-23 2:35 ` [PATCH 6/6] autofs4 - cleanup expire code duplication Ian Kent
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20081027134050.c85a28dd.akpm@linux-foundation.org \ --to=akpm@linux-foundation.org \ --cc=autofs@linux.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=raven@themaw.net \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).