All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Marek <mmarek@suse.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-kbuild@vger.kernel.org, "Jörn Engel" <joern@logfs.org>,
	"Prasad Joshi" <prasadjoshi.linux@gmail.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] logfs: clarify MTD dependency
Date: Fri, 27 Nov 2015 15:50:05 +0100	[thread overview]
Message-ID: <56586D9D.1000603@suse.com> (raw)
In-Reply-To: <3269089.8XYbbcUOLH@wuerfel>

On 2015-11-27 15:30, Arnd Bergmann wrote:
> On Friday 27 November 2015 15:14:06 Michal Marek wrote:
>>
>> Hi Arnd,
>>
>> I hit this as well and was about to submit a slightly different fix. Can
>> you try the logfs portion of the below patch? Proper changelog is to be
>> done, but the gist of the patch is that IS_REACHABLE(CONFIG_FOO) 
>> evaluates to 1 if CONFIG_FOO=y or we are building a module and
>> CONFIG_FOO=m.
>>
> 
> I thought about doing it that way, and I'm sure that also worked.
> The possible behaviors are basically:
> 
> a) before your original patch, building logfs with CONFIG_MTD=m would
>    silently leave out MTD support, which was rather confusing.
> 
> b) with my patch, it becomes impossible to have logfs as the built-in
>    root file system on a block device while also using CONFIG_MTD=m,
>    and that may be slightly annoying
> 
> c) your patch restores a), but makes it work in the case where both
>    logfs and mtd are loadable modules, which is an improvement but
>    may still confuse users.
> 
> My preference is still version b) as I sent, but I don't really mind
> your version either.

I used the IS_REACHABLE macro because it hides the boolean expressions
nicely :). But I also do not insist on a particular solution. Jörn, what
would be your preference?

Thanks,
Michal

WARNING: multiple messages have this Message-ID (diff)
From: mmarek@suse.com (Michal Marek)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] logfs: clarify MTD dependency
Date: Fri, 27 Nov 2015 15:50:05 +0100	[thread overview]
Message-ID: <56586D9D.1000603@suse.com> (raw)
In-Reply-To: <3269089.8XYbbcUOLH@wuerfel>

On 2015-11-27 15:30, Arnd Bergmann wrote:
> On Friday 27 November 2015 15:14:06 Michal Marek wrote:
>>
>> Hi Arnd,
>>
>> I hit this as well and was about to submit a slightly different fix. Can
>> you try the logfs portion of the below patch? Proper changelog is to be
>> done, but the gist of the patch is that IS_REACHABLE(CONFIG_FOO) 
>> evaluates to 1 if CONFIG_FOO=y or we are building a module and
>> CONFIG_FOO=m.
>>
> 
> I thought about doing it that way, and I'm sure that also worked.
> The possible behaviors are basically:
> 
> a) before your original patch, building logfs with CONFIG_MTD=m would
>    silently leave out MTD support, which was rather confusing.
> 
> b) with my patch, it becomes impossible to have logfs as the built-in
>    root file system on a block device while also using CONFIG_MTD=m,
>    and that may be slightly annoying
> 
> c) your patch restores a), but makes it work in the case where both
>    logfs and mtd are loadable modules, which is an improvement but
>    may still confuse users.
> 
> My preference is still version b) as I sent, but I don't really mind
> your version either.

I used the IS_REACHABLE macro because it hides the boolean expressions
nicely :). But I also do not insist on a particular solution. J?rn, what
would be your preference?

Thanks,
Michal

  reply	other threads:[~2015-11-27 14:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-27 13:54 [PATCH] logfs: clarify MTD dependency Arnd Bergmann
2015-11-27 13:54 ` Arnd Bergmann
2015-11-27 14:14 ` Michal Marek
2015-11-27 14:14   ` Michal Marek
2015-11-27 14:14   ` Michal Marek
2015-11-27 14:30   ` Arnd Bergmann
2015-11-27 14:30     ` Arnd Bergmann
2015-11-27 14:50     ` Michal Marek [this message]
2015-11-27 14:50       ` Michal Marek
  -- strict thread matches above, loose matches on Subject: below --
2016-01-13 13:25 Arnd Bergmann
2016-01-13 13:25 ` Arnd Bergmann
2016-01-13 20:39 ` Andrew Morton
2016-01-13 20:39   ` Andrew Morton
2016-01-13 20:45   ` Arnd Bergmann
2016-01-13 20:45     ` Arnd Bergmann
2016-01-13 21:31     ` Randy Dunlap
2016-01-13 21:31       ` Randy Dunlap

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=56586D9D.1000603@suse.com \
    --to=mmarek@suse.com \
    --cc=arnd@arndb.de \
    --cc=joern@logfs.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prasadjoshi.linux@gmail.com \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.