On Mon, Dec 19, 2016 at 6:31 AM, Robert P. J. Day <[email protected]> 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 > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
