Victor Yodaiken wrote:
> As some of you may have noticed, we have a commercial venture that is now paying for 
>most
> of the core RTLinux development. Now I feel like I need to make more of an effort to
> open the design and development process. ...

In general, thumbs up to everything, good work.  Yes to the pthreads API
which enables debugging, yes to hardware clocks, yes to specifying which
processor your rt "thread" runs on ...


> ------------------------------------------------------------------
> 6.3.1.3 Files and directories
> 
> --- RTLinux will have a posixio module to give a basic framework for drivers.
> 
> "The open function is needed to do basic device I/O, also to provide device 
>initialization."
> "Although this requires some form of name resolution, a full pathname is 
>specifically not
> required. Directories are also not required."
> 
> open(s,mode) == if(s[1] != 0 ) return -EINVAL; return 
>symbolic_name_to_fifo_number(s[0]);
> ------------------------------------------------------------------
> 6.3.1.4 Input and output
> 
> "The functions _read_ _write_ , and _close_ are required to do basic i/O and device 
>cleanup."

Are you talking about rt-fifo devices only ? what other devices are
there in rtl ?

Are you saying that rtl users create devices for their ADC cards, etc
and access those cards with open(), close(), read(), write(), etc.  This
would be resisted by the average hacker, but is arguably the "right" way
of writing drivers portable to soft real time, etc.


>---------------------------------------------
>6.3.1.1 Process Primitives
>"most POSIX.1 process primitives to not apply."
>but
>"Signal services are a basic mechanism with POSIX based systems and are required for 
>>error and 
> event handling"

>In RTL we intend signals to be constructed from the rtl_mutex primitive and an 
>>unspecified mailbox implementation.
>kill(p,s) == { put s in mailbox(p); 
>>if(rtl_is_waiting_muxtex(p,mailbox(p)->mutex))rtl_mutex_release(mailbox(p)->mutex)
>---------------------------------------------

Is this saying a linux user space app can kill a rt process? what about
permissions checking - only root can do this ?


> 6.3.2.1 Realtime signals
> 
> --- My grand plan for signal.
>     1. hate em
>     2. despise em
>     3. implement them via brute force. There will be a posix_sig
>        module that does the following on a kill
>        A. lock everything
>        B. if the target is ignoring, return
>        B. go to the scheduler machine dependent saved state of the
>           target and patch it to jump to handling code
>        C. unsuspend  target
>        D. done

OK, but what is the the above kill() primitive necessary if we can send
signals to a rt proc ?


-- 
Steve Rosenbluth

--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/

Reply via email to