RE: [PATCH] Remove bogus default y for DMAR and NET_DMA

[Nelson, Shannon]

>From: Jeff Garzik [mailto:jeff@xxxxxxxxxx] 
>
>Andi Kleen wrote:
>> Index: linux-2.6.24-rc1-hack/arch/x86_64/Kconfig
>> ===================================================================
>> --- linux-2.6.24-rc1-hack.orig/arch/x86_64/Kconfig
>> +++ linux-2.6.24-rc1-hack/arch/x86_64/Kconfig
>> @@ -753,7 +753,6 @@ config PCI_DOMAINS
>>  config DMAR
>>  	bool "Support for DMA Remapping Devices (EXPERIMENTAL)"
>>  	depends on PCI_MSI && ACPI && EXPERIMENTAL
>> -	default y
>>  	help
>>  	  DMA remapping (DMAR) devices support enables 
>independent address
>>  	  translations for Direct Memory Access (DMA) from devices.
>
>ACK
>
>
>> Index: linux-2.6.24-rc1-hack/drivers/dma/Kconfig
>> ===================================================================
>> --- linux-2.6.24-rc1-hack.orig/drivers/dma/Kconfig
>> +++ linux-2.6.24-rc1-hack/drivers/dma/Kconfig
>> @@ -43,7 +43,6 @@ comment "DMA Clients"
>>  config NET_DMA
>>  	bool "Network: TCP receive copy offload"
>>  	depends on DMA_ENGINE && NET
>> -	default y
>>  	help
>>  	  This enables the use of DMA engines in the network stack to
>>  	  offload receive copy-to-user operations, freeing CPU cycles.
>
>ACK -- but its arguable that given the current code, its worth setting 
>this if DMA_ENGINE is also set.
>

The intent is to give us a DMA offload for NIC-to-user operations.  At
the moment the ioatdma device is the only gizmo supporting this through
NET_DMA, and is the only DMA_ENGINE supported on x86.  As more devices
are made available through DMA_ENGINE on platforms that don't have
ioatdma, removing the "default y" makes sense.  I agree that this is
ACK-able, but under the "it should just work" philosophy, and with the
Intel servers coming out with the hardware support, it may want to wait
until there are more DMA_ENGINE choices.

In any case, I'll ACK this and let the maintainers decide on the timing.

sln
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/