Re: Misremembered (was: Re: Stupid question)
On Tue 15 Feb 2022 at 19:28:48 (+0100), Andrei POPESCU wrote:
> On Lu, 14 feb 22, 17:23:52, David Wright wrote:
> > > On 2/14/2022 10:19 AM, Bijan Soleymani wrote:
> > > >
> > > > Not sure about the Debian installer (except that it does boot and
> > > > run Linux, but not sure it ever switches to another kernel
> > > > midway), but the Grub bootloader is kind of a mini-OS, in that it
> > > > can read files from filesystems (rather than some other
> > > > bootloaders that read from specific sectors/blocks of a disk).
> >
> > I think that confuses the issue. Grub is just a program, not an OS.
> > It can run commands from a shell, and it can load lots of drivers,
> > but that doesn't even qualify it as a single-user OS.
>
> Well, without digging too much into it GRUB seems to be almost as
> capable as DOS ;)
>
> > It's technically correct to say that Grub is designed with a "kernel"
> > and modules, but that's mainly a way of saving space in the final
> > product, by having as little excess code included as possible.
>
> As far as I recall there is a very strict limit for the first stage,
> because it has to fit in the MBR.
It's a very strict limit but, in another sense, very generous,
seeing that its code barely consists of more than Jump To Sector N.
When you embed Grub's core image in the "MBR Gap" (IMO the second
safest place), that's where the size constraints kick in. On my
old MBR laptop, it has less than 32KB space. (For comparison,
│ io.sys │ 40774│May 31 1994│
│ msdos.sys │ 38138│May 31 1994│
│ command.com │ 54645│May 31 1994│
for DOS 6.22, before you start adding any drivers.)
One of the reasons I converted all my drives to GPT (bar said
laptop's) was the BIOS Boot partition, which must be the safest
place for Grub's core image.
> > There's no concept of kernel- and user-space. They could have as
> > easily named the kernel.img "trunk.img", and core.img "body.img",
> > to illustrate how Grub is agglomerated.
>
> However, GRUB's capabilities are heavily influenced by what modules are
> available and loaded (as you mention below with the 'normal' module),
> and anyway, an OS isn't defined by having kernel- and user-space.
I wasn't trying to define an OS, but just correcting the post that
drew a false equivalence between something called "Grub's kernel"
and the linux kernel.
> On the other hand it can't run *other* programs within it's environment
> (scripts in it's own scripting language don't count). When it loads a
> kernel or chain-loads another boot-loader it basically hands over
> control completely, so maybe this is the distinguishing limitation
> compared to a "real" OS.
I think an OS has to have something to manage, ie other programs,
and "manage" has to mean more than one function like loading
a program. Generally a computer system's "product" comes from
the programs that the OS manages, and not from the OS itself,
which usually produces nothing at all.
Cheers,
David.
Reply to: