All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: James Bottomley <James.Bottomley@suse.de>,
	Stefan Richter <stefanr@s5r6.in-berlin.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Joel Becker <jlbec@evilplan.org>
Subject: Re: [PATCH] configfs: change depends -> select SYSFS
Date: Mon, 17 Jan 2011 16:13:24 -0800	[thread overview]
Message-ID: <4D34DB24.5040800@oracle.com> (raw)
In-Reply-To: <1295302216.22813.212.camel@haakon2.linux-iscsi.org>

On 01/17/11 14:10, Nicholas A. Bellinger wrote:
> On Mon, 2011-01-17 at 10:24 -0800, Randy Dunlap wrote:
>> On Sun, 16 Jan 2011 22:05:54 -0800 Nicholas A. Bellinger wrote:
>>
>>> On Sun, 2011-01-16 at 18:22 -0600, James Bottomley wrote:
> 
> <SNIP>
> 
>>>> This is what I don't understand.
>>>>
>>>> Actually I think the whole premise of the patch (to get back to the
>>>> original topic) is wrong.
>>>>
>>>> TARGET_CORE depends on SCSI; SCSI has to have sysfs to survive ... we
>>>> just don't work without it yet we neither select nor depend on it.
>>>> SYSFS is only deselectable for embedded anyway, so I think the
>>>> configuration which generated this whole argument was likely a bogus one
>>>> and consequently, none of the patches are needed (or if they are,
>>>> they're the tip of the iceberg).
>>>>
>>>
>>> This sounds fine for TARGET_CORE, but would still leave GFS2_FS with an
>>> unmet direct dependency according to the original warning above.
>>> Unfortuately I do not recall which exactly linux-next build
>>> configuration was causing this warning to occur from the original post:
>>>
>>> http://marc.info/?l=linux-next&m=129355383112997&w=2
>>>
>>> Any more thoughts here Randy..?
>>
>>
>> I've looked at GFS2 a bit now and I think that the warning is bogus:
>>
>> kconfig complains with:
>> warning: (TARGET_CORE && GFS2_FS) selects CONFIGFS_FS which has unmet direct dependencies (SYSFS)
>>
>> but the "select" is conditional:
>> config GFS2_FS
>> 	tristate "GFS2 file system support"
>> 	depends on (64BIT || LBDAF)
>> 	select DLM if GFS2_FS_LOCKING_DLM
>> 	select CONFIGFS_FS if GFS2_FS_LOCKING_DLM
>> 	select SYSFS if GFS2_FS_LOCKING_DLM
>>
>> and the same condition selects both SYSFS and CONFIGFS_FS.  Furthermore, the
>> conditional is not true, so neither of them is being selected/enabled.
>> Looks like a minor kconfig buglet to me.
>>
> 
> Ok, so Linus has pulled the CONFIGFS_FS -> select SYSFS series and it
> looks like this 'select SYSFS ...' bit for GFS2_FS can safely be dropped
> now..
> 
> Care to carry this one via your kbuild tree..?


Who are you asking?  (I don't have a kbuild tree.)

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

  reply	other threads:[~2011-01-18  0:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-15 21:10 [PATCH] configfs: change depends -> select SYSFS Nicholas A. Bellinger
2011-01-16 13:11 ` Stefan Richter
2011-01-16 21:53   ` Nicholas A. Bellinger
2011-01-16 23:06     ` Stefan Richter
2011-01-16 23:11       ` Linus Torvalds
2011-01-16 23:19         ` Al Viro
2011-01-16 23:45           ` Linus Torvalds
2011-01-17  0:05             ` Al Viro
2011-01-17  7:11               ` Rolf Eike Beer
2011-01-17  0:52             ` Stefan Richter
2011-01-17  1:07               ` Randy Dunlap
2011-01-17 11:16               ` Bernd Petrovitsch
2011-01-16 23:14       ` Nicholas A. Bellinger
2011-01-17  0:22       ` James Bottomley
2011-01-17  6:05         ` Nicholas A. Bellinger
2011-01-17 18:24           ` Randy Dunlap
2011-01-17 22:10             ` Nicholas A. Bellinger
2011-01-18  0:13               ` Randy Dunlap [this message]
2011-01-18  0:46                 ` Nicholas A. Bellinger
2011-01-17 18:11         ` Randy Dunlap
2011-01-16 17:54 ` Linus Torvalds
2011-01-16 21:44   ` Nicholas A. Bellinger
  -- strict thread matches above, loose matches on Subject: below --
2011-01-10 19:45 Nicholas A. Bellinger
2011-01-10 23:46 ` Joel Becker

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=4D34DB24.5040800@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=James.Bottomley@suse.de \
    --cc=jlbec@evilplan.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=nab@linux-iscsi.org \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=torvalds@linux-foundation.org \
    /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.