Ohh… That’s quite a statement. What makes ‘microkernel’ is modular
structure with modules running outside of kernel memory space. Mach3
is
exactly that (it even allows user-land pager daemon).
What makes a microkernel is a philosphy of simplicity of design and
minimalism. One could easily construct a massively over-engineered
kernel that demonstrated high modularity and ran many services in user
space, and this would not be a microkernel.
“user land pager daemon” != “user land cache management”.
It is also based
on message passing, only more sophisticated than QNX.
Message passing is (by definition of a microkernel message passing
architecture) implemented in the kernel.
“more sophisticated” == “more code” == “more complex”
If you don’t subscribe to the QNX philosophy of simplicity, then perhaps
Mach is the O/S you should be using ?
Mach
message-passing, unlike QNX is secure (has permissions attached to
‘ports’)
Oh yeah, just what I need, security data for IPC on my iPaq, or my
process controller
and works in 0-copy mode when possible, using copy-on-write
mechanism.
and what, exactly is the impact on scheduling latency (not to mention
footprint) for all this “cool” stuff ?
And on top of that it is binary-compatible with Unix. Which
is what killed it, ironically since it was competing against
monolithic
kernels and they were faster anyway, especially on the processors of
those days.
Hmmm, QNX didn’t die, I wonder why “superior” technology that was “open
source” “died”, when QNX didn’t ? Could it be that QNX actually met a
market need better than Mach ?
Nevertheless, most modern Unix variants were influenced heavily by
ideas
introduced in Mach.
Except for anything remotely related to microkernel architecture…
Too bad QNX was not (yet).
No, your right, QNX is heavily influenced by simplicity, and microkernel
architecture, not featuritis and Rube Goldbergism … Personally, I hope
it remains that way.
Well, if you watch QNX corporate video, they don’t really say ‘most
advanced OS for process control’. They say something more in line with
‘the most advanced architecture in the world’.
Often, marketing material isn’t designed to convey detailed information
about the target applications that a product is designed to address
(typically because marketing campaigns can encompass many revisions of a
product). I think that QNX6 is a very advanced architecture for the
market it is designed to address; I concede that the marketing material
does not clearly convey what the target market is; but I am also willing
to bet that QSSL sales/marketing rarely show up at customers who aren’t
in that target market. Those who read any marketing material in a
vacuum deserve what they get.
Also i would challenge calling good filesystem performance a
‘gee-whiz’
feature. May be for you it is, but not for most of us.
No. In my experience (15 years of QNX at 5 different companies in 3
different industries), a high performance filesystem, is a ghee-wiz
feature for most of the customers in the QNX target market (it always
has been). Many of the customers don’t even need a filesystem, those
that do, typically need a compact and robust filesystem, above a high
performance filesystem. As proof, I submit that QNX’s largest
competitor (and dominant player in the market that QSSL currently
operates in) is VxWorks which (for all intents and purposes) has no
filesystem; and certainly not a high performance filesystem by anyones
definition of the term…
IMO there are a minority of vocal advocates of a HPFS and IBC that make
a lot of noise, while the majority of users are FDAH without these, and
see no reason to get involved in these discussions. I just want to make
it clear that there are those of us out here for whom a HPFS is very low
on the priority list.
We (Motorola) use
QNX6 on ‘high-end’ server-type system and it needs to read and write
data efficiently. We have bypassed writing problems by using
complicated
queueing,
QNX is a real-time operating system. Even the most novice real-time
system designer knows the rule #2 of real-time system design: "no queues
- certainly not complicated queues". Therefore, if you solved your
applications “problems” by using queues, then I submit that your
application is not hard real-time. Perhaps QNX is not the best choice
for your application.
but there’s nothing we can do with reading. It gives us
3mb/sec on UltraWide SCSI and that translates directly into slow
startup, because we need to read large database at startup. Slow
startup
translates into longer downtime which is hardly tolerable in telecom
industry. And you bet we did tell that to our sales rep (couple years
back and kept telling ever since).
I’m not going to get into what QSSL sales told you or didn’t tell you
(since I haven’t a clue about that subject), I am simply voicing my
opinion, that I don’t believe a high performance filesystem, or an
integrated buffer cache is a high priority for those in our industry
(process control), or for most current QNX customers (including telecom
- haven’t seen any filesystems on routers lately…).
Would I like it if QNX had these features (at no cost in scheduling
latency or base footprint), certainly; but I wouldn’t be willing to
sacrifice very much to get them. QNX6 is starting to look very good in
the areas that I care about, but it isn’t quite there yet, and I
represent the traditional market; IMO they need to serve the traditional
market first, and then they can look at new markets (as long as it
doesn’t negatively impact the existing markets).
See how things look differently from
different perspective?
I am just trying to give you my perspective which is different to yours,
and (I believe) common to the majority of those who currently have
products based on QNX (and the QNX philosophy).