linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] new feattures to improve linux interrupt response
@ 2003-08-07 10:25 Takeharu KATO
  2003-08-07 12:09 ` Alan Cox
  0 siblings, 1 reply; 2+ messages in thread
From: Takeharu KATO @ 2003-08-07 10:25 UTC (permalink / raw)
  To: linux-kernel; +Cc: linuxppc-dev

Dear developers:

We have a plan to implement new features of Linux kernel for
embedded systems.
In particular, these features are planed to improve interrupt 
response on Linux. 
Please tell us whether someone has been engaged in 
working about the same features yet.
Of course any comments are welcome.
We describe the feature as follows. 

[1] Problems to be solved

We focus on the following problems to use Linux on the embedded systems.

(1) Long critical sections
	Linux has longer critical sections than RTOS.
	So the invocation of interrupt handler may be delayed until executions of 
	critical section 
	is ended for long time.	The issue declines the response time to interrupts.

(2) The handling order of interrupts is not guaranteed.
	Current Linux kernel does not guarantee the handling order of interrupts
 	, so any kind of interruptions can interrupt on  handlers
	which is not set SA_INTERRUPT flags.
	
	By the way, typically, when we design the systems, we assign the interrupt
	priority on each devices by its importance.
	(e.g. Some systems need to handle network devices before disk devices,
	other systems need to handle disk devices have most important priority.).
	These priorities are decided by the system's character. In such cases,
	developers need the mechanism to guarantee interruption handling order for
	their systems.
	

[2] The proposed features

	We are engaged in implementing following facilities.
	These features can be enabled/disabled by kernel configuration.
	If users disable these features in kernel configuration,
	our modification will make no effect on kernel behaviors.

	a) Quick interruption handling facility for embedded systems
		We are designing and implementing quick interrupt handling facility 
		for embedded systems. This is achieved by accepting some 
		interrupts(these are pre-defined in kernel configuration.) in current 
		Linux kernel's critical sections. 
		
		We will modify local_irq_disable/local_irq_enable macros
		to keep interrupt masks of some interrupts which need to handle quickly
		un-masked in most of kernel critical sections.
		
	b) Priority based interrupt handler facility
		We adopt interrupt priorities for interrupt handlers(top half handlers)
		to handle interruption orderly(like Solaris).  
		In current plan, these priorities are set in kernel configuration,
		so this feature will make no effects on  current interrupt handler
		handlers API (request_irq/free_irq and so on.). 
		
		This is achieved by invoking interrupt handlers by kernel threads.
		These threads are created for each priority. Interrupt 
		priority is represented by thread's priority.


[3] About target platform
We will implement these features on PowerPC 405GP(r) platform at first.

Sincerely, yours


-- 
Takeharu KATO
Fujitsu Limited
Email:tkato@cs.fujitsu.co.jp

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [RFC] new feattures to improve linux interrupt response
  2003-08-07 10:25 [RFC] new feattures to improve linux interrupt response Takeharu KATO
@ 2003-08-07 12:09 ` Alan Cox
  0 siblings, 0 replies; 2+ messages in thread
From: Alan Cox @ 2003-08-07 12:09 UTC (permalink / raw)
  To: Takeharu KATO; +Cc: Linux Kernel Mailing List, linuxppc-dev

On Iau, 2003-08-07 at 11:25, Takeharu KATO wrote:
> 	a) Quick interruption handling facility for embedded systems
> 		We are designing and implementing quick interrupt handling facility 
> 		for embedded systems. This is achieved by accepting some 
> 		interrupts(these are pre-defined in kernel configuration.) in current 
> 		Linux kernel's critical sections. 
> 		
> 		We will modify local_irq_disable/local_irq_enable macros
> 		to keep interrupt masks of some interrupts which need to handle quickly
> 		un-masked in most of kernel critical sections.

Thats something you can do in board specific/platform specific code and
it does seem to work. I had hacks at one point doing this for the serial
port on the Macintosh II.



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-08-07 12:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-08-07 10:25 [RFC] new feattures to improve linux interrupt response Takeharu KATO
2003-08-07 12:09 ` Alan Cox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).