is anyone seriously using execute-in-place (in embedded systems)?

[Robert P. J. Day]

is anyone using XIP for their linux kernel? i know the argument
about saving space by running the kernel straight out of ROM, but that
also costs more in terms of ROM memory since the kernel has to be
stored uncompressed, no?

so, despite the advantages of XIP, is anyone actually using it on a
regular or production basis? thanks.

rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to eca...@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ

[Erik Mouw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, May 02, 2007 at 09:36:09AM -0400, Robert P. J. Day wrote:
> is anyone using XIP for their linux kernel? i know the argument
> about saving space by running the kernel straight out of ROM, but that
> also costs more in terms of ROM memory since the kernel has to be
> stored uncompressed, no?

Correct. Given the fact that flash memory is more expensive than RAM,
I've always failed to see why XIP would be an advantage.

> so, despite the advantages of XIP, is anyone actually using it on a
> regular or production basis? thanks.

So far I haven't actually heard a convincing advantage of XIP.

I guess some appliances use XIP, after all it was a large network
vendor that moved a large stack of green paper in the direction of an
embedded Linux vendor to get XIP supported. After moving all that green
paper it would be a shame not to use the result ;)

Erik

- --
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGORQs/PlVHJtIto0RAvSxAJwO62RVhxIjSr0e3OW3OAYhutTo5ACfWd+g
lwTaLlP6b4ujr7PbNSwCY4Q=
=7Df3
-----END PGP SIGNATURE-----

[k b]

Hi,
Can someone explain how the kernel figures out which interrupt handler
to call when the interrupt line is shared.

Any insight would be helpful.

thanks
KB

_________________________________________________________________
Watch free concerts with Pink, Rod Stewart, Oasis and more. Visit MSN In
Concert today. http://music.msn.com/presents?icid=ncmsnpresentstagline

[Mike Frysinger]

On 5/2/07, k b <k_b...@hotmail.com> wrote:
> Can someone explain how the kernel figures out which interrupt handler
> to call when the interrupt line is shared.

it doesnt ... it calls all registered interrupt handlers until one of
them returns IRQ_HANDLED

it's up to each individual interrupt handler to decide whether the
generated interrupt is for its device
-mike

[Greg KH]

On Wed, May 02, 2007 at 06:23:46PM -0700, k b wrote:
> Hi,
> Can someone explain how the kernel figures out which interrupt handler
> to call when the interrupt line is shared.

It calles them all, until one says it handled the interrupt.

thanks,

greg k-h

[k b]

Great thanks for the input.

which makes me think of the following scenario.

Lets say one interrupt say for this discussion interrupt number 5 is shared amongst 3
devices(d1, d2, d3) .(obviously the interrupt is level as its shared, otherwise we would miss interrupts)

T0 d3 fires an interrupt 5
T1 d1 also fires an interrupt.
T2 the kernel finds out(or gets ready to service the int) that int 5 was fired.
Kernel starts iterating its list of handles and call d1 int handler and it services the interrupt and returns interrupt handled (even though d1 wasn't the first guy who fired the int to start with).
but the int line is still high/low so it goes over the process again and calls d1's handler this time it sees it has nothing to service and the d2 and finally d3.

What i'm getting at is that if d3 is sharing an interrupt line with a device which generate a lot of interrupt it could be possible that d3 would have a high interrupt latency(in other word a have to wait
longer to get its int serviced).

Is that a right statement ?

thanks once again. Your inputs were really insightful.

KB

> Date: Wed, 2 May 2007 19:12:33 -0700
> From: gr...@kroah.com
> To: k_b...@hotmail.com
> CC: kernel...@nl.linux.org
> Subject: Re: Shared Interrupt handling.

---

Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it!

[Mike Frysinger]

On 5/2/07, k b <k_b...@hotmail.com> wrote:

> Lets say one interrupt say for this discussion interrupt number 5 is shared
> amongst 3
> devices(d1, d2, d3) .(obviously the interrupt is level as its shared,
> otherwise we would miss interrupts)
>
> T0 d3 fires an interrupt 5
> T1 d1 also fires an interrupt.
> T2 the kernel finds out(or gets ready to service the int) that int 5 was
> fired.
> Kernel starts iterating its list of handles and call d1 int handler and it
> services the interrupt and returns interrupt handled (even though d1 wasn't
> the first guy who fired the int to start with).
> but the int line is still high/low so it goes over the process again and
> calls d1's handler this time it sees it has nothing to service and the d2
> and finally d3.
>
> What i'm getting at is that if d3 is sharing an interrupt line with a device
> which generate a lot of interrupt it could be possible that d3 would have a
> high interrupt latency(in other word a have to wait
> longer to get its int serviced).
>
> Is that a right statement ?

yes, but that's really not the kernel's problem ... that's an issue
the system designer must keep in mind when architecting the hardware
... also, this is a good reason why interrupt handlers need to be as
small as possible and defer longer work to tasklets or workqueues
-mike

[Rajat Jain]

Hi Greg,

> > Can someone explain how the kernel figures out which interrupt handler
> > to call when the interrupt line is shared.
>
> It calles them all, until one says it handled the interrupt.
>

Doesn't the following code in handle_IRQ_event() suggest that ALL the
interrupt handlers are called, IRRESPECTIVE of the return value?

do {
ret = action->handler(irq, action->dev_id);
if (ret == IRQ_HANDLED)
status |= action->flags;
retval |= ret;
action = action->next;
} while (action);

Thanks,

Rajat

[Mike Frysinger]

On 5/3/07, Rajat Jain <rajat.no...@gmail.com> wrote:
> Doesn't the following code in handle_IRQ_event() suggest that ALL the
> interrupt handlers are called, IRRESPECTIVE of the return value?
>
> do {
> ret = action->handler(irq, action->dev_id);
> if (ret == IRQ_HANDLED)
> status |= action->flags;
> retval |= ret;
> action = action->next;
> } while (action);

it certainly seems that way huh ;)

makes sense too for the reasons "k b" highlighted
-mike