Re: [rtl] X win and RT problems

[David Olofson]

On Monday 19 February 2001 23:41, daniel sheltraw wrote:
> Hello Linux Realtimers
>
> I have seen some discussion on the problems X Windows causes with
> RT scheduling. What are those of you that have abandoned X Windows
> altogether using in place of Xfree86?

svgalib, fbdev, or just plain text, I guess...

Note that fbdev is basically a DDT for Linux/lowlatency, as it burns up to 10 
ms in kernel spare for some operations. Shouldn't matter to RTL or RTAI, 
though.


//David

.- M A I A -.
|  Multimedia Application Integration Architecture  |
| A Free/Open Source Plugin API for Professional Multimedia |
`--> http://www.linuxaudiodev.com/maia -'
.- David Olofson ---.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--> [EMAIL PROTECTED] -'
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

[rtl] RTLinux under 2.4.1 with NOLinux option.

[Christopher D. Carothers]

Hi all. Just an fyi, if you want to get the NO LINUX option to
work under the 2.4.1 distribution, you need to modify main/reserve_cpu.c .
The variable "priority" has been changed in the task_struct to "nice" it
seems.

With that change rtl.o will build correctly.

Regards,
Chris


Christopher D. Carothers

Assistant Professor
Department of Computer Science 
Rensselaer Polytechnic Institute
110 8th Street
Troy, New York 12180-3590

e-mail: [EMAIL PROTECTED]
web page: www.cs.rpi.edu/~chrisc
phone: (518) 276-2930 
fax: (518) 276-4033



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

[rtl] X win and RT problems

[daniel sheltraw]

Hello Linux Realtimers

I have seen some discussion on the problems X Windows causes with
RT scheduling. What are those of you that have abandoned X Windows
altogether using in place of Xfree86?

Thanks all,
Daniel
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

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

[rtl] regression tests in v3.0

[Brad Fitzgibbons]

I've installed RTLinux v3.0 (2.2.18) and everything appears to be
working just fine.  However, the
thread_app regression test complains that poll (on fifo) is not
available.  It appears to be implemented in the source so I was just
curious if someone might be able to explain it.  I'm new to
RTLinux so please don't shoot me if this is a repeated question.

Thanks.

Brad Fitzgibbons
[EMAIL PROTECTED]

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

[rtl] [Update] licences and patents

[Bernhard Kuhn]

Hi everybody!

First of all, thank you for your input ... makes
things much clearer now!



No legal actions prepared
=

Although there were some roumors and signs,
i am very happy to tell you that neither Victor
nor Paolo intend to do legal actions against
each other:

Victor Yodaiken: "[...] We are not planning any legal actions
against anyone although we are being careful to get
legal opinions. [...]"

Paolo Mantegazza: "[...] I do not know what Yodaiken is
doing but I'm not preparing any legal action. [...]"



Additions/modifications to GPL in Linux Kernel
==

As Robert Schwebel already mentioned, there is
an addenum/preface to the linux kernel licence file:

  NOTE! This copyright does *not* cover user programs that use kernel
  services by normal system calls - this is merely considered normal use
  of the kernel, and does *not* fall under the heading of "derived
  work". [...]

This statement only clearifies the use of user space
programs, but not the usage of kernel space modules.
Two years ago, L.T. wrote the following statement on
the kernel mailing list. As none of the other copyright
holders (the kernel developers) "dared" :-) to object
to this statement, it can be taken as officialy granted:

  [...] I _allow_ binary-only modules.  I allow them because I think
that
  sometimes I cannot morally require people to make sources available to
  projects like AFS where those sources existed before Linux. [...]

So, you can now argue that adding kernel space modules also
"is merely considered normal use of the kernel" and thus
"does *not* fall under the heading of 'derived'".

For this reason, RTAI-modules can be distributed under LGPL
and RT-Linux-modules under any licence. But the kernel-patch
itself has to be GPL, because GPLed files are modified directly
instead of creating new files that can be compiled as modules.



And the Patent?
===

Concerning the software licences, the world looks fine, again.
But there is still the patent left! It basicaly says

  "[...] use of the Patented Process is permitted, without
  fee or royalty, when used: A. By software licensed
  under the GPL [...]"

Means, you will have to pay a patent licence fee to fsmlabs
when using LGPLed RTAI in US. You don't have to pay a fee when
using RTAI and/or RT-Linux in contries where
US patents have no legal effects. Especialy in europe,
where software patents are only allowed under very
rare circumstances, the RT-Linux patent very likly
wouldn't be granted,

Victor pointed me to a patent granted in Germany
that is similar to his patent. But as there
are thousends of patents filled and granted
illegaly, that doesn't mean very much: this
patent can probably be deleted within a short
amount of time.

In US, the situation is different, and it might not
be a good idea to do legal actions to delete the
patent there, too: There are several similar patents
around that could apply to Victors process. Means:
things could be even worse when deleting the patent,
because the other patent holders could do a much
worse patent licence (i.e. you have to pay even when
using GPLed code).

At least, Victors patent mostly want's to protect the
mechanism, so that no other company can claim their
rights, but there are probably thousands of
code fragments in the linux kernel that are covered
by US patents - and nobody cares, because on one hand,
it is not easy for the patent holders to find out
whom to sue and on the other hand, a patent-suit can
be very expensive and the result is oftenly uncertain.

Also Victor patent forces developers to uphold free software
standards: "get millions lines of code for free, but
return your thousends lines of code you have created
back to the community."
On the other hand, propietary kernel modules mean "money
is floating around" and fsmlabs just want to have some
small pieces of the cake.

Comments?

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

[rtl] Re: [realtime] Re: [ANNOUNCE] Adaptive Domain Environment for OperatingSystems

[Mark_H_Johnson]

Hmm. I'm somewhat concerned about an apparent attitude of...
 - if the hardware does "X" (e.g., PCI stalls), the software can't do
anything about it
Yet the example of X and "non spec" cards appears to be part of a problem
that a real time developer needs to...
 - know about and understand
 - the software COULD do something different that didn't cause the problem
to begin with
As a system designer, I want to know where the "oopses" are and avoid them.
In our case, we weren't planning on running X anyway, but we might have
similar problems with network I/O, the cluster interconnect, and some
occasional disk I/O. Are there some things we should look for and avoid for
those cases?

We're looking at a cluster of machines to run a real time simulation
(fastest rate 80hz). Its a large system that we are unwilling to run in
kernel mode. Our system needs relatively low latency and jitter. However,
for most of our code, a millisecond here or there isn't a big deal. For a
couple specific hardware interfaces - we have an exceptionally tight
tolerance (+/- 50 microsecond jitter on data transfer, 80hz rate). We'll
use a hardware assist for now - perhaps a kernel RT task later.

The solution we're looking at today is a combination of...
 - low latency patches to Linux
 - some form of "user land" RT for most of our tasks (RT_FIFO, LXRT?)
 - a few items [TBD] to be under RTLinux, ADEOS, or similar product
>From what I've read in the ADEOS docs doesn't help much over what RTLinux
does today other than avoid the patent [which does have value to us]. What
we'd prefer to see more focus on good performance in user mode and still
have access to non-blocking Linux services. I see most of the solutions
suggested to date are unable to meet that need.

--Mark H Johnson
  


   
  
Karim Yaghmour 
  
<[EMAIL PROTECTED]>   To: Cort Dougan 
<[EMAIL PROTECTED]> 
Sent by:  cc: William Montgomery 
<[EMAIL PROTECTED]>, 
owner-realtime@realtim[EMAIL PROTECTED], 
[EMAIL PROTECTED]
elinux.orgSubject: Re: [realtime] Re: 
[ANNOUNCE] Adaptive Domain Environment for 
  Operating Systems
  
   
  
02/16/01 04:51 PM  
  
   
  
   
  




Hello Cort,

You're somewhat right. There are hardware issues that may be out
of the reach of any software, the PCI stall example is a good
one. On the other, whether RTLinux is running on Alpha, MIPS or
PowerPC, device drivers can still issue the equivalent cli/sti
and ruin determinism. There's nothing RTLinux can do about it.

Best regards,

Karim

Cort Dougan wrote:
> [snip]
> Current versions of X (4.x) are pretty aggressive with cards that are not
> entirely spec which results in PCI stalls.  That's a problem for any
> real-time system since software can't do much about this once it's
> happened.



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

Re: [rtl] Article about RTL/RTAI licence and patent situation

[Robert Schwebel]

Hello Bernhard, 

On Sun, 18 Feb 2001, Bernhard Kuhn wrote:
> Just adding or modifying code in GPLed files will certainly result in
> a "derived work", means it has to be GPL.

please take into account that the kernel has an addition to the GPL: 

--8<--8<--8<--8<--8<--
callisto:/usr/src/linux/drivers/char # head /usr/src/linux/COPYING 

   NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".
 Also note that the GPL below is copyrighted by the Free Software
 Foundation, but the instance of code that it refers to (the Linux
 kernel) is copyrighted by me and others who actually wrote it.

Linus Torvalds

callisto:/usr/src/linux/drivers/char #
--8<--8<--8<--8<--8<--

Therefore using header files (which is necessary to write programs which
use the kernel functions) does not result in a "derivative work" and it is
possible to run proprietary applications on Linux. 

The more interesting questions are a) if releasing RT Linux under another
License than the kernel is possible as the code doesn't really make sense
if it is not patched into the kernel (and in that case it _is_
derrived!) and b) if the technique of running an operating system ontop of
another one hasn't been common practise at the time the patent was
accepted (which meant that it could easily be eliminated in case there
will be somebody who pays the lawyer). 

My impression from lots of talks with technical people at the Embedded
Systesm was the same as your's: anybody is unsure about what the future of
realtime linux variants might be. If the question of licenses will not be
solved in a positive way Linux in industrial applications will be _dead_
because it'll be on the same level as any other commercial OS. I hope that
ones who are responsible for the dilemma know what they are doing...

Robert
-- 
 +--+
 I Dipl.-Ing. Robert Schwebel, Luedemannstrasse 25, 24114 Kiel, Germany I
 I Phone +49-431-6794138 Fax +49-431-6794139 email: [EMAIL PROTECTED]  I
 +--+

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

Re: [rtl] Re: [realtime] Re: [ANNOUNCE] Adaptive Domain Environment for Operating Systems

[Paolo Mantegazza]

Karim Yaghmour wrote:
> 
> Hello Cort,
> 
> You're somewhat right. There are hardware issues that may be out
> of the reach of any software, the PCI stall example is a good
> one. On the other, whether RTLinux is running on Alpha, MIPS or
> PowerPC, device drivers can still issue the equivalent cli/sti
> and ruin determinism. There's nothing RTLinux can do about it.
> 

The cli/sti is just for ix86. From many other archs you'll get just a
fault since you are trying to manipulate the status register, to cli/sti
the related flag from a lower privilige. Can anybody tell me how can one
ascertain that the status register is being access just for cli/sti
without touching Linux code?

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