Linus Pooh-Pooh's Real-Time Patch

An anonymous reader submits "Speaking with CNet via email, Linus Torvalds appears to be in no hurry to accept the latest real-time patches from embedded specialist MontaVista into the mainstream kernel, at least not "at this time." Nontheless, MontaVista's new open-source real-time Linux project could broadly expand commercial opportunities for the open source OS, especially in telecom initially, where real-time Linux will likely play on "both ends of the wire." For example, Linux is already making progress in smartphones."

Patents ?

[Anonymous Coward]

Wouldn't a real time patch violate software update patents

Re:Patents ?

[ryanmfw]

It's not a *real time patch*, it's a *real time* patch. It doesn't change the kernel while running, it changes the behavior of the kernel to be a real time one. I'm a little hazy on the difference, but I think it mainly has to do with scheduling, and that it will give high priority tasks all the time they need.

Re:Patents ?

[Rosco P. Coltrane]

Perhaps Victor Yodaiken might want to pull another one of his lame patent stunts [linuxdevices.com] on Montavista. That'd be rather amusing actually...

Re:Better link

[Anonymous Coward]

And a link to the Slashdot story [slashdot.org] where we discussed the real-time patches on Saturday.

There are TONS of non-mainstream things there

[MoralHazard]

Has anyone ever taken a look at some of the stuff available in the 2.6 configuration options? Do a 'make menuconfig' and browse through the "General Setup" and "Processor Type and Features" submenus. A bunch of it is wholly useless to 99.9% of the installations out there.

But it's there as an option, if you want it, like most everything else. Have a tulip ethernet card? Include the driver. If you don't, leave it out. Old BIOS doesn't do ACPI? Leave it out. Don't need a keyboard driver because it's an appliance system? Leave it out.

Why the hell not just include the real-time business as options? Is the maintenance really that much more challenging?

Anyone finding this suspicious?

[swordboy]

Here's something that Montavista has contributed to the Linux kernel - PRAMFS [sourceforge.net]. A quote (emphasis mine):

Many embedded systems have a block of non-volatile RAM seperate from normal system memory, i.e. of which the kernel maintains no memory page descriptors. For such systems it would be beneficial to mount a fast read/write filesystem over this "I/O memory", for storing frequently accessed data that must survive system reboots and power cycles. An example usage might be system logs under /var/log, or a user address book in a cell phone or PDA.

[...]

2. If the backing-store RAM is comparable in access speed to system memory, there's really no point in caching the file I/O data in the page cache. Better to move file data directly between the user buffers and the backing store RAM, i.e. use direct I/O.

They've described that they want to use this stuff in a cell phone or PDA, yet have described an NVRAM technology that does not exist (as fast as system memory?). Methinks that they're working with Intel on some new fangled NVRAM, [intel.com] (hint, look for Ovonic). Samsung appears to be working with PRAM [zdnet.co.uk] as well.

So this MontaVista file system is a PRAM-File System, maybe...

Alternatives?

[Tellalian]

At the risk of sounding redundant, how is MontaVista's implementation significantly better or different from pre-existing real-time Linux interfaces, such as FSMLabs' RT Linux [fsmlabs.com] or DIAPM's RTAI [rtai.org]?

What is it needed for?

[El]

What can an RTOS do that Linux can't that wouldn't be better handled in hardware? If responding to a given event is really THAT time critical, then perhaps you shouldn't be handing the event all the way up to your systems software for a response... In my experience, most problems that people claimed demanded "real time" to solve could be more easily solved by adding more buffers.

Re:Can this be a config parameter?

[ceswiedler]

The existence of the code in the main kernel, regardless of whether it is enabled at compile time, affects everybody. It's not like you're going to have a single place with

#ifdef REAL_TIME_KERNEL

...lots of code

#endif

It's going to change a lot of things in a lot of places. Ideally, it will make infrastructure changes which benefit everyone, by abstracting certain elements of the code, which then makes its own specific features fit in nicely. Unfortunately, this is very difficult to do with real-time scheduling.

Re:Barely a story.

[SnowZero]

His job is to say no a few times, so that developers create better and better versions of the feature, until one is good enough and he says "yes".

Kernel cleanly done kernel-preemption patch went in, but the "lock-break" patch which predated it did not . That's because the latter peppered "reschedule me" calls all over the code tree. If he hadn't said "no" the first time, the later clean solution probably would not have come.

RT OSs are not inherently slower

[Anonymous Coward]

There is no price to pay for running a good real-time OS in terms of efficency. There is a monetary cost (licensing fees).

Folks who say otherwise are just quoting the silly wickipedia and have never worked with a good real time OS (like QNX - www.qnx.com).

For example, on QNX the scheduler runs every 10ms by default. You can increase the frequency, say to 1ms, or .2 ms if you are running a control app that needs higher frequency. Then you have more overhead.

Oh - you get to set real priorities for your processes, and scheduling disiplines per process (FIFO, RR, "fair", etc.)

There is nothing in the definition of a real-time OS that requires it to be slower or less efficient than a non-real-time OS.

QNX transfers disk data at platter speeds, and has done so forever. Network data at the rate of your network.

It is just a far superior OS than Linux, and I use both professionally and have written device drivers for both. It lacks 3rd party software and driver support - and some people won't understand why that doesn't mean it is inferior as an OS to Linux.

Want to write a device driver? In QNX just write a user mode program, use the language of your choice (C, C++). Debug it with DDD or your favorite debugger. You're not stuck in kernel mode using C like in Linux.

Want to access the serial port on another machine without writing any network code? Open "/net//dev/ttyS0" instead of "/dev/ttyS0". The OS handles it transparently for you.

Same with any file/device. Copy all the files from machine "bob" to your home directory on your machine? "cp -r /net/bob/* ~"

Need more processing power? Just move some of your processes to another machine, no need to rewrite your code to use a network protocol - the built in msg passing works with a global namespace and connects you to the right process on the right machine.

The GUI system is unbelievable, designed for networking from the ground up. You can move a window accross machines on the network, or have multiple people sharing the same desktop, or different portions of the same desktop, or multiple sessions (a-la traditional windowing systems). Without writing any special networking/gui code.

QNX is free for non-commercial use. Read about it. Use it. Don't be a wickipedia fool, badmouthing real-time operating systems :)

It's been around for 20 years. It was the best when it was multitasking on my 286 and it still is the best now on a P4/3GHz.