Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: patent on O_ATOMICLOOKUP [Re: [PATCH] loopable tmpfs (2.4.17)]
Original-Message-ID: <Pine.LNX.4.44.0205251651460.4120-100000@home.transmeta.com>
Date: Sun, 26 May 2002 00:07:51 GMT
Message-ID: <fa.m8ueeav.150o80s@ifi.uio.no>

On Sun, 26 May 2002, Robert Schwebel wrote:
>
> Show me how you will implement a closed loop controller where the
> application is _not_ implemented as a kernel module. I would really love to
> do it this way, but unfortunately no one of the realtime programmers has
> found a way how it can be achieved so far.

The thing is, if your whole app is really RT, then neither RTAI nor
RTLinux will help you all that much.

The "user space" in RTAI ends up being equally limited as any kernel
module in RTLinux. No dynamic memory allocation, no deep recursion, no
regular system calls. That's just fundamental to hard realtime, and has
nothing to do with any of the environments themselves.

The "advantage" of RTAI is a copyright license issue at that point,
nothing more (well, you get your own address space, but since you mustn't
fault anything anyway, the advantage is dubious, _and_ it certainly eats
into your performance). And as explained elsewhere, I don't find that to
be an advantage at all (and as pointed out by Larry, there seems to be
some dubious issues about the RTAI copyright itself).

Don't get me wrong - I'd love to say that it could be easily fixed by
doing xxxx, but the fact is that since the linux kernel itself isn't hard
realtime, the lack of kernel services really is unavoidable.

And once you lack kernel services, from a programming standpoint it
shouldn't really matter whether it's a kernel module or not. You've got
basically the same amount of (or rather, "lack of") support. A lot of
things are a lot easier in kernel mode (interrupts, IO etc), while you
might find loading the app etc easier in the RTAI model, for example. You
win some, you lose some.

Can we make the whole kernel truly hard-RT? Sure, possible in theory. In
practice? No way, José. It's just not mainline enough.

So I'm agreeing with you: for true hard RT, you need a kernel module. I
can't come up with a way to avoid any of the fundamental problems either..

			Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: patent on O_ATOMICLOOKUP [Re: [PATCH] loopable tmpfs (2.4.17)]
Original-Message-ID: <Pine.LNX.4.44.0205251729490.4355-100000@home.transmeta.com>
Date: Sun, 26 May 2002 00:40:06 GMT
Message-ID: <fa.m8uqeav.150080h@ifi.uio.no>

On Sat, 25 May 2002, Linus Torvalds wrote:

> Can we make the whole kernel truly hard-RT? Sure, possible in theory. In
> practice? No way, José. It's just not mainline enough.

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.

Every single RT person out there is already painfully aware of (and used
to) having to limit the set of functions he can use while RT, so this is
something you guys tend to be pretty familiar with..

So the "hard-RT" thing doesn't need to be a complete on/off thing.

This kind of "limited kernel functionality" tends to help only RT kernel
modules, though. Full system calls (except the trivial ones like
"getpid()", of course) simply tend to have to require too much "real"
infrastructure that they can't use the RT subset.

Also, some people will he happy to know that soft-RT ends up getting
continually improved, and many people might be able to find that just the
regular preemptible kernel gives good enough latency at least if you can
limit the workload on the machine (which, on embedded devices tends to be
something you take for granted anyway).

That may not make the hard RT people happier, but at least it might shrink
the number of the die-hard hard RT'rs.

"If you can't beat them, try to make them extinct" ;)

			Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: patent on O_ATOMICLOOKUP [Re: [PATCH] loopable tmpfs (2.4.17)]
Original-Message-ID: <Pine.LNX.4.44.0205252116240.1028-100000@home.transmeta.com>
Date: Sun, 26 May 2002 04:21:38 GMT
Message-ID: <fa.m6tudav.150g90j@ifi.uio.no>

On Sat, 25 May 2002, Oliver Xymoron wrote:

> I'm sure you know this route is not very useful - there's practically
> nothing that we can push across the hard RT divide anyway. We can't do
> meaningful filesystem I/O, memory allocation, networking, or VM fiddling -
> what's left?

Atomic memory allocation, for one. Potentially very useful.

> Cleaning up soft RT latencies will make the vast majority of people who
> think they want hard RT happy anyway.

I certainly personally agree with you, but the hard-liners don't.
Remember: it took the hard-RT community a long time to accept radical new
things like CPU caches, and some of them _still_ like the ability to lock
down cachelines..

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: patent on O_ATOMICLOOKUP [Re: [PATCH] loopable tmpfs (2.4.17)]
Original-Message-ID: <Pine.LNX.4.44.0205251057370.6515-100000@home.transmeta.com>
Date: Sat, 25 May 2002 18:12:31 GMT
Message-ID: <fa.m9ece2v.17gu8ov@ifi.uio.no>

On Sat, 25 May 2002, Wolfgang Denk wrote:
>
> What do you think: it it OK (both from the legal and from  the  ethic
> point  of  view)  that  somebody  writes  and distributes proprietary
> application code?

That's not my point.

My point is that from a technical standpoint, I think giving user land
higher priorities than the kernel is _wrong_.

It gets you into all the priority inversion stuff, where you suddently
must not do simple system calls because the regular kernel locks are no
longer safe to use. That's a HUGE design mistake, and a classic one. Yes,
others have done it that way. A billion flies _can_ be wrong - I'd rather
eat lamb chops than shit.

In short:

 - I think the microkernel approach is fundamentally broken. Karim claims
   there is no priority inversion, but he must have his blinders on. Every
   single spinlock in the kernel assumes that the kernel isn't preempted,
   which means that user apps that can preempt the kernel cannot use them.

   (Or RTAI just handles the priority inversion the way that it has been
   handled in other places: by dropping the priority on the floor when
   calling into the kernel. Whatever. It's still priority inversion, and
   it's still broken).

   It's worse than that. Something as simple as growing your stack a bit
   too much will cause a hard kernel failure (or failure of the RT part,
   assuming that the priority is dropped). Karim claims to give "user
   land" hard-real-time abilities, but the fact is, it's not "user land"
   any more. it's a limited shadow, and a _perversion_ of what user land
   is supposed to be all about.

   This is my _technical_ reason for saying that user-land hard realtime
   sucks, and SHOULD NOT BE DONE. That way lies madness, and crap.

 - My other argument is one of FUD against the patent. People claim that
   the RTLinux patent stands in their way, and they are full of _crap_.

	- The patent only covers a specific way of doing things, which as
	  far as I can tell isn't even an issue with RTAI. In short, the
	  RTLinux patent has about as much to do with "holding up
	  real-time development on Linux" as every other patent out there.

	- Yes, if you go the RTLinux way, you either need to make your RT
	  kernel modules GPL'd, or you need to pay FSMlabs. Since I would
	  strongly suggest you make kernel modules GPL'd anyway, this just
	  isn't an issue. The fact that FSMlabs can get people to pay for
	  their patent is just another "tax on stupidity".

	  And "tax on stupidity" is fine by me. People who don't want to
	  use the GPL might as well pay for it, either by paying FSMlabs
	  or by paying somebody else. I don't care.

Have I made myself sufficiently clear by splitting up the issues into a
technical part and a FUD part?

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: patent on O_ATOMICLOOKUP [Re: [PATCH] loopable tmpfs (2.4.17)]
Original-Message-ID: <Pine.LNX.4.44.0205251138390.17649-100000@home.transmeta.com>
Date: Sat, 25 May 2002 18:47:33 GMT
Message-ID: <fa.l6dboqv.1hhk3hn@ifi.uio.no>

On Sat, 25 May 2002, Karim Yaghmour wrote:
>
> Blinders ehh... Well, if you would care to ask I would answer.
>
> In reality, what you point out is actually a non-issue since the hard-rt
> user-land tasks are not allowed to call on normal Linux services. They
> can only call on RTAI services which are exported by an extra soft-int.
> These services are hard-rt, so there's no problem there.

... which was exactly what I said:

 "..every single spinlock in the kernel assumes that the kernel isn't
  preempted, which means that user apps that can preempt the kernel
  cannot use them."

Karim, I don't _need_ to download RTAI or ask you questions about how it
works, because this is fundamental "RT-101" stuff. This is what priority
inversion is all about: if you make user land more important than the
kernel, it _cannot_ stay RT and use kernel services.

I went on to say:

   "Karim claims to give "user land" hard-real-time abilities, but the
    fact is, it's not "user land" any more. it's a limited shadow, and a
    _perversion_ of what user land is supposed to be all about."

Which certainly should have told you that I understood the limitations of
RTAI very well indeed. And I reject them.

		Linus