[OE-core] minimal contents of a kernel config fragment

[Bruce Ashfield]

On Mon, Dec 19, 2016 at 6:31 AM, Robert P. J. Day <rpjday at crashcourse.ca>
wrote:

>
>   (ok, let's see if i can avoid embarrassing myself with an overly
> simple question ...)
>
>   reading YP kernel-dev manual, and there is an example of a kernel
> config fragment:
>
>   CONFIG_SERIAL_8250=y
>   CONFIG_SERIAL_8250_CONSOLE=y
>   CONFIG_SERIAL_8250_PCI=y
>   CONFIG_SERIAL_8250_NR_UARTS=4
>   CONFIG_SERIAL_8250_RUNTIME_UARTS=4
>   CONFIG_SERIAL_CORE=y
>   CONFIG_SERIAL_CORE_CONSOLE=y
>
> all well and good, but is it clear that one can cut that down based on
> the defaults in the Kconfig file? since the Kconfig file contains:
>
>   config SERIAL_8250_NR_UARTS
>         int "Maximum number of 8250/16550 serial ports"
>         depends on SERIAL_8250
>         default "4"
>         help
>           Set this to the number of serial ports you want the driver
>           to support.  This includes any ports discovered via ACPI or
>           PCI enumeration and any ports that may be added at run-time
>           via hot-plug, or any ISA multi-port serial cards.
>
>   config SERIAL_8250_RUNTIME_UARTS
>         int "Number of 8250/16550 serial ports to register at runtime"
>         depends on SERIAL_8250
>         range 0 SERIAL_8250_NR_UARTS
>         default "4"
>         help
>           Set this to the maximum number of serial ports you want
>           the kernel to register at boot time.  This can be overridden
>           with the module parameter "nr_uarts", or boot-time parameter
>           8250.nr_uarts
>
> is it accurate to say that the two fragment lines related to UARTs
> could be omitted? (yes, it's more informative to have them there, but
> technically, they're not required, correct?)
>


correct. In the end, it comes down to how much future proofing, readability
and segmentation you want in fragments. Some folks like to put everything
into a fragments .. others trust the kernel to not change a default and mess
with their functionality :)


>
>   similarly, another line could be omitted given the Kconfig lines:
>
>   config SERIAL_8250
>         tristate "8250/16550 and compatible serial support"
>         select SERIAL_CORE
>
> however, given the following in the same Kconfig file:
>
>   config SERIAL_8250_DEPRECATED_OPTIONS
>         bool "Support 8250_core.* kernel options (DEPRECATED)"
>         depends on SERIAL_8250
>         default y
>
> if you didn't want deprecated options, you *would* have to explicitly
> deselect that option with:
>
>   # CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
>
> yes?
>

Correct. As long as some other Kconfig doesn't "select <foo>", you can
turn the default off this way. There is another subtlety that if a Kconfig
option
doesn't have help text, you also can't change it from a default .. but
that's
not my fault, that's the fun of the kernel configuration subsystem :D

Bruce


>
>   just making sure i'm not overlooking any subtleties.
>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
>
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20161219/4b9c578f/attachment-0002.html>