linux-kernel - RE: [patch] Introduce CONFIG_HAS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0C7297FA1D2D244A9C7F6959C0BF1E5201EC6BE2@azsmsx413.amr.corp.intel.com>
Date:	Wed, 30 May 2007 14:40:02 -0700
From:	"Williams, Dan J" <dan.j.williams@...el.com>
To:	"Cornelia Huck" <cornelia.huck@...ibm.com>
Cc:	"Heiko Carstens" <heiko.carstens@...ibm.com>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"John W. Linville" <linville@...driver.com>,
	"Kyle McMartin" <kyle@...isc-linux.org>,
	<linux-kernel@...r.kernel.org>, <James.Bottomley@...eleye.com>,
	"Tejun Heo" <htejun@...il.com>, "Jeff Garzik" <jeff@...zik.org>,
	"Martin Schwidefsky" <schwidefsky@...ibm.com>,
	<geert@...ux-m68k.org>, <zippel@...ux-m68k.org>, <spyro@....com>,
	<uclinux-v850@....nec.co.jp>, <ysato@...rs.sourceforge.jp>
Subject: RE: [patch] Introduce CONFIG_HAS_DMA.

[ please let me know if you want to be dropped from the cc ]

> From: Cornelia Huck [mailto:cornelia.huck@...ibm.com]
> IMO, well-placed #ifdefs are preferrable to dragging non-working code
> around. Like:
> 
> - put the DMA path in a file only build for MY_STUFF_USE_DMA
> - let MY_STUFF select MY_STUFF_USE_DMA if HAS_DMA
> - have a header file that points to the implementation for
>   MY_STUFF_USE_DMA and uses well defined stubs for !MY_STUFF_USE_DMA,
>   like returning ICannotDoThat for check_if_can_do() (kind of like
what
>   include/linux/sysfs.h does, for example)
> 
> This contains the #ifdefs in a header, doesn't compile stuff that
won't
> work anyway on !HAS_DMA, and adds the ability to disable
> MY_STUFF_USE_DMA even if HAS_DMA at a later time if someone wants it.
> 
> > In other words let CONFIG_HAS_DMA prevent pure DMA code from being
> > built, but do not preclude "clever" implementations from calling
> > broken code.
> 
> If it calls broken code, it may not be so "clever" after all :)
> 
Yes, at run time, but not necessarily at compile time.  

> What I don't like about this is
> 
> - compiles stuff that is not needed on !HAS_DMA
> - worse, compiles stuff that will not work on !HAS_DMA
> - does not encourage to split code properly into a DMA and a non-DMA
>   part

I came to the same conclusions as I started to implement the bug-stubs.
The patch (to follow) attempts to satisfy all the concerns you outline
as well as my observation that async_tx requires no factoring for the
!HAS_DMA case.

With the patch non-dma-architectures that try to build code with true
dependencies on the DMA api will fail to link i.e.:

CONFIG_DMA_ENGINE=y CONFIG_HAS_DMA=n ASYNC_MEMCPY=y
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
async_tx/built-in.o: In function `async_memcpy':
xor.c:(.text+0x770): undefined reference to `dma_map_page'
xor.c:(.text+0x798): undefined reference to `dma_map_page'
xor.c:(.text+0x968): undefined reference to `dma_map_page'

Now changing CONFIG_DMA_ENGINE to depend on HAS_DMA (which is more
correct than saying !S390). Results in:
CONFIG_DMA_ENGINE=n CONFIG_HAS_DMA=n ASYNC_MEMCPY=y
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
  KSYM    .tmp_kallsyms1.S
  AS      .tmp_kallsyms1.o
  LD      .tmp_vmlinux2
  KSYM    .tmp_kallsyms2.S
  AS      .tmp_kallsyms2.o
  LD      vmlinux

This also allows include/asm-s390/dma-mapping.h to be dropped.

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