Newsgroups: comp.os.minix
Subject: Re: Future releases of Minix
References: <slrn88ac6e.hn.sletner@stormblast.sletner.com> <869ast$s9q$1@newsserv.zdv.uni-tuebingen.de> <3888b8fd.0@news> <acfa68.ksn.ln@jetsam.cs.vu.nl>
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: <388a46b3@news.isc.rit.edu>
Date: 22 Jan 2000 19:09:23 -0500
X-Trace: 22 Jan 2000 19:09:23 -0500, grace.isc.rit.edu
Lines: 83
XPident: dcw2428
X-Original-NNTP-Posting-Host: 129.21.4.100
XPident: Unknown
Path: news.adfa.oz.au!clarion.carno.net.au!news0.optus.net.au!news1.optus.net.au!optus!news.mpx.com.au!nsw.nnrp.telstra.net!intgwpad.nntp.telstra.net!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.nyu.edu!news-nysernet-16.sprintlink.net!news.sprintlink.net!news.isc.rit.edu!aje9383
Xref: news.adfa.oz.au comp.os.minix:34596

In article <acfa68.ksn.ln@jetsam.cs.vu.nl>,
Kees J Bot <kjb=732020@cs.vu.nl> wrote:
>There are a lot of ideas floating through my head concerning Minix'
>future, some of the "very likely" variety, and some of the "I wish I had
>the time" variety.  I thought it would be nice to write them down:
>
>- First the bad news:  It's not likely that much will change in user
>  space.  Both select() and the BSD socket interface are quite ugly from
>  a O.S. purist standpoint, and since Minix is a teaching O.S., we are
>  purists by definition.  (The current networking calls may not seem too
>  pretty either, but they map nicely to read(), write() and ioctl() and
>  don't need a slew of weird new system calls.)

I'm not sure I consider this "bad news"; I never really liked sockets all
that much myself.  (I'm too much of a purist, too, I guess :) ).  Select
would be nice, but not at all easy to put on top of minix itself.  Select
is really just an excuse for not being able to do proper asynchronous I/O
as well; and adding that might be even a bit simpler than select.

>- First of a list of things I like to change:  A general overhaul of the
>  code.  Everything must be ANSI C, and the number of definitions in the
>  include files must be reduced.  Definitions can be removed, or moved
>  to new include files that are only used in the files they are needed.
>  For example: ....  Why MACHINE and CHIP when the compiler defines
>  __i386 and __i86?

Yes!  Please!

(Would removing MACHINE and CHIP work reasonably for cross-platform
sources?  I'm thinking of the no-longer-up-to-date M68K ports, which
I would like to see updated (and would update if I were not working
on my thesis full-time now).  CHIP could probably be removed, but
MACHINE might still be needed; the compiler for the various M68K
ports is more or less identical.  Still, that could probably be done
via, say, cc or cpp more easily than elsewhere.)

<snippage>

>- I'm thinking about implementing a simple form of swapping....
>
>- With virtual memory Al probably means that pages are added to a
>  process when the break (the end of the malloc() area) or the stack is
>  moved.  VM to disk (paging) is of a different order.  Alas VM alone is
>  already quite disruptive to Minix structure....

Paging of any sort will require substantial changes to MM; a hole list
would be quite inadequate as the basic data structure.  Swapping might
be interesting, though.

>- Get rid of the zones in FS, make a block the only file system unit.
>  Never in its life has Minix ever seen zones larger than a block...
>  Wrong endian file system support can also go.

Would blocks then be variable-sized?  Or is the 2.0 FS no longer limited to
sixteen-bit block numbers?  Having a (theoretical) 64 MB limit on file
systems (and often an actual 32 MB limit, due to some signed/unsigned
problems in utilities, etc.) is a fairly substantial drawback, IMHO.

<more snippage>

>- Something else Minix-vmd now has is a new disk device naming.  A
>  partition in this scheme is characterized by controller, disk,
>  partition, and subpartition number....

Good.

>- The inet task must be moved out of the image, to be started in user
>  mode.  This makes it possible to run some ethernet board initialization
>  code first, before starting inet.  It will also make it possible to
>  distribute a network enabled kernel, because the ethernet drivers
>  alone aren't that big.

It would be cool if device drivers could also be moved out of the image
and loaded separately by a utility; I don't believe this would be too
difficult to do, and allows for quite a bit more sophisticated usage.

>- An ATAPI driver, an NCR SCSI driver, support for PCI devices, and a
>  year of paid leave from work to implement all this.  :-)

I thought those were just kind of assumed by all involved, no?

-- 
Andrew Erickson
