All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andries Brouwer <Andries.Brouwer@cwi.nl>
To: "Patrick J. LoPresti" <patl@users.sourceforge.net>
Cc: Sean Estabrooks <seanlkml@sympatico.ca>,
	szepe@pinerecords.com, Andries.Brouwer@cwi.nl,
	linux-kernel@vger.kernel.org
Subject: Re: 2.6.x partition breakage and dual booting
Date: Wed, 2 Jun 2004 01:55:05 +0200	[thread overview]
Message-ID: <20040601235505.GA23408@apps.cwi.nl> (raw)
In-Reply-To: <s5gfz9f2vok.fsf@patl=users.sf.net>

On Tue, Jun 01, 2004 at 11:10:27AM -0400, Patrick J. LoPresti wrote:

> Now, starting with 2.6.5 Linux actually invokes INT13/AH=08h during
> real-mode startup and stashes the values away.  They are available via
> Dell's EDD module.  So, to find the Windows-compatible geometry, you
> simply:
> 
>   modprobe edd
>   cat /sys/firmware/edd/int13_dev80/{legacy_heads,legacy_sectors}
> 
> (And add 1 to the "heads" value because the legacy BIOS interface is
> freaky.)

Now that we are discussing this stuff anyway:
The names chosen are really bad, they are an invitation for
confusion and bugs.

We have "sectors" and it gives a count of sectors, like 0x7280b80
(yecch - why in hex??).
But "legacy_sectors" is not a number of sectors, but a number of
sectors per track, just like "default_sectors_per_track".

We have "default_heads" and it is a number of heads, like 0xff
(yecch - why in hex??).
But "legacy_heads" is not a number of heads, it is the largest
head number, that is, one less than the number of heads.

Please, now that this is still unused, fix your names and/or
your code. Names could be legacy_max_head (etc.) if you want
to keep the values, or otherwise add 1 to the values.

Note that sectors are counted from 1 here, so by some coincidence
legacy_max_sectors_per_track is the same as legacy_sectors_per_track.

Also - people will try to match the 0x7280b80 for int13_dev83 with
the 120064896 sectors that dmesg or hdparm -g reports for /dev/hdf.
Life would be easier with values given in decimal, as they are
everywhere else.

Andries


> There is just one catch.  This assumes BIOS device 80h (the boot
> device) is the disk you care about.  If not, you need to figure out
> which BIOS device corresponds to the disk you do care about.  This is
> the hard part, but it is not THAT hard, because the /sys/firmware/edd
> interface exposes lots of information which will help you deduce this
> correspondence.

It is basically impossible, but it is easy to give heuristics
that very often work. Very good that that now is a job left
to user space.

  reply	other threads:[~2004-06-01 23:56 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-30 18:04 2.6.x partition breakage and dual booting Jeff Garzik
2004-05-30 18:36 ` Andries Brouwer
2004-05-30 18:56   ` Jeff Garzik
2004-05-30 20:03     ` Andries Brouwer
2004-05-30 20:47       ` viro
2004-05-30 21:06         ` Andries Brouwer
2004-05-30 21:08         ` Andreas Schwab
2004-05-30 21:14           ` viro
2004-05-30 21:02       ` Patrick J. LoPresti
2004-05-30 22:20         ` Andries Brouwer
     [not found]           ` <mit.lcs.mail.linux-kernel/20040530222001.GD4681@apps.cwi.nl>
2004-05-30 22:54             ` Patrick J. LoPresti
2004-05-31 18:08         ` Tomas Szepe
2004-05-31 19:19           ` Frediano Ziglio
2004-05-31 20:06           ` Patrick J. LoPresti
2004-05-31 21:03             ` Sean Estabrooks
2004-06-01 15:10               ` Patrick J. LoPresti
2004-06-01 23:55                 ` Andries Brouwer [this message]
2004-06-02 13:02                   ` Patrick J. LoPresti
2004-06-02 15:00                     ` Matt Domsch
2004-06-02 21:22                       ` [PATCH] Better names for EDD legacy_* fields Patrick J. LoPresti
2004-06-02 23:03                         ` Andries Brouwer
2004-06-02 23:38                           ` Patrick J. LoPresti
2004-06-02 23:53                       ` [PATCH] Use decimal instead of hex for EDD values Patrick J. LoPresti
2004-06-01 16:28           ` 2.6.x partition breakage and dual booting Stephen Hemminger
2004-06-03  6:51           ` Frediano Ziglio
2004-06-03 10:39             ` Andries Brouwer
2004-06-03 12:30               ` Frediano Ziglio
2004-06-03 14:35                 ` Bartlomiej Zolnierkiewicz
2004-06-03 15:11                   ` Andries Brouwer
2004-06-03 14:46               ` Patrick J. LoPresti
2004-06-03 15:32                 ` Bartlomiej Zolnierkiewicz
2004-06-03 15:55                   ` Patrick J. LoPresti
2004-05-30 19:35 ` Patrick J. LoPresti

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=20040601235505.GA23408@apps.cwi.nl \
    --to=andries.brouwer@cwi.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patl@users.sourceforge.net \
    --cc=seanlkml@sympatico.ca \
    --cc=szepe@pinerecords.com \
    /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.