4 Aug
2006
4 Aug
'06
11:28 p.m.
Don Y wrote:
Alexey Toptygin wrote:
Not exactly multiple entry points, but a main() that just parsed argv[0]
and a shitload of hard links or symbolic links.
On Thu, 3 Aug 2006, Chuck Guzis wrote:
Yes and no.
Of course it is a special build. Just like bootable *BSD floppies
"crunch" the core utilities into a single executable image
(with multiple entry points) instead of separate binaries. Maybe, but Linux doesn't have anything like
the old QNX demo--an OS and
browser that boots from a single 1.44MB floppy:
http://toastytech.com/guis/qnxdemo.html
Even back then, it impressed the heck out of me.
They could only get away with that because of the supported hardware:
Hardware requirements:
* 386 or better.
* 8 megs of ram.
* Hardware / RS232 modem (not a winmodem) or NE1000/2000, DEC 21x4x,
or 3com 509 based network card.
* Serial or PS/2 mouse.
* VGA or Vesa 2.0 compatible card.
* No hard disk needed
That must be the simplest set of x86 hardware that you can write a
networked, protected VM OS on; all long-lived, well-defined
interfaces, and only one set. No disk drivers even :-) Could you fit
into such a small footprint with their stock kernel? I doubt it; I
think this was a special build. But, one key difference between the QNX approach and
that of
most other current OS's is the microkernel architecture.
Instead of a BIG monolithic kernel with ALL the drivers
installed (or, extra glue for LKM support, etc.), a microkernel
based design treats all of these as components which can be
plugged together. And *talk* to each other (instead of being
invoked "from above").
I suspect that they could REPLACE the support for NE1000 cards
with some OTHER card and not change the overall footprint
by much. And, *possibly* not even have to relink (!?).
Minix 3 comes to mind on this.
Even Mach -- probably the most bloated microkernel --
would
fit into a 1MB footprint. OTOH, how big is the latest
Linux Kernel? The NetBSD kernel that I run is almost 3M...
and I've trimmed out much of the support for devices that
aren't present in my machine!
> Then there's their entirely in-house userland. Could you fit a variety
> of things written by different groups? Again, I doubt it; code would
> be duplicated, and it would be hard to remove everything non-essential
> without removing something essential attached to it.
That's when you make like Busybox, combine all utilities into one
program, and have main() call out each 'program' subroutine based on the
string pointed by by argv[0].
QNX doesn't try to be a desktop OS. Just like Linux doesn't
claim to be MacOS.
I think that's why some people that use that OS act like jerks --
they're fustrated at their machines :>
I don't hate QNX, but for some reason this
demo has always irked me; I
don't feel it's fair to compare a nifty trick to a complete minimal
I dont see it as a nifty trick. You want "tricks"? Look at
PIC-based web servers :> Gives new meaning to the term
"truth in advertising" :-(
system. If you want to do something practical on
x86, you'll need a
lot more than one floppy. Today's debian installer needs 2 1.44
floppies of drivers on top of the most common ones built into the
kernel (which lives on its own 1.44 floppy).
But that's a consequence of the way that *they* decided to support
the hardware that *they* chose to support! Do they support
Mitsumi CD-ROM's? Adaptec 1542's? ATM / SONET?
Gee, there's another OS that tres to do all of those things.
I think it's made by MS... :> A single floppy is a *lot* of code. You can *do* a
lot with
that much code (since it only needs to reflect the size of
the TEXT segent, more or less, and could conceivably be a
compressed executable). Look at what most cell phones do
nowadays...
If you want to burden the implementation with "this has to
run on ANY conceivable x86 machine built since 1980", then
you're imposing a lot on the design. How many Linux kernels
will boot on a 4MB machine? What about a *1* MB machine??
What about ELKS?
No, I'm not a fan of QNX (their licensing doesn't justify
the value they add). But, I think this is a reasonable
marketing ploy -- especially to a market (embedded systems)
where an 8MB machine is considered "resource RICH"!
Agreed.
--
The real problem with C++ for kernel modules is: the language just sucks.
-- Linus Torvalds