LKML Archive on
help / color / mirror / Atom feed
From: Thomas Hood <>
To: Alan Cox <>
Subject: Re: Linux should not set the "PnP OS" boot flag
Date: 07 Oct 2001 09:50:48 -0400	[thread overview]
Message-ID: <1002462656.831.112.camel@thanatos> (raw)
In-Reply-To: <>
In-Reply-To: <>

On Sun, 2001-10-07 at 06:02, Alan Cox wrote:
> > This change has to be permanent.  Linux should never automatically
> > set the boot flag, no matter how PnP-competent we make it.
> > The reason is that setting the flag affects what the BIOS will
> > do on the _subsequent_ boot.  But Linux can't possibly know 
> > which operating system will be booted _next time_.  This is
> > something that has to be left up to the user to control.
> When it cuts your reboot time right down then its a very useful thing to
> set.

Okay, clearly we do need the ability to set the PnP-OS flag.  But this
has to be under the user's control.  Microsoft itself says (from their
Simple Boot Flag FAQ

How does this specification solve the multi-boot scenarios?
This specification does not attempt to solve multi-boot scenarios in
which a user has several different operating systems, some Plug and
Play, some not, installed on the machine. This specification only
provides a more reliable technique for detecting the presence of these
operating systems than previously published designs.

The multi-boot problem is fundamentally intractable: the information
needed by the system BIOS in order to boot is not available until after
boot. A system BIOS would like to know whether or not a Plug and Play
operating system will be booted. If so, it will only configure devices
that are required for boot. If not, it will configure all devices it
controls. The information about which OS will be booted is not known
until the user chooses the operating system in a boot menu. To present
the boot menu, however, the system BIOS must start booting the operating
system, which means it must have already configured devices. Thus, the
situation is a catch 22. The best any design can do is provide some hint
to the system BIOS that a Plug and Play operating system is installed.
This specification does no more than that.

For these reasons it must be left up to the user to provide this

> Also remember that this is entirely configurable.

I'm not sure what you mean by 'configurable' here.  All I see is that
the code that sets the PnP-OS flag gets compiled in if one chooses
to build the PnP BIOS driver by defining CONFIG_PNPBIOS.  But having
a PnP BIOS driver (merely an interface to the PnP BIOS) is not the
same thing as "being a PnP OS".  There ought to be some way of
overriding this---of building in the PnP BIOS driver without setting
the PnP-OS flag.  One solution is to put #ifdef CONFIG_PNPOS ... #endif
around the flag-setting code and add a new choice to the configuration.

> In fact the last stage of a pnp aware bootup requires that user space
> sets the "booted ok" flag.

Yes (if you mean: clears the "Booting" flag).  This is a different
flag from the PnP-OS flag.  The PnP-OS flag is bit 0; the "Booting"
flag is bit 1.  So this is a separate issue.

But look at the code (following).  The code DOES NOT clear the "Booting"
flag.  It ONLY sets the PnP-OS flag.  Not only that: when it does so
it fails to change bit 7 in order to preserve odd parity, as the spec

static void __init sbf_bootup(void)
        u8 v = sbf_read();
                v = 0;
#if defined(CONFIG_PNPBIOS)
        /* Tell the BIOS to fast init as we are a PnP OS */
        v |= (1<<0);    /* Set PNPOS flag */

#ifdef NOT_USED
void linux_booted_ok(void)
        u8 v = sbf_read();
        v &= ~(1<<1);   /* Clear BOOTING flag */
#endif /* NOT_USED */

> > If I'm right, then bootflag.c should be modified (see my patch)
> > to remove the bit that sets the flag.  It would be nice,
> > however, if the flag could be controlled via a /proc entry.
> No need. It's all already handled

I think you'll understand why I say that it is not handled
_correctly_ and that the handling must be brought under
the user's control ... if not via a /proc entry then by
a build option or boot option.  I invite advice about this.

Please let me know if you still disagree.


  reply	other threads:[~2001-10-07 13:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-07  2:54 Thomas Hood
2001-10-07 10:02 ` Alan Cox
2001-10-07 13:50   ` Thomas Hood [this message]
2001-10-07 14:07     ` Dave Jones
2001-10-07 14:18     ` Alan Cox
2001-10-07 17:10       ` Thomas Hood
2001-10-07 21:59         ` Alan Cox
2001-10-07 17:54       ` Thomas Hood
  -- strict thread matches above, loose matches on Subject: below --
2001-10-08 12:40 Thomas Hood
2001-10-08 13:25 ` Stelian Pop
2001-10-08 22:12   ` J.D. Hood
2001-10-06  3:35 Thomas Hood
2001-10-06 19:24 ` Eric W. Biederman
2001-10-06 21:11   ` Alan Cox
2001-10-07  1:08     ` Eric W. Biederman

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:

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

  git send-email \
    --in-reply-to=1002462656.831.112.camel@thanatos \ \ \ \
    --subject='Re: Linux should not set the "PnP OS" boot flag' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).