lkml.org 
[lkml]   [2005]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: RT patch acceptance
From
On Thu, Jun 02, 2005 at 12:32:50AM +0200, Andrea Arcangeli wrote:
> Do you worry about "less work" after all this new stuff added? I'd
> understand "less work" for a simple and safe solution like rtlinux/RTAI,
> but going down your path, isn't looking for "less work" or "simpler".

This has already been discussed earlier in this thread.

> The advantage you get with preempt-RT is a chance to run syscalls with
> higher prio by sharing the same syscall code of the non-RT case, but
> it'd be little advantage if you then have to lose in reliability.

This is not the purpose of the patch, nor will it ever be. RT apps don't
depend on this property as was previously mentioned in this thread.

> The argument that only a subset of drivers is used isn't very valid,

It's being done. It's works and it's valid.

> people will just assume it to be hard-RT and they could build hardware
> with random drivers thinking that they will get the gurantee. I
> understand it's ok with you since you're able to evaluate the RT-safety
> of every driver you use, but I sure prefer "ruby hard" solutions that
> don't require looking into drivers to see if they're RT-safe.

Again, this has been covered previously by this thread. It's ultimately
about writing RT apps that have a more sophisticated use that RTAI or
RT Linux.

bill

-
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/

\
 
 \ /
  Last update: 2005-06-02 01:02    [W:0.311 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site