All of lore.kernel.org
 help / color / mirror / Atom feed
From: u-vpoa@aetey.se
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-8086@vger.kernel.org
Subject: Re: We have a whole new ton of goodies to investigate...
Date: Mon, 27 Apr 2015 09:06:43 +0200	[thread overview]
Message-ID: <20150427070643.GV8197@example.net> (raw)
In-Reply-To: <20150427003128.0c61965e@www.etchedpixels.co.uk>

On Mon, Apr 27, 2015 at 12:31:28AM +0100, Alan Cox wrote:
> > I wonder, if Fuzix is sufficiently portable to run on 8086, could it
> > happen to offer a possibly even more suitable foundation for a usable
> > system, than the linux-derived code in ELKS?
> 
> I'm not sure where the changeover point would be. ELKS supports
> asynchronous disk I/O properly, something FUZIX avoids. On an 8bit micro
> its pretty much pure overhead. On a PC/XT it's less clear.

My experience with again Venix/86: it came with an async XT hard disk
driver. Unfortunately this did not work with differing hd controllers,
not all computers were born equal enough.

Replacing the hd driver with a home made bios based one did not produce
any "noticeable" performance impact (i.e. never measured but never bothered).

There was not that much of parallelizable i/o and the CPU/RAM was often
the bottleneck. This can be different on faster reimplementations of *86
but the disks are now faster as well.

> ELKS is not that bloated to be honest. It's got a few areas that would
> probably save a chunk of memory if fixed but the basic architecture is
> pretty sound including basic 286 mode support.

Nice! I had an impression that it was severely constrained by the
64k limit for itself, which would make it very hard to extend the
functionality. Of course a part of the problem is the compiler
efficiency limitations.

> Some of the utilities are a bit brain-dead or buggy and might benefit
> from being pulled from elsewhere instead, and there are things lacking
> (like the real bourne shell should fit fine and is nowdays available)

Sure. Fortunately the user space is much easier to replace.

Rl


  reply	other threads:[~2015-04-27  7:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-26 21:22 We have a whole new ton of goodies to investigate u-vpoa
2015-04-26 23:31 ` Alan Cox
2015-04-27  7:06   ` u-vpoa [this message]
2015-04-27 10:53     ` Alan Cox
2015-04-27 12:30       ` u-vpoa
2015-04-27 13:35         ` Alan Cox
2015-04-27 14:44           ` u-vpoa
  -- strict thread matches above, loose matches on Subject: below --
2015-04-16 11:14 LM
2015-04-16 11:39 ` Alan Cox
2015-04-03 20:40 Alan Cox
2015-04-15 17:10 ` MFLD
2015-04-15 21:41   ` Alan Cox
2015-04-16  7:35     ` MFLD
2015-04-16 11:49       ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150427070643.GV8197@example.net \
    --to=u-vpoa@aetey.se \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-8086@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.