Newsgroups: comp.os.minix
Subject: Re: Future direction
References: <7idrd1$97i@cs.vu.nl> <374DF9E2.8B908B7@bellsouth.net>
Organization: Rochester Institute of Technology, Rochester, NY
From: aje9383@osfmail.isc.rit.edu (Andrew Erickson)
NNTP-Posting-Host: grace.isc.rit.edu
X-Original-NNTP-Posting-Host: grace.isc.rit.edu
Message-ID: <375be733.0@isc-newsserver.isc.rit.edu>
Date: 7 Jun 1999 11:37:23 -0500
X-Trace: 7 Jun 1999 11:37:23 -0500, grace.isc.rit.edu
Lines: 69
XPident: aje9383
X-Original-NNTP-Posting-Host: 129.21.3.100
XPident: Unknown
Path: star.cs.vu.nl!newsfeed.amsterdam.nl.net!sun4nl!EU.net!news-peer1.sprintlink.net!news-backup-west.sprintlink.net!news.sprintlink.net!isc-newsserver.isc.rit.edu!aje9383
Xref: star.cs.vu.nl comp.os.minix:35770

In article <374DF9E2.8B908B7@bellsouth.net>,
Max F Lang  <mflang@bellsouth.net> wrote:
>Andy Tanenbaum wrote:
>
>> I was wondering why there wasn't more discussion of this topic.  Are
>> there any people trying to port MINIX to these very small systems?
>> It might be a good match.
>> 
>> Andy Tanenbaum (ast@cs.vu.nl)
>
>In a word: "licence". As long as Minix is held in copyright by Prentice-Hall,
>there won't be much commercial development if there isn't the freedom to
>propogate the changes back into the source tree without involving the copyright
>holder. If Prentice-Hall could be convinced somehow to transfer the source into
>the GPL style licence and basically free the source up to let us use it as we
>see fit, there might be much more interest in doing such ports and even trying
>to make a little money at it. Until then, neither Minix is going to be seen for
>much besides education. And that would be a shame, as there's actually quite a
>lot under Minix' tiny hood.
>
>I'd have to say that seeing the copyright blurb on page 434 of the original
>edition is not very encouraging to unstifled development. The issue is, if I
>develop a nice Minix port to some palmtop, could I put the source onto a CD and
>sell it? I'd like to get my money back on buying the blank CD and the time for
>burning the source onto it. How about if I build a nice palmtop and decide to
>use Minix in the ROM? In either case it seems that Prentice-Hall's "licence"
>prevents it, not without involving them and their lawyers.
>With all due respect, Andy, Minix needs to be "freed".
>
>Max, Free*nix junkie.

Before we go on and on and on about the liscense (oops, too late...), has
anyone actually tried *asking* PH about using it for some commercial
product?

My gut feeling, and it's just a feeling, is that they'd be rather ammenable
towards liscensing it and it wouldn't be too big of a hassle.  More than
likely, their main concerns are that you won't sue them for bugs in their
code and that you won't write a new operating systems textbook based on
minix which is published by some other company (and thus eat into their
market share).

On the other hand, if my experience with textbook manufacturers as a student
is at all representative, PH would be more than glad to introduce a new
revision of OS:D&I geared towards embedded OS's; after all, every used book
that gets sold and reused is a new book that they don't sell.

(On the other hand, I doubt too many of Dr. Tanenbaum's books get sold; most
people keep thier copys forever and ever, as they are actually useful as
references and fun to read.)

One feature I would really like to see incorporated into Minix, and which I
would work at if I had time, is loadable device drivers.  It shouldn't be
too hard--have a special, fork-like system call which stuffs the executable
somewhere reasonable in memory, allows it access to all RAM, and stuffs its
major number and proc table entry in the FS device table.  This would
prevent many kernel compiles to change setup things, and would be a fairly
big win for embedded systems--only keep the drivers in RAM that you need in
RAM.  It would also make developing e.g. video drivers much easier.

I'd also appreciate it if new devices could continue to be accessed via
open/read/write/ioctl/close; the minix network implementation is much closer
to a proper UNIX philosophy than, say, BSD sockets.  If everything is a
file, by gum, let's keep *everything* accessible as a file.  Pointing
devices work pretty nicely as files; simply read a structure to get the
current position, button status, etc.  A graphics display could also be
accessible as a file, although that might get slow pretty quickly.

--Andrew Erickson, aje9383@grace.isc.rit.edu
