Messages in this thread |  | | | Date | Sat, 25 May 2002 21:28:32 -0600 | | From | yodaiken@fsmlabs ... | | Subject | Re: patent on O_ATOMICLOOKUP - Warning actual technical content. |
| |
On Sat, May 25, 2002 at 05:39:00PM -0700, Linus Torvalds wrote: > Side note: we could, of course, mark some spinlocks (and thus some > code-paths) as being RT-safe, and then make sure that those spinlocks - > when they disable interrupts - actually disable the _hw_ interrupts even > with the RT patches. > > That would make those sequences usable even from within a RT subset, but > would obviously mean that those spinlocks have to be checked for latency > issues - because any user (also non-RT ones) would obviously be truly > uninterruptible within these spinlocks.
How about something more useful: interval progress assurances? Such as "during any 5 second period this process will be able to read X meg of data from a file and write Y meg"
So if I have an RT task that dumps data to a DVD at millisecond intervals, I can be sure that the non-RT task that reads the FS and puts data into a buffer will never let me run out of frames on a given shared memory size.
This is useful in itself for nonRT Linux too. It seems quite hard, but it could be relatively robust, once it was in place - making a 1 millisecond worst case turn into a 10 millisecond worst case would not break it.
--- BTW: I'm ignoring the 10 billionth rehash of the RTLinux/RTAI debate since there seems very little purpose in not doing so. People who have actual questions should feel free to ask me directly - publically or privately, I don't mind. Those on tape loops can keep repeating themselves without my assistance.
-- --------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |