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