linux-kernel - Re: linux-next: Tree for Oct 8 (media/usb/gspca)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1412853970.21441.32.camel@x220>
Date:	Thu, 09 Oct 2014 13:26:10 +0200
From:	Paul Bolle <pebolle@...cali.nl>
To:	Mauro Carvalho Chehab <mchehab@....samsung.com>
Cc:	Randy Dunlap <rdunlap@...radead.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Hans de Goede <hdegoede@...hat.com>,
	linux-media <linux-media@...r.kernel.org>
Subject: Re: linux-next: Tree for Oct 8 (media/usb/gspca)

On Thu, 2014-10-09 at 07:30 -0300, Mauro Carvalho Chehab wrote:
> Em Thu, 09 Oct 2014 08:45:28 +0200
> Paul Bolle <pebolle@...cali.nl> escreveu:
> > The above discussion meanders a bit, and I just stumbled onto it, but
> > would
> >     #if IS_BUILTIN(CONFIG_INPUT) || (IS_MODULE(CONFIG_INPUT) && defined(MODULE))
> > 
> > cover your requirements when using macros?
> 
> No. What we need to do, for all gspca sub-drivers that have optional
> support for buttons is to only enable the buttons support if:
> 
> 	CONFIG_INPUT=y
> or
> 	CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=m
> 
> If we use a reverse logic, we need to disable the code if:
> 	# CONFIG_INPUT is not set
> or
> 	CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=y
> 
> The rationale for disabling the code on the last expression is that a
> builtin code cannot call a function inside a module.
> 
> Also, as the submodule is already being compiled, we know that
> CONFIG_USB_GSPCA_submodule is either module or builtin.
> 
> So, either one of those expressions should work:
> 	#if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && !IS_BUILTIN(CONFIG_USB_GSPCA_submodule))
> or
> 	#if (IS_BUILTIN(CONFIG_INPUT)) || (IS_MODULE(CONFIG_INPUT) && IS_MODULE(CONFIG_USB_GSPCA_submodule) && defined(MODULE))

I thought MODULE was only defined for code that will be part of a
module. So "IS_MODULE(CONFIG_USB_GSPCA_submodule)" and "defined(MODULE)"
should be equal when used _inside_ [...]/usb/gspca/that_submodule.c,
shouldn't they? That would make this option basically identical to my
suggestion. Or are you thinking about using these tests outside of these
submodules themselves?

> or
> 	#if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && IS_MODULE(CONFIG_USB_GSPCA_submodule))

I think it's clearer to use
    IS_BUILTIN(CONFIG_FOO) || (IS_MODULE(CONFIG_FOO) && [...])

Ditto above. Perhaps just a matter of taste.

(Depending on INPUT is apparently not possible for these submodules. So
obviously any solution needs to check whether input is available, say
like
    if (IS_MODULE(CONFIG_INPUT))
        if (!is_input_loaded())
            goto no_input;

Doesn't it?)

Thanks,


Paul Bolle

--
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/