avr/qmk/firmware - [no description]

diff options

author	fishsoupisgood <github@madingley.org>	2020-10-02 11:10:08 +0100
committer	fishsoupisgood <github@madingley.org>	2020-10-02 11:10:08 +0100
commit	ee079a41f1450ef567e15699275596ebe058236a (patch)
tree	225f59e41a436fc3b22cbfe04e214a6e371e82f2 /keyboards/handwired/promethium/keymaps/default
parent	9cd522d3814baf2fd12839c5e5ff2a98b4d823b4 (diff)
download	firmware-master.tar.gz firmware-master.tar.bz2 firmware-master.zip

async handing of colourHEAD master

Diffstat (limited to 'keyboards/handwired/promethium/keymaps/default')

0 files changed, 0 insertions, 0 deletions

# # For a description of the syntax of this configuration file, # see Documentation/kbuild/kconfig-language.txt. # mainmenu "Linux Kernel Configuration" config XEN bool default y help This is the Linux Xen port. config ARCH_XEN bool default y config NO_IDLE_HZ bool default y menu "XEN" config XEN_PRIVILEGED_GUEST bool "Privileged Guest (domain 0)" default n select XEN_PHYSDEV_ACCESS help Support for privileged operation (domain 0) config XEN_PHYSDEV_ACCESS bool "Physical device access" default XEN_PRIVILEGED_GUEST help Assume access is available to physical hardware devices (e.g., hard drives, network cards). This allows you to configure such devices and also includes some low-level support that is otherwise not compiled into the kernel. config XEN_BLKDEV_BACKEND bool "Block-device backend driver" depends on XEN_PHYSDEV_ACCESS default y help The block-device backend driver allows the kernel to export its block devices to other guests via a high-performance shared-memory interface. config XEN_BLKDEV_TAP_BE bool "Block Tap support for backend driver (DANGEROUS)" depends on XEN_BLKDEV_BACKEND default n help If you intend to use the block tap driver, the backend domain will not know the domain id of the real frontend, and so will not be able to map its data pages. This modifies the backend to attempt to map from both the tap domain and the real frontend. This presents a security risk, and so should ONLY be used for development with the blktap. This option will be removed as the block drivers are modified to use grant tables. config XEN_NETDEV_BACKEND bool "Network-device backend driver" depends on XEN_PHYSDEV_ACCESS default y help The network-device backend driver allows the kernel to export its network devices to other guests via a high-performance shared-memory interface. config XEN_NETDEV_PIPELINED_TRANSMITTER bool "Pipelined transmitter (DANGEROUS)" depends on XEN_NETDEV_BACKEND default n help If the net backend is a dumb domain, such as a transparent Ethernet bridge with no local IP interface, it is safe to say Y here to get slightly lower network overhead. If the backend has a local IP interface; or may be doing smart things like reassembling packets to perform firewall filtering; or if you are unsure; or if you experience network hangs when this option is enabled; then you must say N here. config XEN_TPMDEV_FRONTEND bool "TPM-device frontend driver" default n select TCG_TPM select TCG_XEN help The TPM-device frontend driver. config XEN_TPMDEV_BACKEND bool "TPM-device backend driver" default n help The TPM-device backend driver config XEN_TPMDEV_CLOSE_IF_VTPM_FAILS bool "TPM backend closes upon vTPM failure" depends on XEN_TPMDEV_BACKEND default n help The TPM backend closes the channel if the vTPM in userspace indicates a failure. The corresponding domain's channel will be closed. Say Y if you want this feature. config XEN_BLKDEV_FRONTEND tristate "Block-device frontend driver" default y help The block-device frontend driver allows the kernel to access block devices mounted within another guest OS. Unless you are building a dedicated device-driver domain, or your master control domain (domain 0), then you almost certainly want to say Y here. config XEN_NETDEV_FRONTEND tristate "Network-device frontend driver" default y help The network-device frontend driver allows the kernel to access network interfaces within another guest OS. Unless you are building a dedicated device-driver domain, or your master control domain (domain 0), then you almost certainly want to say Y here. config XEN_BLKDEV_TAP bool "Block device tap driver" default n help This driver allows a VM to interact on block device channels to other VMs. Block messages may be passed through or redirected to a character device, allowing device prototyping in application space. Odds are that you want to say N here. config XEN_SHADOW_MODE bool "Fake shadow mode" default n help fakes out a shadow mode kernel config XEN_SCRUB_PAGES bool "Scrub memory before freeing it to Xen" default y help Erase memory contents before freeing it back to Xen's global pool. This ensures that any secrets contained within that memory (e.g., private keys) cannot be found by other guests that may be running on the machine. Most people will want to say Y here. If security is not a concern then you may increase performance by saying N. choice prompt "Processor Type" default XEN_X86 config XEN_X86 bool "X86" help Choose this option if your computer is a X86 architecture. config XEN_X86_64 bool "X86_64" help Choose this option if your computer is a X86_64 architecture. endchoice endmenu config HAVE_ARCH_ALLOC_SKB bool default y config HAVE_ARCH_DEV_ALLOC_SKB bool default y source "init/Kconfig" if XEN_X86 source "arch/xen/i386/Kconfig" endif if XEN_X86_64 source "arch/xen/x86_64/Kconfig" endif menu "Executable file formats" source "fs/Kconfig.binfmt" endmenu source "arch/xen/Kconfig.drivers" if XEN_PRIVILEGED_GUEST menu "Power management options" source "drivers/acpi/Kconfig" endmenu endif source "fs/Kconfig" source "security/Kconfig" source "crypto/Kconfig" source "lib/Kconfig" source "arch/xen/Kconfig.debug"


context:
space:
mode: