aboutsummaryrefslogtreecommitdiffstats
path: root/lib/lufa/Projects/LEDNotifier/Config
diff options
context:
space:
mode:
authorErez Zukerman <bulk@ezuk.org>2016-10-31 21:41:19 -0400
committerGitHub <noreply@github.com>2016-10-31 21:41:19 -0400
commit7a9be2562d8386c4cdec7fa130d2608931d85590 (patch)
tree5695fbf018e4dcf2601913122e92517682b9c2f8 /lib/lufa/Projects/LEDNotifier/Config
parenta6401076d51a6858940131b97858ac71ce668893 (diff)
parentf284bc6af9995453fc7be2e94ae134bc42b90204 (diff)
downloadfirmware-7a9be2562d8386c4cdec7fa130d2608931d85590.tar.gz
firmware-7a9be2562d8386c4cdec7fa130d2608931d85590.tar.bz2
firmware-7a9be2562d8386c4cdec7fa130d2608931d85590.zip
Merge pull request #851 from J3RN/momentary
Switched to momentary
Diffstat (limited to 'lib/lufa/Projects/LEDNotifier/Config')
0 files changed, 0 insertions, 0 deletions
125'>125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257
#
# This Kconfig describe xen options
#

mainmenu "Xen Configuration"

config XEN
	bool
	default y if X86_XEN || X86_64_XEN
	help
	  This is the Linux Xen port.

if XEN
config XEN_INTERFACE_VERSION
	hex
	default 0x00030202

menu "XEN"

config XEN_PRIVILEGED_GUEST
	bool "Privileged Guest (domain 0)"
	depends XEN
	default n
	help
	  Support for privileged operation (domain 0)

config XEN_UNPRIVILEGED_GUEST
	bool
	default !XEN_PRIVILEGED_GUEST

config XEN_BACKEND
        tristate "Backend driver support"
        default y
        help
          Support for backend device drivers that provide I/O services
          to other virtual machines.

config XEN_PCIDEV_BACKEND
	tristate "PCI device backend driver"
	depends on PCI && XEN_BACKEND
	default XEN_PRIVILEGED_GUEST
	help
	  The PCI device backend driver allows the kernel to export arbitrary
	  PCI devices to other guests. If you select this to be a module, you
	  will need to make sure no other driver has bound to the device(s)
	  you want to make visible to other guests.

choice
	prompt "PCI Backend Mode"
	depends on XEN_PCIDEV_BACKEND
	default XEN_PCIDEV_BACKEND_VPCI

config XEN_PCIDEV_BACKEND_VPCI
	bool "Virtual PCI"
	---help---
	  This PCI Backend hides the true PCI topology and makes the frontend
	  think there is a single PCI bus with only the exported devices on it.
	  For example, a device at 03:05.0 will be re-assigned to 00:00.0. A
	  second device at 02:1a.0 will be re-assigned to 00:01.0.

config XEN_PCIDEV_BACKEND_PASS
	bool "Passthrough"
	---help---
	  This PCI Backend provides a real view of the PCI topology to the
	  frontend (for example, a device at 06:01.b will still appear at
	  06:01.b to the frontend). This is similar to how Xen 2.0.x exposed
	  PCI devices to its driver domains. This may be required for drivers
	  which depend on finding their hardward in certain bus/slot
	  locations.

endchoice

config XEN_PCIDEV_BE_DEBUG
	bool "PCI Backend Debugging"
	depends on XEN_PCIDEV_BACKEND
	default n

config XEN_BLKDEV_BACKEND
	tristate "Block-device backend driver"
        depends on XEN_BACKEND
	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
        tristate "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
	tristate "Network-device backend driver"
        depends on XEN_BACKEND && NET
	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_NETDEV_LOOPBACK
	tristate "Network-device loopback driver"
	depends on XEN_NETDEV_BACKEND
	default y
	help
	  A two-interface loopback device to emulate a local netfront-netback
	  connection.

config XEN_TPMDEV_BACKEND
	tristate "TPM-device backend driver"
        depends on XEN_BACKEND
	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"
	depends on XEN
	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"
	depends on XEN && NET
	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
	tristate "Block device tap driver"
        depends on XEN_BACKEND
	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_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.

config XEN_DISABLE_SERIAL
	bool "Disable serial port drivers"
	default y
	help
	  Disable serial port drivers, allowing the Xen console driver
	  to provide a serial console at ttyS0.

config XEN_SYSFS
	tristate "Export Xen attributes in sysfs"
	depends on SYSFS
	default y