[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fw: 16-bit bootloader support?

From: Robert Millan
Subject: Re: Fw: 16-bit bootloader support?
Date: Fri, 9 Oct 2009 19:55:02 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Fri, Oct 09, 2009 at 02:21:06AM +0200, Vladimir 'phcoder' Serbinenko wrote:
> Bogdan wrote:
> > The difference is basically that you have no paging, the linear address is 
> > the same as the physical address, no virtual 8086 mode, no way of going 
> > back to real mode, the segment address inside the descriptor table is 24 
> > bits wide and the limit is 16 bits wide.
> >
> > In response to Seth - there are still business and apparently research 
> > machines out there that still use the 80286. It's arguable whether one 
> > would actually need to be able to boot several OSes on such machines 
> For multi-OS on pre-386 use mbrldr (
> > but I am an example of someone who is personally interested in this. If I 
> > write support for this can it be merged into GRUB 
> Rule of a thumb is "if you do it in a way it doesn't create a
> maintenance burden then it can be merged". Due to limited usefullness
> the amount of maintenance burden I'm ok to tolerate is small. I would
> define 286 as a separate architecture with perhaps some BIOS-related and
> realmode code reusage. This way it minimises the amount of it getting in
> the way
> Due to 16-bit pointers it's still likely to get in the way of a lot of
> code. Also even before you start you have to ensure grub2 can work with
> less than 1 MiB of memory.
> In whole I would say that maintaining 16-bit compatible code is a burden
> and probably not worth if only PC 286 is considered. Additionally
> without being able to load any kernel natively grub's usefulness
> decreases. Many other modules become useless too because newer standards
> aren't supported on 286 hardware. In whole I feel like multi-OS on 286
> and 8086 niche is well filled by mbrldr.
> (but I'm not maintainer)

I have very limited interest in this.  But if there's real demand (i.e. not
just a toy) and it doesn't mean more work for us, we could accept it.

Is there a proof-of-concept patch?

Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]