FYI, the 286pmode code pre-dates the first CVS commit from 1998-09-12
and none of the code has developer attribution. Something tells me that
there are no toes to step upon 21 years later. I'm strongly in favor of
a 286-only LOADALL-based extension, perhaps implemented as RAM-based
swap. The disadvantage would be that 8086 limits would still be in place
on a per-process basis, but the big advantage is that we won't need to
write hardware-specific disk controller drivers (and routines to
discover them!) that we don't have anyway and probably can't get
datasheets for. Protected mode requires that the OS handle all the
hardware on its own and we rely heavily on BIOS calls to do that heavy
lifting because we simply don't have the drivers in the first place,
plus most of the code is untested in protected mode anyway, so keeping
286pmode around makes very little sense to me.
-Jody
On 2/23/2019 12:00 PM, Marc-F. Lucca-Daniau wrote:
Hello all,
Github issues #207 <https://github.com/jbruchon/elks/issues/207> and
#233 <https://github.com/jbruchon/elks/issues/233> raise a somewhat
'strategic' question about the support of the 16-bit protected mode.
My proposal is to merely drop it, after considering the following pros
& cons:
Pros:
* existing code base in the repository as 'experimental'
* allow memory 1...16 MB
* intrinsic robustness
Cons:
* inconsistent code with current ELKS state
* strong architectural constraints in addition to the current i86
segmentation
* very specific to i286 processor model
* never being a success on PC market
* not suited for embedded market (big gap between 80186 softcores
and 32-bit ones)
* and last but not least, nobody to work on it
Jody already agreed the proposal, but I would like to be sure I won't
hurt any previous contributor by throwing away his code. So please
notify us in case you would disagree that simplification.
Thanks,
MFLD
