Re: [rtl] We are missing a whole point.

[Alex Dubov <oak@puma.technion.ac.il>]

yodaiken@fsmlabs.com wrote:

> This is not likely for technical reasons.
> 
 Right. It is more like a vision.


> Try to develop a periodic task with a 100microsecond period under
> Solaris and see what happens.
>
 I solely agree with this too. But my work lies primary in the
servocontrol areas (with a 10msec tasks). In these areas it is
especially desired (and possible) to reduce an auxillary tasks effort,
in favor of algorithmic development (servocontrol has a raising
importance in these days; some TI official even noticed, that there are
more electric motors, than cellular phones, in the industry).


> 
> We are moving towards a "debug under pthreads/ run in kspace" functionality.
>
 So the whole linux community (with the SGI's kernel debugger). But I
still insist, that all processing must be done in the user space (in
accordance with TS systems policy).
 
> 
> We are moving that way. Specific suggestions are nice.
> 
 I started some preliminary work on the new API. I think to get rid of
device numbers, in favor of "named" services. I also experimented with
'/proc' filesystem interface (one has no need to access the disk at all,
if he only wants to talk to some device drivers; this makes a '/proc' fs
suitable for the device interchange points, just in style of the new
'sysctl' interface; another point is to reduce the kernel-side interface
of module to the few, well-documented calls).

> 
> I don't see why this requires redesign.
 The best argument here is a story of sound card support on the laptops
(sound card is the best example of DA card from the normal world).
Because of some inherent problems in the kernel module mechanism, many
SC drivers are unable to properly save the context of the respective
cards, when computer goes to sleep; this renders the use of these cards
impossible after wake-up, untill a hard reset is performed (of course,
there is always a possibility, that driver designer had bad card
documentation).
 Another point is a waiting on the event. Is it possible to assure that
waking-up interrupt goes directly to assigned driver (as fast as
possible)?
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail majordomo@rtlinux.cs.nmt.edu OR
echo "unsubscribe rtl <Your_email>" | mail majordomo@rtlinux.cs.nmt.edu
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/