LAUTERWASSER Stefan wrote:
I want to rebuild linux-3.16.3-200.fc20.x86_64 with options:
CONFIG_GENERIC_CMOS_UPDATE=n
CONFIG_X86_TSC=n
i'm unsure how i got this mail (which list it came from)
also i'm unsure if you checked all other options to see if none of
those require x86.
# zless menuconfig-text.gz # lk 2.6+
i see CMOS is generic may requires "x86" and is for updating clock chip
here's my guesses...
depends on X86_64 || (X86_32 && X86_PAE && !X86_VISWS)
depends on X86_CMPXCHG && X86_TSC
help
seeing the above makes me believe the Xen product is only available
as an x86 binary, ie SPARC zen doesn't exist or it'd say
(X86_TSC||SPARC_TSC) - and on arm you couldn't run Xen if you didn't
have Zen compiled for ARM - and something tells me hypervisor isn't
prepared for dealthing with anyting but x86. if you have x86 newer
than 586, you have a TSC and say yes. i can't remember but i think
sparc has fully multithread but doesn't use TSC flag verbatim as x86
does.
first figure out (read the source?) if it actually updates cmos
given your build. usually kernel modules check a device is good
before doing anything. if it does you can insert an exit(0) in the
code before it writes.
if you feel the dependancy is incorrect, that zen does not call for
cmos update and your not running 386, you may be able to edit the
Makefile (and which other file?) to remove the "depends" so it no
longer in the list of "required to build". i think they do depends
by hand, but i'm unsure how the lk people have that sorted out. my
guess is the dependancy is correct
But it seams that "make olddefconfig" enables these options again because of dependencies.
I found the "select GENERIC_CMOS_UPDATE" entries in arch/*/Kconfig files - if I remove them, I am able to build a kernel with CONFIG_GENERIC_CMOS_UPDATE=n.
It's selected by default but does not seam to be necessary isn't it?
I am not able to disable CONFIG_X86_TSC.
It seams that Xen (arch/x86/xen/Kconfig) depends on X86_TSC - so I disabled all the XEN stuff.
May arch/x86/Kconfig.cpu (config X86_TSC - def_bool y) is the reason that CONFIG_X86_TSC is enabled again?
I thought it's just on of multiple clock sources isn't it?
It's my first email to a kernel mailing list so please be clement - feetback welcome. :-)
Mit freundlichen Grüßen/Best regards
Stefan Lauterwasser
Software Engineer
Transportation Systems
Thales Deutschland
Email: Stefan.Lauterwasser@xxxxxxxxxxxxxxx
Web: www.thalesgroup.com
--------------------------------------------------------------
Thales Transportation Systems GmbH
Thalesplatz 1 - 71254 Ditzingen - Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-config" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-config" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
