Re: a joint letter on low latency and Linux

[David Schleef]

On Thu, Jun 29, 2000 at 06:38:53PM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 30 Jun 2000, Russell, Richard (DEH) wrote:
> 
> > > Well, I personally would rather see that nobody ever needed RTlinux at
> > > all. I think hard realtime is a waste of time, myself, and 
> > 
> > The need for hard real-time comes when you have real-world requirements that
> > require absolute timing garantees with 100% reliability.
> 
> If you hadn't snipped the rest of the email, you'd have seen that I agree:
> _if_ there are truly hard guarantee requirements, RTLinux is the way to
> go.
> 
> The number of problems that really need RT-linux is practically zero for
> normal uses. This is, btw, why I've never applied the RTLinux patches to
> the standard kernel tree. My personal opinion is that the RTLinux patches
> should _not_ be available by default, so that only people who really need
> the functionality start using it. 

How about these?

  - Winmodems
  - crappy UARTs running at high speeds
  - High-accuracy stratum-1 NTP servers
  - Almost any data acquisition application with a board that
    costs less than USD 1000.

The uses for hard real time are growing very rapidly, especially
as people realize that Linux+RTAI or Linux+RTLinux is a viable
alternative to LynxOS, VxWorks, pSOS, or homebrewed kernels.

These are just applications that _currently_ would find benefit
from mainstream hard-real-time.  But if included, people would
find new and interesting ways to use it.

Think of the amount of time that has been spent to implement
SMP support in the kernel.  Several years ago, it could have
been argued that SMP support was not necessary.  Even today,
the number of problems that really _need_ SMP are practically
zero.[1]  But the inclusion of SMP support opened an entire new
space to Linux.  Ditto for real-time -- it opens up Linux
to the space of real-time operating systems, especially for
embedded devices.

The current situation is "adequate", but maintaining a real-time
patch is a bitch -- either you have to use hooks and hacks,
or you have to spend all your time compensating for kernel
drift.  Some potential features are simply ignored, because
they would require closer intergration.

I realize that using hard-real-time to support crappy hardware
is, um..., a bit silly, but IMO it _should_ be done if it is
the best way to do so.  (Where's Alan when I need him?  He's
commented on this before.)

> Having non-hard-RT users start using the RTLinux functionality would be a
> disaster, in my opinion. The programming-interfaces are much more
> cumbersome, and the ways of making the system lock up hard are many and
> varied. 

With the currently developing option of hard-real-time in user space,
this argument is becoming less of an issue.

dave...

[1]  Yes, this is a troll.  Please ignore it.  It is a bit of an
exaggeration for use as a metaphor.