Hi folks,
I'm looking at software architecture questions, and wondering how much
application domain work I can move out of driver land and into user space,
hence the following question: Can anyone give me a rough idea of the maximum
latency in user space I could expect on an 860T based system with multiple
threads, where only one thread has SCHED_RR realtime scheduling priority?
Thanks,
Graham
PS: If you're in Sydney Australia and you're interested in an Embedded Linux
job doing 860/855T stuff, please let me know.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Graham Stoney wrote:
Hi folks,
I'm looking at software architecture questions, and wondering how much
application domain work I can move out of driver land and into user space,
I believe this is a good programming practice, and in many
cases I don't even write a driver when the application is
allowed to run with root privilege.
.... Can anyone give me a rough idea of the maximum
latency in user space I could expect on an 860T based system with multiple
threads, where only one thread has SCHED_RR realtime scheduling priority?
You can't answer this question due to the design and implementation
of the kernel. Most "real-time" systems can't either once you
throw protocol stacks, file systems, disk drives, and other
external devices or distributed services into the feature mix.
I have successfully written applications that required
sub-millisecond latency. You just have to be careful about
other applications in the system, and remember that you can't
preempt the kernel.
If you have hard real-time requirements, check into the RT-Linux
features. These are starting to mature, and can make scheduling
guarantees within the confined real-time domain.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Tue, 30 Nov 1999, Dan Malek wrote:
Graham Stoney wrote:
quoted
Hi folks,
I'm looking at software architecture questions, and wondering how much
application domain work I can move out of driver land and into user space,
I believe this is a good programming practice, and in many
cases I don't even write a driver when the application is
allowed to run with root privilege.
I have not looked yet into this section of my own project but I'll have to
eventually so I have a question: how about interrupt? I guess a very
simple driver which kicks some userland waiting thread is good enough in
most cases. Or is there a way to register some userland code?
Claude
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Claude Robitaille wrote:
.... so I have a question: how about interrupt? I guess a very
simple driver which kicks some userland waiting thread is good enough in
most cases. Or is there a way to register some userland code?
Interrupts are the reason to write the driver. The open()/close()
can perform some hardware initialization and shutdown to enable
and disable the interrupt source. The interrupt handler may
need to do something to remove the pending interrupt, and then
I usually use select() for the user thread synchronization.
The difficulty registering some user function as the interrupt
handler is it must run with interrupts disabled.....there are
a number of complexities associated with allowing this to
occur. The reason for interrupts disabled is that the handler
must do something to remove the interrupt state before you can
enable interrupts again.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/