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>] [day] [month] [year] [list]
Message-Id: <200701220957.36554.david-b@pacbell.net>
Date:	Mon, 22 Jan 2007 09:57:36 -0800
From:	David Brownell <david-b@...bell.net>
To:	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: [patch 2.6.20-rc5] rm pointless dmaengine exports

This removes several pointless exports from drivers/dma/dmaengine.c;
the dma_async_memcpy_*() functions are inlined by <linux/dmaengine.h>
so those exports are inappropriate.

It also moves the existing EXPORT_SYMBOL declarations next to their
functions, so it's now trivial to confirm one-to-one correspondence
between exports and nonstatic symbols.

Signed-off-by: David Brownell <dbrownell@...rs.sourceforge.net>

---
By the way ... I'm sure that I'm not the only one to observe how odd it
is that a "DMA Engine" framework is purely a memcpy() offload engine.

It overlooks the primary use of DMA in Linux:  peripheral I/O, which
may well involve the same kind of dual-access engines this framework
assumes.  DMA controllers on embedded Linuxes commonly support a few
dozen logical DMA channels supporting hardware-synchronized transfers
to/from most peripheral devices.  Memory-to-memory DMA would often
also work ... but wouldn't address IRQ rate issues of PIO drivers.

 drivers/dma/dmaengine.c |   18 ++++++------------
 1 files changed, 6 insertions(+), 12 deletions(-)

Index: g26/drivers/dma/dmaengine.c
===================================================================
--- g26.orig/drivers/dma/dmaengine.c	2007-01-22 09:19:27.000000000 -0800
+++ g26/drivers/dma/dmaengine.c	2007-01-22 09:19:29.000000000 -0800
@@ -176,6 +176,7 @@ void dma_chan_cleanup(struct kref *kref)
 	chan->client = NULL;
 	kref_put(&chan->device->refcount, dma_async_device_cleanup);
 }
+EXPORT_SYMBOL(dma_chan_cleanup);
 
 static void dma_chan_free_rcu(struct rcu_head *rcu)
 {
@@ -261,6 +262,7 @@ struct dma_client *dma_async_client_regi
 
 	return client;
 }
+EXPORT_SYMBOL(dma_async_client_register);
 
 /**
  * dma_async_client_unregister - unregister a client and free the &dma_client
@@ -287,6 +289,7 @@ void dma_async_client_unregister(struct 
 	kfree(client);
 	dma_chans_rebalance();
 }
+EXPORT_SYMBOL(dma_async_client_unregister);
 
 /**
  * dma_async_client_chan_request - request DMA channels
@@ -304,6 +307,7 @@ void dma_async_client_chan_request(struc
 	client->chans_desired = number;
 	dma_chans_rebalance();
 }
+EXPORT_SYMBOL(dma_async_client_chan_request);
 
 /**
  * dma_async_device_register - registers DMA devices found
@@ -346,6 +350,7 @@ int dma_async_device_register(struct dma
 
 	return 0;
 }
+EXPORT_SYMBOL(dma_async_device_register);
 
 /**
  * dma_async_device_cleanup - function called when all references are released
@@ -390,23 +395,12 @@ void dma_async_device_unregister(struct 
 	kref_put(&device->refcount, dma_async_device_cleanup);
 	wait_for_completion(&device->done);
 }
+EXPORT_SYMBOL(dma_async_device_unregister);
 
 static int __init dma_bus_init(void)
 {
 	mutex_init(&dma_list_mutex);
 	return class_register(&dma_devclass);
 }
-
 subsys_initcall(dma_bus_init);
 
-EXPORT_SYMBOL(dma_async_client_register);
-EXPORT_SYMBOL(dma_async_client_unregister);
-EXPORT_SYMBOL(dma_async_client_chan_request);
-EXPORT_SYMBOL(dma_async_memcpy_buf_to_buf);
-EXPORT_SYMBOL(dma_async_memcpy_buf_to_pg);
-EXPORT_SYMBOL(dma_async_memcpy_pg_to_pg);
-EXPORT_SYMBOL(dma_async_memcpy_complete);
-EXPORT_SYMBOL(dma_async_memcpy_issue_pending);
-EXPORT_SYMBOL(dma_async_device_register);
-EXPORT_SYMBOL(dma_async_device_unregister);
-EXPORT_SYMBOL(dma_chan_cleanup);
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ