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 *** -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
