* [PATCH v4 3/6] dmaengine: Add slave DMA interface
From: Haavard Skinnemoen @ 2008-06-26 13:23 UTC (permalink / raw)
To: Dan Williams, Pierre Ossman
Cc: linux-kernel, linux-embedded, kernel, shannon.nelson,
David Brownell, Haavard Skinnemoen
In-Reply-To: <1214486603-23655-3-git-send-email-haavard.skinnemoen@atmel.com>
This patch adds the necessary interfaces to the DMA Engine framework
to use functionality found on most embedded DMA controllers: DMA from
and to I/O registers with hardware handshaking.
In this context, hardware hanshaking means that the peripheral that
owns the I/O registers in question is able to tell the DMA controller
when more data is available for reading, or when there is room for
more data to be written. This usually happens internally on the chip,
but these signals may also be exported outside the chip for things
like IDE DMA, etc.
A new struct dma_slave is introduced. This contains information that
the DMA engine driver needs to set up slave transfers to and from a
slave device. Most engines supporting DMA slave transfers will want to
extend this structure with controller-specific parameters. This
additional information is usually passed from the platform/board code
through the client driver.
A "slave" pointer is added to the dma_client struct. This must point
to a valid dma_slave structure iff the DMA_SLAVE capability is
requested. The DMA engine driver may use this information in its
device_alloc_chan_resources hook to configure the DMA controller for
slave transfers from and to the given slave device.
A new struct dma_slave_descriptor is added. This extends the standard
dma_async_tx_descriptor with a few members that are needed for doing
slave DMA from/to peripherals.
A new operation for creating such descriptors is added to struct
dma_device. Another new operation for terminating all pending
transfers is added as well. The latter is needed because there may be
errors outside the scope of the DMA Engine framework that may require
DMA operations to be terminated prematurely.
DMA Engine drivers may extend the dma_device, dma_chan and/or
dma_slave_descriptor structures to allow controller-specific
operations. The client driver can detect such extensions by looking at
the DMA Engine's struct device, or it can request a specific DMA
Engine device by setting the dma_dev field in struct dma_slave.
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
dmaslave interface changes since v3:
* Use dma_data_direction instead of a new enum
* Submit slave transfers as scatterlists
* Remove the DMA slave descriptor struct
dmaslave interface changes since v2:
* Add a dma_dev field to struct dma_slave. If set, the client can
only be bound to the DMA controller that corresponds to this
device. This allows controller-specific extensions of the
dma_slave structure; if the device matches, the controller may
safely assume its extensions are present.
* Move reg_width into struct dma_slave as there are currently no
users that need to be able to set the width on a per-transfer
basis.
dmaslave interface changes since v1:
* Drop the set_direction and set_width descriptor hooks. Pass the
direction and width to the prep function instead.
* Declare a dma_slave struct with fixed information about a slave,
i.e. register addresses, handshake interfaces and such.
* Add pointer to a dma_slave struct to dma_client. Can be NULL if
the DMA_SLAVE capability isn't requested.
* Drop the set_slave device hook since the alloc_chan_resources hook
now has enough information to set up the channel for slave
transfers.
---
drivers/dma/dmaengine.c | 16 ++++++++++++-
include/linux/dmaengine.h | 53 ++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index ad8d811..2e0035f 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -159,7 +159,12 @@ static void dma_client_chan_alloc(struct dma_client *client)
enum dma_state_client ack;
/* Find a channel */
- list_for_each_entry(device, &dma_device_list, global_node)
+ list_for_each_entry(device, &dma_device_list, global_node) {
+ /* Does the client require a specific DMA controller? */
+ if (client->slave && client->slave->dma_dev
+ && client->slave->dma_dev != device->dev)
+ continue;
+
list_for_each_entry(chan, &device->channels, device_node) {
if (!dma_chan_satisfies_mask(chan, client->cap_mask))
continue;
@@ -180,6 +185,7 @@ static void dma_client_chan_alloc(struct dma_client *client)
return;
}
}
+ }
}
enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie)
@@ -276,6 +282,10 @@ static void dma_clients_notify_removed(struct dma_chan *chan)
*/
void dma_async_client_register(struct dma_client *client)
{
+ /* validate client data */
+ BUG_ON(dma_has_cap(DMA_SLAVE, client->cap_mask) &&
+ !client->slave);
+
mutex_lock(&dma_list_mutex);
list_add_tail(&client->global_node, &dma_client_list);
mutex_unlock(&dma_list_mutex);
@@ -350,6 +360,10 @@ int dma_async_device_register(struct dma_device *device)
!device->device_prep_dma_memset);
BUG_ON(dma_has_cap(DMA_INTERRUPT, device->cap_mask) &&
!device->device_prep_dma_interrupt);
+ BUG_ON(dma_has_cap(DMA_SLAVE, device->cap_mask) &&
+ !device->device_prep_slave_sg);
+ BUG_ON(dma_has_cap(DMA_SLAVE, device->cap_mask) &&
+ !device->device_terminate_all);
BUG_ON(!device->device_alloc_chan_resources);
BUG_ON(!device->device_free_chan_resources);
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 4b602d3..8ce03e8 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -89,10 +89,23 @@ enum dma_transaction_type {
DMA_MEMSET,
DMA_MEMCPY_CRC32C,
DMA_INTERRUPT,
+ DMA_SLAVE,
};
/* last transaction type for creation of the capabilities mask */
-#define DMA_TX_TYPE_END (DMA_INTERRUPT + 1)
+#define DMA_TX_TYPE_END (DMA_SLAVE + 1)
+
+/**
+ * enum dma_slave_width - DMA slave register access width.
+ * @DMA_SLAVE_WIDTH_8BIT: Do 8-bit slave register accesses
+ * @DMA_SLAVE_WIDTH_16BIT: Do 16-bit slave register accesses
+ * @DMA_SLAVE_WIDTH_32BIT: Do 32-bit slave register accesses
+ */
+enum dma_slave_width {
+ DMA_SLAVE_WIDTH_8BIT,
+ DMA_SLAVE_WIDTH_16BIT,
+ DMA_SLAVE_WIDTH_32BIT,
+};
/**
* enum dma_ctrl_flags - DMA flags to augment operation preparation,
@@ -115,6 +128,33 @@ enum dma_ctrl_flags {
typedef struct { DECLARE_BITMAP(bits, DMA_TX_TYPE_END); } dma_cap_mask_t;
/**
+ * struct dma_slave - Information about a DMA slave
+ * @dev: device acting as DMA slave
+ * @dma_dev: required DMA master device. If non-NULL, the client can not be
+ * bound to other masters than this. The master driver may use
+ * this to determine whether it's safe to access
+ * @tx_reg: physical address of data register used for
+ * memory-to-peripheral transfers
+ * @rx_reg: physical address of data register used for
+ * peripheral-to-memory transfers
+ * @reg_width: peripheral register width
+ *
+ * If dma_dev is non-NULL, the client can not be bound to other DMA
+ * masters than the one corresponding to this device. The DMA master
+ * driver may use this to determine if there is controller-specific
+ * data wrapped around this struct. Drivers of platform code that sets
+ * the dma_dev field must therefore make sure to use an appropriate
+ * controller-specific dma slave structure wrapping this struct.
+ */
+struct dma_slave {
+ struct device *dev;
+ struct device *dma_dev;
+ dma_addr_t tx_reg;
+ dma_addr_t rx_reg;
+ enum dma_slave_width reg_width;
+};
+
+/**
* struct dma_chan_percpu - the per-CPU part of struct dma_chan
* @refcount: local_t used for open-coded "bigref" counting
* @memcpy_count: transaction counter
@@ -219,11 +259,14 @@ typedef enum dma_state_client (*dma_event_callback) (struct dma_client *client,
* @event_callback: func ptr to call when something happens
* @cap_mask: only return channels that satisfy the requested capabilities
* a value of zero corresponds to any capability
+ * @slave: data for preparing slave transfer. Must be non-NULL iff the
+ * DMA_SLAVE capability is requested.
* @global_node: list_head for global dma_client_list
*/
struct dma_client {
dma_event_callback event_callback;
dma_cap_mask_t cap_mask;
+ struct dma_slave *slave;
struct list_head global_node;
};
@@ -280,6 +323,8 @@ struct dma_async_tx_descriptor {
* @device_prep_dma_zero_sum: prepares a zero_sum operation
* @device_prep_dma_memset: prepares a memset operation
* @device_prep_dma_interrupt: prepares an end of chain interrupt operation
+ * @device_prep_slave_sg: prepares a slave dma operation
+ * @device_terminate_all: terminate all pending operations
* @device_issue_pending: push pending transactions to hardware
*/
struct dma_device {
@@ -315,6 +360,12 @@ struct dma_device {
struct dma_async_tx_descriptor *(*device_prep_dma_interrupt)(
struct dma_chan *chan, unsigned long flags);
+ struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
+ struct dma_chan *chan, struct scatterlist *sgl,
+ unsigned int sg_len, enum dma_data_direction direction,
+ unsigned long flags);
+ void (*device_terminate_all)(struct dma_chan *chan);
+
enum dma_status (*device_is_tx_complete)(struct dma_chan *chan,
dma_cookie_t cookie, dma_cookie_t *last,
dma_cookie_t *used);
--
1.5.5.4
^ permalink raw reply related
* [PATCH v4 2/6] dmaengine: Add dma_chan_is_in_use() function
From: Haavard Skinnemoen @ 2008-06-26 13:23 UTC (permalink / raw)
To: Dan Williams, Pierre Ossman
Cc: linux-kernel, linux-embedded, kernel, shannon.nelson,
David Brownell, Haavard Skinnemoen
In-Reply-To: <1214486603-23655-2-git-send-email-haavard.skinnemoen@atmel.com>
This moves the code checking if a DMA channel is in use from
show_in_use() into an inline helper function, dma_is_in_use(). DMA
controllers can use this in order to give clients exclusive access to
channels (usually necessary when setting up slave DMA.)
I have to admit that I don't really understand the channel refcounting
logic at all... dma_chan_get() simply increments a per-cpu value. How
can we be sure that whatever CPU calls dma_chan_is_in_use() sees the
same value?
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
---
drivers/dma/dmaengine.c | 12 +-----------
include/linux/dmaengine.h | 17 +++++++++++++++++
2 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index a57c337..ad8d811 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -105,17 +105,7 @@ static ssize_t show_bytes_transferred(struct device *dev, struct device_attribut
static ssize_t show_in_use(struct device *dev, struct device_attribute *attr, char *buf)
{
struct dma_chan *chan = to_dma_chan(dev);
- int in_use = 0;
-
- if (unlikely(chan->slow_ref) &&
- atomic_read(&chan->refcount.refcount) > 1)
- in_use = 1;
- else {
- if (local_read(&(per_cpu_ptr(chan->local,
- get_cpu())->refcount)) > 0)
- in_use = 1;
- put_cpu();
- }
+ int in_use = dma_chan_is_in_use(chan);
return sprintf(buf, "%d\n", in_use);
}
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index cffb95f..4b602d3 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -180,6 +180,23 @@ static inline void dma_chan_put(struct dma_chan *chan)
}
}
+static inline bool dma_chan_is_in_use(struct dma_chan *chan)
+{
+ bool in_use = false;
+
+ if (unlikely(chan->slow_ref) &&
+ atomic_read(&chan->refcount.refcount) > 1)
+ in_use = true;
+ else {
+ if (local_read(&(per_cpu_ptr(chan->local,
+ get_cpu())->refcount)) > 0)
+ in_use = true;
+ put_cpu();
+ }
+
+ return in_use;
+}
+
/*
* typedef dma_event_callback - function pointer to a DMA event callback
* For each channel added to the system this routine is called for each client.
--
1.5.5.4
^ permalink raw reply related
* [PATCH v4 1/6] dmaengine: Add dma_client parameter to device_alloc_chan_resources
From: Haavard Skinnemoen @ 2008-06-26 13:23 UTC (permalink / raw)
To: Dan Williams, Pierre Ossman
Cc: linux-kernel, linux-embedded, kernel, shannon.nelson,
David Brownell, Haavard Skinnemoen
In-Reply-To: <1214486603-23655-1-git-send-email-haavard.skinnemoen@atmel.com>
A DMA controller capable of doing slave transfers may need to know a
few things about the slave when preparing the channel. We don't want
to add this information to struct dma_channel since the channel hasn't
yet been bound to a client at this point.
Instead, pass a reference to the client requesting the channel to the
driver's device_alloc_chan_resources hook so that it can pick the
necessary information from the dma_client struct by itself.
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
---
drivers/dma/dmaengine.c | 3 ++-
drivers/dma/ioat_dma.c | 5 +++--
drivers/dma/iop-adma.c | 7 ++++---
include/linux/dmaengine.h | 3 ++-
4 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 99c22b4..a57c337 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -174,7 +174,8 @@ static void dma_client_chan_alloc(struct dma_client *client)
if (!dma_chan_satisfies_mask(chan, client->cap_mask))
continue;
- desc = chan->device->device_alloc_chan_resources(chan);
+ desc = chan->device->device_alloc_chan_resources(
+ chan, client);
if (desc >= 0) {
ack = client->event_callback(client,
chan,
diff --git a/drivers/dma/ioat_dma.c b/drivers/dma/ioat_dma.c
index 318e8a2..90e5b0a 100644
--- a/drivers/dma/ioat_dma.c
+++ b/drivers/dma/ioat_dma.c
@@ -452,7 +452,8 @@ static void ioat2_dma_massage_chan_desc(struct ioat_dma_chan *ioat_chan)
* ioat_dma_alloc_chan_resources - returns the number of allocated descriptors
* @chan: the channel to be filled out
*/
-static int ioat_dma_alloc_chan_resources(struct dma_chan *chan)
+static int ioat_dma_alloc_chan_resources(struct dma_chan *chan,
+ struct dma_client *client)
{
struct ioat_dma_chan *ioat_chan = to_ioat_chan(chan);
struct ioat_desc_sw *desc;
@@ -1049,7 +1050,7 @@ static int ioat_dma_self_test(struct ioatdma_device *device)
dma_chan = container_of(device->common.channels.next,
struct dma_chan,
device_node);
- if (device->common.device_alloc_chan_resources(dma_chan) < 1) {
+ if (device->common.device_alloc_chan_resources(dma_chan, NULL) < 1) {
dev_err(&device->pdev->dev,
"selftest cannot allocate chan resource\n");
err = -ENODEV;
diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
index 0ec0f43..2664ea5 100644
--- a/drivers/dma/iop-adma.c
+++ b/drivers/dma/iop-adma.c
@@ -444,7 +444,8 @@ static void iop_chan_start_null_memcpy(struct iop_adma_chan *iop_chan);
static void iop_chan_start_null_xor(struct iop_adma_chan *iop_chan);
/* returns the number of allocated descriptors */
-static int iop_adma_alloc_chan_resources(struct dma_chan *chan)
+static int iop_adma_alloc_chan_resources(struct dma_chan *chan,
+ struct dma_client *client)
{
char *hw_desc;
int idx;
@@ -838,7 +839,7 @@ static int __devinit iop_adma_memcpy_self_test(struct iop_adma_device *device)
dma_chan = container_of(device->common.channels.next,
struct dma_chan,
device_node);
- if (iop_adma_alloc_chan_resources(dma_chan) < 1) {
+ if (iop_adma_alloc_chan_resources(dma_chan, NULL) < 1) {
err = -ENODEV;
goto out;
}
@@ -936,7 +937,7 @@ iop_adma_xor_zero_sum_self_test(struct iop_adma_device *device)
dma_chan = container_of(device->common.channels.next,
struct dma_chan,
device_node);
- if (iop_adma_alloc_chan_resources(dma_chan) < 1) {
+ if (iop_adma_alloc_chan_resources(dma_chan, NULL) < 1) {
err = -ENODEV;
goto out;
}
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index d08a5c5..cffb95f 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -279,7 +279,8 @@ struct dma_device {
int dev_id;
struct device *dev;
- int (*device_alloc_chan_resources)(struct dma_chan *chan);
+ int (*device_alloc_chan_resources)(struct dma_chan *chan,
+ struct dma_client *client);
void (*device_free_chan_resources)(struct dma_chan *chan);
struct dma_async_tx_descriptor *(*device_prep_dma_memcpy)(
--
1.5.5.4
^ permalink raw reply related
* [PATCH v4 0/6] dmaengine/mmc: DMA slave interface and two new drivers
From: Haavard Skinnemoen @ 2008-06-26 13:23 UTC (permalink / raw)
To: Dan Williams, Pierre Ossman
Cc: linux-kernel, linux-embedded, kernel, shannon.nelson,
David Brownell, Haavard Skinnemoen
First of all, I'm sorry it went so much time between v3 and v4 of this
patchset. I was hoping to finish this stuff up before all kinds of
other tasks started demanding my attention, but I didn't, so I had to
put it on hold for a while. Let's try again...
This patchset extends the DMA engine API to allow drivers to offer DMA
to and from I/O registers with hardware handshaking, aka slave DMA.
Such functionality is very common in DMA controllers integrated on SoC
devices, and it's typically used to do DMA transfers to/from other
on-SoC peripherals, but it can often do DMA transfers to/from
externally connected devices as well (e.g. IDE hard drives).
The main differences from v3 of this patchset are:
* A DMA descriptor can hold a whole scatterlist. This means that
clients using slave DMA can submit large requests in a single call
to the driver, and they only need to keep track of a single
descriptor.
* The dma_slave_descriptor struct is gone since clients no longer
need to keep track of multiple descriptors.
* The drivers perform better and are more stable.
The dw_dmac driver depends on this patch:
http://lkml.org/lkml/2008/6/25/148
and the atmel-mci driver depends on this series:
http://lkml.org/lkml/2008/6/26/158
as well as all preceding patches in this series, of course.
Comments are welcome, as usual! Shortlog and diffstat follow.
Haavard Skinnemoen (6):
dmaengine: Add dma_client parameter to device_alloc_chan_resources
dmaengine: Add dma_chan_is_in_use() function
dmaengine: Add slave DMA interface
dmaengine: Make DMA Engine menu visible for AVR32 users
dmaengine: Driver for the Synopsys DesignWare DMA controller
Atmel MCI: Driver for Atmel on-chip MMC controllers
arch/avr32/boards/atngw100/setup.c | 7 +
arch/avr32/boards/atstk1000/atstk1002.c | 3 +
arch/avr32/mach-at32ap/at32ap700x.c | 73 ++-
drivers/dma/Kconfig | 11 +-
drivers/dma/Makefile | 1 +
drivers/dma/dmaengine.c | 31 +-
drivers/dma/dw_dmac.c | 1105 +++++++++++++++++++++
drivers/dma/dw_dmac_regs.h | 224 +++++
drivers/dma/ioat_dma.c | 5 +-
drivers/dma/iop-adma.c | 7 +-
drivers/mmc/host/Kconfig | 10 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/atmel-mci-regs.h | 194 ++++
drivers/mmc/host/atmel-mci.c | 1428 ++++++++++++++++++++++++++++
include/asm-avr32/arch-at32ap/at32ap700x.h | 16 +
include/asm-avr32/arch-at32ap/board.h | 6 +-
include/asm-avr32/atmel-mci.h | 12 +
include/linux/dmaengine.h | 73 ++-
include/linux/dw_dmac.h | 62 ++
19 files changed, 3229 insertions(+), 40 deletions(-)
create mode 100644 drivers/dma/dw_dmac.c
create mode 100644 drivers/dma/dw_dmac_regs.h
create mode 100644 drivers/mmc/host/atmel-mci-regs.h
create mode 100644 drivers/mmc/host/atmel-mci.c
create mode 100644 include/asm-avr32/atmel-mci.h
create mode 100644 include/linux/dw_dmac.h
Haavard
^ permalink raw reply
* Re: selecting initramfs support without initrd?
From: Leon Woestenberg @ 2008-06-26 9:40 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: linux-embedded
In-Reply-To: <alpine.LFD.1.10.0806241805390.5000@localhost.localdomain>
Hello Robert,
On Wed, Jun 25, 2008 at 12:11 AM, Robert P. J. Day
<rpjday@crashcourse.ca> wrote:
>
> perusing the early boot code, i noticed that selecting the config
> variable BLK_DEV_INITRD gives you support for both initramfs, and an
> initrd image.
>
Yes, I thought initrd to disappear when no block drivers where
selected. (because initramfs does not depend on the disk block i/o
stuff).
I may be confused and cannot check at this moment. At least I am sure
I saw the idea or a patch, maybe in the -tiny patches?
Regards,
--
Leon
^ permalink raw reply
* Atmel AT91SAM7S and AT91SAM7A3
From: Michelle Konzack @ 2008-06-25 17:16 UTC (permalink / raw)
To: Embedded
[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]
Hello,
I have several projects where I have the need for a microcontroller and
I considered to use 8051 compatibles but not it is not more possible
because I need an USBHID-PDU device interface, which can only solved
using Linux.
I like to use the AT91SAM7S and the AT91SAM7A3 (it has 16 AD-Converters)
and want to know, whether there is support for accessing the 8 and 16
AD-Converters directly via the Kernel.
Also I like to know, which memory size for the AT91 you recommend.
The current projects are:
1) Solar-Volatge regulator
(Uin <=68V, Uout=30V) with USB interface to PC or Master controller)
2) 24V PbGel charger
(Uin=30V and nearly the same hardware as above)
3) 24V DV modular ATX PSU
(special for solarsystems and must support minimal features of an
UPS to protect the computer)
Q: I have downloaded nearly all stuff about specifications to USBHID
and like to know, whether someone can point me to sample codes HOW
to code the device stuff... which seems currently not availlable in
the Kernel... (It seems, I am the first one WHO need this stuff,
but I am not a genie in C programming)
Note: "eCosCentric" sell USB stacks, but for an inacceptable price,
since I build only small quantities for my projects.
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Adrian Bunk @ 2008-06-25 15:41 UTC (permalink / raw)
To: James Chapman
Cc: Denys Vlasenko, Andi Kleen, David Woodhouse, Tim Bird, torvalds,
akpm, Paul Gortmaker, linux-embedded, linux-kernel
In-Reply-To: <486214F3.4070505@katalix.com>
On Wed, Jun 25, 2008 at 10:50:43AM +0100, James Chapman wrote:
> Adrian Bunk wrote:
>> On Mon, Jun 23, 2008 at 07:28:09PM +0200, Denys Vlasenko wrote:
>>> On Thursday 01 May 2008 12:41, Andi Kleen wrote:
>>>>> To a large extent, I agree. I certainly don't want to focus solely on
>>>>> code size; there's a lot more to embedded Linux than that. But it _is_
>>>> Not only code size, far more important is dynamic memory consumption.
>>>> [admittedly we right now lack a good instrumentation framework for this]
>>>>
>>>>> There are some cases where we really _do_ want to have CONFIG options,
>>>>> but I agree that we should keep them to a minimum. And when we _do_ have
>>>>> CONFIG options, they don't have to litter the actual code with ifdefs.
>>>> The problem I see is more that really nobody can even compile not
>>>> alone test all these combinations anymore. Hidding the problem in
>>>> inlines
>>>> does not solve that. And no randconfig is not the solution either.
>>> Because we allowed kernel to be developed without the requirement that
>>> random config should be buildable for release kernels.
>>>
>>> Had it been a requirement, keeping it in shape wouldn't be
>>> too difficult.
>>>
>>> Sure enough, _now_ fixing kernel to pass such a test on i386
>>> would take several weeks of work at least. But it is doable.
>>> ...
>>
>> On i386 it might even already work today.
>>
>> But guess how much time it costs to get at least all defconfigs
>> compiling on the other 22 architectures.
>>
>> Even getting allmodconfig/allyesconfig compiling isn't trivial for all
>> architectures, and random configurations are _far_ from compiling.
> >
> > And we are not talking about something to be done once, as soon as you
> > leave x86 there are tons of regular breakages.
>
> Could automated builds and build error reporting be used to help resolve
> these problems?
>
> The good people at Simtec have an automated build report available as an
> e-mail digest. I use it to watch for architecture build breakages in
> subsystems or drivers that I use or touch. It covers defconfigs of ARM
> and MIPS architectures and reports compile errors/warnings, module size,
> kernel size etc. If this approach were extended/distributed to cover
> more architectures
Jan Dittmer has a great page showing the build status and kernel size of
the defconfigs of all architectures that is running since 2004 or 2005:
http://l4x.org/k/
> and random config builds, developers could with
> little effort spot problems and fix them. Hell, it might also encourage
> new developers to get involved and contribute.
Perhaps in an ideal world...
In reality, I'd claim I'm one out of only two people who regularly fix
architecture-specific build problems for all architectures.
> James Chapman
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: James Chapman @ 2008-06-25 9:50 UTC (permalink / raw)
To: Adrian Bunk
Cc: Denys Vlasenko, Andi Kleen, David Woodhouse, Tim Bird, torvalds,
akpm, Paul Gortmaker, linux-embedded, linux-kernel
In-Reply-To: <20080623174537.GB4756@cs181140183.pp.htv.fi>
Adrian Bunk wrote:
> On Mon, Jun 23, 2008 at 07:28:09PM +0200, Denys Vlasenko wrote:
>> On Thursday 01 May 2008 12:41, Andi Kleen wrote:
>>>> To a large extent, I agree. I certainly don't want to focus solely on
>>>> code size; there's a lot more to embedded Linux than that. But it _is_
>>> Not only code size, far more important is dynamic memory consumption.
>>> [admittedly we right now lack a good instrumentation framework for this]
>>>
>>>> There are some cases where we really _do_ want to have CONFIG options,
>>>> but I agree that we should keep them to a minimum. And when we _do_ have
>>>> CONFIG options, they don't have to litter the actual code with ifdefs.
>>> The problem I see is more that really nobody can even compile not
>>> alone test all these combinations anymore. Hidding the problem in inlines
>>> does not solve that. And no randconfig is not the solution either.
>> Because we allowed kernel to be developed without the requirement that
>> random config should be buildable for release kernels.
>>
>> Had it been a requirement, keeping it in shape wouldn't be
>> too difficult.
>>
>> Sure enough, _now_ fixing kernel to pass such a test on i386
>> would take several weeks of work at least. But it is doable.
>> ...
>
> On i386 it might even already work today.
>
> But guess how much time it costs to get at least all defconfigs
> compiling on the other 22 architectures.
>
> Even getting allmodconfig/allyesconfig compiling isn't trivial for all
> architectures, and random configurations are _far_ from compiling.
>
> And we are not talking about something to be done once, as soon as you
> leave x86 there are tons of regular breakages.
Could automated builds and build error reporting be used to help resolve
these problems?
The good people at Simtec have an automated build report available as an
e-mail digest. I use it to watch for architecture build breakages in
subsystems or drivers that I use or touch. It covers defconfigs of ARM
and MIPS architectures and reports compile errors/warnings, module size,
kernel size etc. If this approach were extended/distributed to cover
more architectures and random config builds, developers could with
little effort spot problems and fix them. Hell, it might also encourage
new developers to get involved and contribute.
Here's a link to a recent report for ARM, fyi:-
http://lists.simtec.co.uk/pipermail/kautobuild/2008-June/001299.html
> Plus the fact that you often get into situations where more options
> mean complex and fragile stuff. Read the Kconfig files under
> drivers/media/ and check in git all commits to them since 2.6.25 alone,
> and you'll understand why "add an option for every bit" can result in
> very high ongoing maintainance work required.
>
> Not everything that is technically possible is also maintainable, and
> maintainability is a very important point in a project with several
> million lines changing each year.
>
>> vda
>
> cu
> Adrian
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: Firmware Linux (was Re: Cross Compiler and loads of issues)
From: Rob Landley @ 2008-06-25 1:49 UTC (permalink / raw)
To: weigelt; +Cc: linux-embedded
In-Reply-To: <20080616043812.GB32139@nibiru.local>
On Sunday 15 June 2008 23:38:12 Enrico Weigelt wrote:
> * Rob Landley <rob@landley.net> schrieb:
> > Did you try my FWL project? :)
> >
> > http://landley.net/code/firmware
>
> hmm, doesnt look like supporting sysroot ...
It doesn't use sysroot. It makes the compiler relocatable using an updated
version of the old uClibc wrapper script, which rewrites each glibc command
line to start with --nostinc --nostdlib and then adds the correct paths back
in from the ground up.
Have you ever run gcc under strace? Or worse, looked at the gcc path logic
source code? It's a mess. It gets paths from ./configure options, it gets
paths from spec files, it adds hardwired paths in the C source code, it
checks enviroment variables to get more paths, and this isn't counting the
paths you tell it on the command line. Every time they gave up on the
previous approach because it was obviously unworkable, they NEVER REMOVED
ANYTHING. They just added yet another layer on top of it, falling back to
the previous one each time. It never occurred to them that people would want
to make it NOT check paths like /usr/include. They just keep piling on more
and more, appending to a big vararray and never removing anything.
Do you know how sysroot is implemented? It still hardwires absolute paths
into the binary, but then it does a string compare with the start of the
hardwired path so it knows how much to trim off when substituting another
path instead.
I once tried to work up a patch to remove the obsolete or clearly defective
parts of the gcc path logic, but when my patch got large than 10,000 lines I
gave up and went to a wrapper script. The only way to make the gcc path
logic reliable is to NOT USE IT. Hence the wrapper script to tell it to
ignore all the paths it _thinks_ it knows, and check in exactly these places
(and only those places) instead. Then you can run the result under strace
without wanting to throw up quite so much.
> cu
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* selecting initramfs support without initrd?
From: Robert P. J. Day @ 2008-06-24 22:11 UTC (permalink / raw)
To: linux-embedded
i'm not sure if this is the proper forum for this, but while
perusing the early boot code, i noticed that selecting the config
variable BLK_DEV_INITRD gives you support for both initramfs, and an
initrd image.
however, with embedded systems, isn't it more common to use
initramfs and not need initrd at all (depending on the functionality
of the bootloader)? and if that's true, might there not be some
benefit in splitting those two features (initramfs versus initrd) so
you could select initramfs all by itself, and not compile in any
initrd support whatsoever?
based on a quick inspection of the source under init/, it would seem
that you could whack out sizable chunks of code if you had no need for
initrd, but i could be wrong.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
^ permalink raw reply
* [PATCH] add diffconfig utility (v2)
From: Tim Bird @ 2008-06-24 17:56 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-embedded, linux kernel, linux-kbuild
In-Reply-To: <20080612131931.GB13702@uranus.ravnborg.org>
Sam Ravnborg wrote:
> When you consider it stabilized could you please drop me a
> new mail including full changelog and updated patch.
>
> And please cc: linux-kbuild@vger.kernel.org + linux-kernel on the
> submission.
Sam,
I haven't gotten any more feedback, and I believe I've addressed
all previous feedback.
As for the ChangeLog, here's some information about history and
recent changes. I can put this in the patch/script if desired.
CHANGELOG:
2008-06-24 - Tim Bird <tim.bird@am.sony.com> - add usage function,
add -m feature for merge-style output, use .config and .config.old
by default, improve command line handling
~2007 - Tim Bird - re-format code for internal use at Sony
~2006 - Matt Mackall - create original diffconfig tool as part of
bloatwatch project
Diffconfig is a simple utility for comparing two kernel configuration files.
See usage in the script for more info.
Signed-off-by: Tim Bird <tim.bird@am.sony.com>
scripts/diffconfig | 129 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 129 insertions(+)
create mode 100755 scripts/diffconfig
diff --git a/scripts/diffconfig b/scripts/diffconfig
new file mode 100755
index 0000000..aa6cfe1
--- /dev/null
+++ b/scripts/diffconfig
@@ -0,0 +1,129 @@
+#!/usr/bin/python
+#
+# diffconfig - a tool to compare .config files.
+#
+# originally written in 2006 by Matt Mackall
+# (at least, this was in his bloatwatch source code)
+# last worked on 2008 by Tim Bird
+#
+
+import sys, os
+
+def usage():
+ print """Usage: diffconfig [-h] [-m] [<config1> <config2>]
+
+Diffconfig is a simple utility for comparing two .config files.
+Using standard diff to compare .config files often includes extraneous and
+distracting information. This utility produces sorted output with only the
+changes in configuration values between the two files.
+
+Added and removed items are shown with a leading plus or minus, respectively.
+Changed items show the old and new values on a single line.
+
+If -m is specified, then output will be in "merge" style, which has the
+changed and new values in kernel config option format.
+
+If no config files are specified, .config and .config.old are used.
+
+Example usage:
+ $ diffconfig .config config-with-some-changes
+-EXT2_FS_XATTR n
+-EXT2_FS_XIP n
+ CRAMFS n -> y
+ EXT2_FS y -> n
+ LOG_BUF_SHIFT 14 -> 16
+ PRINTK_TIME n -> y
+"""
+ sys.exit(0)
+
+# returns a dictionary of name/value pairs for config items in the file
+def readconfig(config_file):
+ d = {}
+ for line in config_file:
+ line = line[:-1]
+ if line[:7] == "CONFIG_":
+ name, val = line[7:].split("=", 1)
+ d[name] = val
+ if line[-11:] == " is not set":
+ d[line[9:-11]] = "n"
+ return d
+
+def print_config(op, config, value, new_value):
+ global merge_style
+
+ if merge_style:
+ if new_value:
+ if new_value=="n":
+ print "# CONFIG_%s is not set" % config
+ else:
+ print "CONFIG_%s=%s" % (config, new_value)
+ else:
+ if op=="-":
+ print "-%s %s" % (config, value)
+ elif op=="+":
+ print "+%s %s" % (config, new_value)
+ else:
+ print " %s %s -> %s" % (config, value, new_value)
+
+def main():
+ global merge_style
+
+ # parse command line args
+ if ("-h" in sys.argv or "--help" in sys.argv):
+ usage()
+
+ merge_style = 0
+ if "-m" in sys.argv:
+ merge_style = 1
+ sys.argv.remove("-m")
+
+ argc = len(sys.argv)
+ if not (argc==1 or argc == 3):
+ print "Error: incorrect number of arguments or unrecognized option"
+ usage()
+
+ if argc == 1:
+ # if no filenames given, assume .config and .config.old
+ build_dir=""
+ if os.environ.has_key("KBUILD_OUTPUT"):
+ build_dir = os.environ["KBUILD_OUTPUT"]+"/"
+
+ configa_filename = build_dir + ".config.old"
+ configb_filename = build_dir + ".config"
+ else:
+ configa_filename = sys.argv[1]
+ configb_filename = sys.argv[2]
+
+ a = readconfig(file(configa_filename))
+ b = readconfig(file(configb_filename))
+
+ # print items in a but not b (accumulate, sort and print)
+ old = []
+ for config in a:
+ if config not in b:
+ old.append(config)
+ old.sort()
+ for config in old:
+ print_config("-", config, a[config], None)
+ del a[config]
+
+ # print items that changed (accumulate, sort, and print)
+ changed = []
+ for config in a:
+ if a[config] != b[config]:
+ changed.append(config)
+ else:
+ del b[config]
+ changed.sort()
+ for config in changed:
+ print_config("->", config, a[config], b[config])
+ del b[config]
+
+ # now print items in b but not in a
+ # (items from b that were in a were removed above)
+ new = b.keys()
+ new.sort()
+ for config in new:
+ print_config("+", config, None, b[config])
+
+main()
^ permalink raw reply related
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Sam Ravnborg @ 2008-06-23 19:33 UTC (permalink / raw)
To: Denys Vlasenko
Cc: David Woodhouse, Andi Kleen, torvalds, akpm, Paul Gortmaker,
linux-embedded, linux-kernel, Tim Bird
In-Reply-To: <200806232112.30393.vda.linux@googlemail.com>
On Mon, Jun 23, 2008 at 09:12:30PM +0200, Denys Vlasenko wrote:
> On Monday 23 June 2008 20:57, Sam Ravnborg wrote:
> > > > I agree. And if we do want to pay attention to pure code size, there are
> > > > other approaches -- like --gc-sections
> > >
> > > I have some patches in this area too. Were submitted to Sam
> > > but he was too busy it seems.
> >
> > They were not trivial to apply and so went down on the TODO list.
>
> I realize that they were not trivial to review, but that
> was unavoidable. They were even more not trivial to create.
>
> > We could try to push the generic and x86 specific .lds stuff via
> > the arch maintainers?
>
> IIRC I splitted the entire GC collection patch in a way
> that first patches were doing exactly this easier first part
> and I hoped that at least these first patches
> will be taken. They were big, but somewhat trivial,
> from "it's obviously safe" department.
I do not recall anything wrong with the patch-set.
>
> Had they been applied, now making --gc-sections to work
> would be easier.
Agreed. I should have asked you to push this via arch maintainers back then.
Sam
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Denys Vlasenko @ 2008-06-23 19:12 UTC (permalink / raw)
To: Sam Ravnborg
Cc: David Woodhouse, Andi Kleen, torvalds, akpm, Paul Gortmaker,
linux-embedded, linux-kernel, Tim Bird
In-Reply-To: <20080623185728.GB30550@uranus.ravnborg.org>
On Monday 23 June 2008 20:57, Sam Ravnborg wrote:
> > > I agree. And if we do want to pay attention to pure code size, there are
> > > other approaches -- like --gc-sections
> >
> > I have some patches in this area too. Were submitted to Sam
> > but he was too busy it seems.
>
> They were not trivial to apply and so went down on the TODO list.
I realize that they were not trivial to review, but that
was unavoidable. They were even more not trivial to create.
> We could try to push the generic and x86 specific .lds stuff via
> the arch maintainers?
IIRC I splitted the entire GC collection patch in a way
that first patches were doing exactly this easier first part
and I hoped that at least these first patches
will be taken. They were big, but somewhat trivial,
from "it's obviously safe" department.
Had they been applied, now making --gc-sections to work
would be easier.
--
vda
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Tim Bird @ 2008-06-23 19:05 UTC (permalink / raw)
To: Adrian Bunk
Cc: Denys Vlasenko, Andi Kleen, David Woodhouse, torvalds, akpm,
Paul Gortmaker, linux-embedded, linux-kernel
In-Reply-To: <20080623174537.GB4756@cs181140183.pp.htv.fi>
Adrian Bunk wrote:
> On Mon, Jun 23, 2008 at 07:28:09PM +0200, Denys Vlasenko wrote:
>> Had it been a requirement, keeping it in shape wouldn't be
>> too difficult.
>>
>> Sure enough, _now_ fixing kernel to pass such a test on i386
>> would take several weeks of work at least. But it is doable.
>> ...
>
> On i386 it might even already work today.
>
> But guess how much time it costs to get at least all defconfigs
> compiling on the other 22 architectures.
>
> Even getting allmodconfig/allyesconfig compiling isn't trivial for all
> architectures, and random configurations are _far_ from compiling.
>
> And we are not talking about something to be done once, as soon as you
> leave x86 there are tons of regular breakages.
>
> Plus the fact that you often get into situations where more options
> mean complex and fragile stuff. Read the Kconfig files under
> drivers/media/ and check in git all commits to them since 2.6.25 alone,
> and you'll understand why "add an option for every bit" can result in
> very high ongoing maintainance work required.
>
> Not everything that is technically possible is also maintainable, and
> maintainability is a very important point in a project with several
> million lines changing each year.
OK sure. Nobody's going to disagree with that. I would, however,
disagree with a characterization of Linux-tiny as "adding an option
for every bit". Linux-tiny has been around about 5 years now, and
if you added the whole thing right now you'd add about 30 config
options.
If you're worried about this multiplying out of control, let me
just say that having to curtail the rate of patch submission by
embedded developers has not been our biggest problem. :-)
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Sam Ravnborg @ 2008-06-23 18:57 UTC (permalink / raw)
To: Denys Vlasenko
Cc: David Woodhouse, Andi Kleen, torvalds, akpm, Paul Gortmaker,
linux-embedded, linux-kernel, Tim Bird
In-Reply-To: <200806231922.10864.vda.linux@googlemail.com>
On Mon, Jun 23, 2008 at 07:22:10PM +0200, Denys Vlasenko wrote:
> On Wednesday 30 April 2008 21:11, David Woodhouse wrote:
> > On Wed, 2008-04-30 at 20:22 +0200, Andi Kleen wrote:
> > > David Woodhouse <dwmw2@infradead.org> writes:
> > >
> > > > Andrew Morton has been saying recently that we need an 'embedded
> > > > maintainer', to take responsibility for 'embedded issues' in the core
> > > > kernel, as well as trying to improve our relationship with those using
> > > > the Linux kernel for 'embedded' devices -- who have a reputation of
> > > > not working with us very closely; to their detriment as well as our
> > > > own.
> > >
> > > I hope your job description doesn't include adding more and more
> > > CONFIGs though.
> > >
> > > I am sure there are lots of low hanging fruit where memory can be
> > > saved and it's a good thing someone cares about that, but please don't
> > > focus on the code size only. Or if you work on that don't do it
> > > using CONFIG or when you really add a new one find some other
> > > that is pointless and remove it first.
> > >
> > > There are simply already far too many of them and they make the
> > > kernel harder and harder to change.
> >
> > I agree. And if we do want to pay attention to pure code size, there are
> > other approaches -- like --gc-sections
>
> I have some patches in this area too. Were submitted to Sam
> but he was too busy it seems.
They were not trivial to apply and so went down on the TODO list.
We could try to push the generic and x86 specific .lds stuff via
the arch maintainers?
Sam
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Denys Vlasenko @ 2008-06-23 18:19 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andi Kleen, David Woodhouse, Tim Bird, torvalds, akpm,
Paul Gortmaker, linux-embedded, linux-kernel
In-Reply-To: <20080623174537.GB4756@cs181140183.pp.htv.fi>
On Monday 23 June 2008 19:45, Adrian Bunk wrote:
> Plus the fact that you often get into situations where more options
> mean complex and fragile stuff. Read the Kconfig files under
> drivers/media/ and check in git all commits to them since 2.6.25 alone,
> and you'll understand why "add an option for every bit" can result in
> very high ongoing maintainance work required.
>
> Not everything that is technically possible is also maintainable, and
> maintainability is a very important point in a project with several
> million lines changing each year.
Well, I am not (and was not) disputing this. I agree with it.
CONFIGs should not be multiplying like rabbits.
--
vda
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Adrian Bunk @ 2008-06-23 17:45 UTC (permalink / raw)
To: Denys Vlasenko
Cc: Andi Kleen, David Woodhouse, Tim Bird, torvalds, akpm,
Paul Gortmaker, linux-embedded, linux-kernel
In-Reply-To: <200806231928.09458.vda.linux@googlemail.com>
On Mon, Jun 23, 2008 at 07:28:09PM +0200, Denys Vlasenko wrote:
> On Thursday 01 May 2008 12:41, Andi Kleen wrote:
> > > To a large extent, I agree. I certainly don't want to focus solely on
> > > code size; there's a lot more to embedded Linux than that. But it _is_
> >
> > Not only code size, far more important is dynamic memory consumption.
> > [admittedly we right now lack a good instrumentation framework for this]
> >
> > > There are some cases where we really _do_ want to have CONFIG options,
> > > but I agree that we should keep them to a minimum. And when we _do_ have
> > > CONFIG options, they don't have to litter the actual code with ifdefs.
> >
> > The problem I see is more that really nobody can even compile not
> > alone test all these combinations anymore. Hidding the problem in inlines
> > does not solve that. And no randconfig is not the solution either.
>
> Because we allowed kernel to be developed without the requirement that
> random config should be buildable for release kernels.
>
> Had it been a requirement, keeping it in shape wouldn't be
> too difficult.
>
> Sure enough, _now_ fixing kernel to pass such a test on i386
> would take several weeks of work at least. But it is doable.
>...
On i386 it might even already work today.
But guess how much time it costs to get at least all defconfigs
compiling on the other 22 architectures.
Even getting allmodconfig/allyesconfig compiling isn't trivial for all
architectures, and random configurations are _far_ from compiling.
And we are not talking about something to be done once, as soon as you
leave x86 there are tons of regular breakages.
Plus the fact that you often get into situations where more options
mean complex and fragile stuff. Read the Kconfig files under
drivers/media/ and check in git all commits to them since 2.6.25 alone,
and you'll understand why "add an option for every bit" can result in
very high ongoing maintainance work required.
Not everything that is technically possible is also maintainable, and
maintainability is a very important point in a project with several
million lines changing each year.
> vda
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Recommendation for activating a deferred module init in the kernel
From: Tim Bird @ 2008-06-23 17:40 UTC (permalink / raw)
To: Gilad Ben-Yossef; +Cc: linux-embedded
In-Reply-To: <485DFA81.6010600@codefidence.com>
Gilad Ben-Yossef wrote:
> Tim Bird wrote:
>> I agree. When you say "have the application call modprobe directly",
>> I'm not sure I understand what you mean.
>
> I simply meant that you can fork and exec modprobe itself (or use
> system() but that
> would require a working shell). This would "save" the need for a
> separate script and a shell.
Well, this would explain why I didn't follow your original
point. I thought you were using the word "modprobe" as a placeholder
for some other module-installation-related concept. In all
my years of working with embedded Linux, I have never used
modprobe in a target device. (And I avoid insmod whenever I can).
Sorry for my confusion.
> The only downside I see of calling the sys_init_module syscall directly
> is that it
> doesn't do any of the dependency tracking that modprobe does, so it's more
> a insmod replacement then a modprobe one, but I doubt this matters at
> all in an
> embedded system anyway.
It may just be my own blind spot, but I can't think of a good
reason to do such dependency tracking in an embedded device.
It is a sad state of affairs if the product developers don't
know the module dependencies for their own products.
>
> Do people here think a shared library implementing modprobe would be
> useful?
Speaking from my own experience, not for embedded.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Denys Vlasenko @ 2008-06-23 17:28 UTC (permalink / raw)
To: Andi Kleen
Cc: David Woodhouse, Tim Bird, torvalds, akpm, Paul Gortmaker,
linux-embedded, linux-kernel
In-Reply-To: <20080501104158.GM20451@one.firstfloor.org>
On Thursday 01 May 2008 12:41, Andi Kleen wrote:
> > To a large extent, I agree. I certainly don't want to focus solely on
> > code size; there's a lot more to embedded Linux than that. But it _is_
>
> Not only code size, far more important is dynamic memory consumption.
> [admittedly we right now lack a good instrumentation framework for this]
>
> > There are some cases where we really _do_ want to have CONFIG options,
> > but I agree that we should keep them to a minimum. And when we _do_ have
> > CONFIG options, they don't have to litter the actual code with ifdefs.
>
> The problem I see is more that really nobody can even compile not
> alone test all these combinations anymore. Hidding the problem in inlines
> does not solve that. And no randconfig is not the solution either.
Because we allowed kernel to be developed without the requirement that
random config should be buildable for release kernels.
Had it been a requirement, keeping it in shape wouldn't be
too difficult.
Sure enough, _now_ fixing kernel to pass such a test on i386
would take several weeks of work at least. But it is doable.
I would even volunteer to do it if there are some
reasonable chances resulting patches would be viewed
as worthwhile for inclusion. I am somewhat tired
of killing weeks of my time only to find that my work
is deemed "not important enough for inclusion".
--
vda
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Denys Vlasenko @ 2008-06-23 17:22 UTC (permalink / raw)
To: David Woodhouse
Cc: Andi Kleen, torvalds, akpm, Paul Gortmaker, linux-embedded,
linux-kernel, Tim Bird
In-Reply-To: <1209582709.25560.441.camel@pmac.infradead.org>
On Wednesday 30 April 2008 21:11, David Woodhouse wrote:
> On Wed, 2008-04-30 at 20:22 +0200, Andi Kleen wrote:
> > David Woodhouse <dwmw2@infradead.org> writes:
> >
> > > Andrew Morton has been saying recently that we need an 'embedded
> > > maintainer', to take responsibility for 'embedded issues' in the core
> > > kernel, as well as trying to improve our relationship with those using
> > > the Linux kernel for 'embedded' devices -- who have a reputation of
> > > not working with us very closely; to their detriment as well as our
> > > own.
> >
> > I hope your job description doesn't include adding more and more
> > CONFIGs though.
> >
> > I am sure there are lots of low hanging fruit where memory can be
> > saved and it's a good thing someone cares about that, but please don't
> > focus on the code size only. Or if you work on that don't do it
> > using CONFIG or when you really add a new one find some other
> > that is pointless and remove it first.
> >
> > There are simply already far too many of them and they make the
> > kernel harder and harder to change.
>
> I agree. And if we do want to pay attention to pure code size, there are
> other approaches -- like --gc-sections
I have some patches in this area too. Were submitted to Sam
but he was too busy it seems.
--
vda
^ permalink raw reply
* Re: Recommendation for activating a deferred module init in the kernel
From: Gilad Ben-Yossef @ 2008-06-22 7:08 UTC (permalink / raw)
To: Tim Bird; +Cc: linux-embedded
In-Reply-To: <485A9E61.6060707@am.sony.com>
Tim Bird wrote:
> Gilad Ben-Yossef wrote:
>
>> Well, seeing as both modprobe and a minimal shell are part of busybox
>> which is included in over 90%+ of Linux based embedded systems and that
>> the script is trivial, not to mention that you can just have the
>> application call modprobe directly, just as it will be calling ioctl()
>> in your case, thereby negating the need for both script and shell at
>> all, I do believe that complexity wise my solution still has some merit.
>>
>
> I agree. When you say "have the application call modprobe directly",
> I'm not sure I understand what you mean. Are you talking about a call
> to the kernel (a syscall) or a library function? The kernel has the
> syscall sys_init_module(), which I'm considering using. Is there some
> mobprobe library call that might make sense to use?
>
>
I simply meant that you can fork and exec modprobe itself (or use
system() but that
would require a working shell). This would "save" the need for a
separate script and a shell.
I guess "invoking" would have been more suitable word then "calling".
The only downside I see of calling the sys_init_module syscall directly
is that it
doesn't do any of the dependency tracking that modprobe does, so it's more
a insmod replacement then a modprobe one, but I doubt this matters at
all in an
embedded system anyway.
Do people here think a shared library implementing modprobe would be
useful?
I ran into such a need a couple of times myself and does not look
difficult to do, but does
anyone else here thinks it will be useful?
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
Codefidence Ltd.
The code is free, your time isn't.(TM)
Web: http://codefidence.com
Email: gilad@codefidence.com
Office: +972-8-9316883 ext. 201
Fax: +972-8-9316885
Mobile: +972-52-8260388
Q: How many NSA agents does it take to replace a lightbulb?
A: dSva7DrYiY24yeTItKyyogFXD5gRuoRqPNQ9v6WCLLywZPINlu!
^ permalink raw reply
* Re: Kernel boot problem on IXP422 Rev. A
From: Greg Ungerer @ 2008-06-20 0:08 UTC (permalink / raw)
To: Marcus Tangermann; +Cc: linux-embedded
In-Reply-To: <485A9E6F.6070006@web.de>
Hi Marcus,
Marcus Tangermann wrote:
>> Kernel dying, not just no console?
> To be honest I don't know ;-) Maybe it's only an issue with the console.
> It should be ttyS0 as this works with 2.6.19-uc1. The snapgear kernel
> works when I use the settings for the MonteJade board.
> Today I took a look at the sources of the snapgear kernel where the
> CONFIG_MARCH_MONTEJADE is used, and there are some modifications within
> the 8250 serial driver for this board. I will take a closer look at it
> tomorrow.
Over the years there have been some changes to the serial
setup on those boards. Some setups leave out the first
serial port definition, and so what is otherwise considered
ttyS1 will be ttyS0. Something to look out for anyway.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: Kernel boot problem on IXP422 Rev. A
From: Marcus Tangermann @ 2008-06-19 17:59 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <48537071.6060902@snapgear.com>
Hello Greg,
> Kernel dying, not just no console?
To be honest I don't know ;-) Maybe it's only an issue with the console.
It should be ttyS0 as this works with 2.6.19-uc1. The snapgear kernel
works when I use the settings for the MonteJade board.
Today I took a look at the sources of the snapgear kernel where the
CONFIG_MARCH_MONTEJADE is used, and there are some modifications within
the 8250 serial driver for this board. I will take a closer look at it
tomorrow.
Best regards
Marcus
^ permalink raw reply
* Re: Recommendation for activating a deferred module init in the kernel
From: Tim Bird @ 2008-06-19 17:58 UTC (permalink / raw)
To: Gilad Ben-Yossef; +Cc: linux-embedded
In-Reply-To: <4859ECF3.3000500@codefidence.com>
Gilad Ben-Yossef wrote:
> Well, seeing as both modprobe and a minimal shell are part of busybox
> which is included in over 90%+ of Linux based embedded systems and that
> the script is trivial, not to mention that you can just have the
> application call modprobe directly, just as it will be calling ioctl()
> in your case, thereby negating the need for both script and shell at
> all, I do believe that complexity wise my solution still has some merit.
I agree. When you say "have the application call modprobe directly",
I'm not sure I understand what you mean. Are you talking about a call
to the kernel (a syscall) or a library function? The kernel has the
syscall sys_init_module(), which I'm considering using. Is there some
mobprobe library call that might make sense to use?
Thanks for the feedback.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Video playback on osk with linux-2.6.18
From: mohammed shareef @ 2008-06-18 19:24 UTC (permalink / raw)
To: linux-embedded
Dear All,
I have an OSK-Omap5912 with linux-2.6.18 running on it. i want to add
video playback support to it. Has someone done this before? could you
suggest some ways to do it? thank you.
regards,
Mohammed
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox