public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Patrick J. LoPresti" <patl@users.sourceforge.net>
To: Andrew Clausen <clausen@gnu.org>
Cc: Andries Brouwer <Andries.Brouwer@cwi.nl>,
	Steffen Winterfeldt <snwint@suse.de>,
	bug-parted@gnu.org, Thomas Fehr <fehr@suse.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] Restoring HDIO_GETGEO semantics (was: Re: workaround for BIOS / CHS stuff)
Date: 03 Jul 2004 11:00:02 -0400	[thread overview]
Message-ID: <s5goemxp2oa.fsf@patl=users.sf.net> (raw)
In-Reply-To: <20040703144500.GL630@gnu.org>

Andrew Clausen <clausen@gnu.org> writes:

> On Sat, Jul 03, 2004 at 10:15:47AM -0400, Patrick J. LoPresti wrote:
> > Parted is primarily a component of larger systems; namely, the
> > RedHat/Suse/etc. installers.  Those larger systems can figure out the
> > correct geometry (using whatever logic/heuristics/knowledge they have)
> > and pass it to the tools which need it, of which Parted is just one.
> 
> Why should they bother?  Shouldn't libparted just do it all for
> them?  (Shouldn't parted use EDD?)

Two reasons:

  1) "...of which Parted is just one."  Whatever logic you fancy for
     determining the geometry, the results need to be available to
     several tools.  Parted is only one such tool; ergo, the logic
     belongs OUTSIDE of it.  Parted should expect to be TOLD the
     geometry in any situation where it matters.

  2) The ideal logic varies depending on the capabilities of your
     kernel.  The distribution vendor knows the capabilities of its
     kernel, and can construct appropriate logic.  Putting logic into
     Parted to handle every possible kernel is a sloppy design.

I hate "smart" software.  Don't be smart; be simple.  Default to
whatever you like, but give me a way to TELL Parted the geometry.

> I was under the impression that 2.6 provides a mechanism for setting
> the HDIO_GETGEO thingy... so any program can tell Parted (and
> everything else, for that matter) what they want the geometry to be.
>
> Perhaps I misunderstood your email:
> 
> 	http://www.uwsg.iu.edu/hypermail/linux/kernel/0404.0/0270.html

You understood correctly, but see below...

> It contains this:
> 
> 	echo "bios_cyl:C bios_head:H bios_sect:S" > /proc/ide/hda/settings
> 
> Isn't the kernel the right place for this kind of communication to
> be happening, anyway?

Not according to the kernel developers.  They are threatening to
remove HDIO_GETGEO completely.

> > (Note that this would also provide a way for end users to fix their
> > partition tables if/when they broke.  Right now, the stock solution
> > for disks which Parted "broke" is "sfdisk -d | sfdisk -C# -H# -S#".
> > Wouldn't it be nice if people could use Parted instead?)
> 
> They can, right?  Just type the above, and then do some dummy thing
> in parted.  (Parted doesn't have a "touch" command).

No, because Parted will "helpfully" infer the geometry from the
existing partition table, no matter what HDIO_GETGEO returns!

In short, the /proc/ide/hdX/settings + HDIO_GETGEO solution 1) only
works on blank drives and 2) uses an interface which the kernel
developers consider a crock.

> > IBM Thinkpads use x/240/63.  In theory, other BIOSes could use
> > anything.
> 
> Do they break on x/255/63?

Yes, absolutely.  This is why I wrote the legacy_* support for the
edd.o module in the first place.  Otherwise, I could have used
x/255/63 and been done with it.

 - Pat

  reply	other threads:[~2004-07-03 15:00 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <s5gwu1mwpus.fsf@patl=users.sf.net>
2004-07-02 16:17 ` [RFC] Restoring HDIO_GETGEO semantics (was: Re: workaround for BIOS / CHS stuff) Szakacsits Szabolcs
2004-07-02 16:50   ` Andries Brouwer
2004-07-02 18:28     ` dwm
2004-07-02 21:12       ` parted maintainership Andries Brouwer
2004-07-02 17:04   ` [RFC] Restoring HDIO_GETGEO semantics (was: Re: workaround for BIOS / CHS stuff) Andries Brouwer
2004-07-02 18:12     ` Szakacsits Szabolcs
2004-07-02 18:45       ` Patrick J. LoPresti
     [not found]         ` <Pine.LNX.4.60.0407022025200.28638@hermes-1.csi.cam.ac.uk>
2004-07-02 19:57           ` Patrick J. LoPresti
2004-07-03  0:17             ` Szakacsits Szabolcs
2004-07-03  0:42               ` Bartlomiej Zolnierkiewicz
2004-07-03  0:56                 ` Andries Brouwer
2004-07-03  1:57                   ` Szakacsits Szabolcs
2004-07-03 13:59                   ` Patrick J. LoPresti
2004-07-05 12:14                   ` Restoring HDIO_GETGEO semantics for 2.6 (was: Re: [RFC] Restoring HDIO_GETGEO semantics) Szakacsits Szabolcs
2004-07-05 13:10                     ` Steffen Winterfeldt
2004-07-05 13:12                     ` Andries Brouwer
2004-07-05 13:13                     ` Bartlomiej Zolnierkiewicz
2004-07-05 14:00                       ` Andries Brouwer
2004-07-05 19:05                         ` Bartlomiej Zolnierkiewicz
2004-07-05 21:08                           ` Andries Brouwer
2004-07-05 21:52                             ` Bartlomiej Zolnierkiewicz
2004-07-06  0:17                               ` Szakacsits Szabolcs
2004-07-06  1:56                                 ` Andries Brouwer
2004-07-06 18:56                                   ` Szakacsits Szabolcs
2004-07-07  1:28                                     ` Andries Brouwer
2004-07-07 11:14                                       ` Roman Zippel
2004-07-07 11:51                                         ` Szakacsits Szabolcs
2004-07-06  8:33                                 ` Steffen Winterfeldt
2004-07-05 18:09                       ` Szakacsits Szabolcs
2004-07-05 18:58                         ` Bartlomiej Zolnierkiewicz
2004-07-03  3:00             ` [RFC] Restoring HDIO_GETGEO semantics (was: Re: workaround for BIOS / CHS stuff) Andrew Clausen
2004-07-02 23:55         ` Szakacsits Szabolcs
2004-07-03 13:56           ` Patrick J. LoPresti
2004-07-03  2:54         ` Andrew Clausen
     [not found]           ` <Pine.LNX.4.60.0407030843400.2415@hermes-1.csi.cam.ac.uk>
2004-07-03 12:44             ` Andrew Clausen
     [not found]               ` <Pine.LNX.4.60.0407031535230.6149@hermes-1.csi.cam.ac.uk>
2004-07-03 15:02                 ` Andrew Clausen
2004-07-03 14:42           ` Patrick J. LoPresti
2004-07-03  1:35   ` Andrew Clausen
2004-07-03 12:33     ` Andries Brouwer
2004-07-03 14:15     ` Patrick J. LoPresti
2004-07-03 14:45       ` Andrew Clausen
2004-07-03 15:00         ` Patrick J. LoPresti [this message]
2004-07-03 20:12         ` Andries Brouwer

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='s5goemxp2oa.fsf@patl=users.sf.net' \
    --to=patl@users.sourceforge.net \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=bug-parted@gnu.org \
    --cc=clausen@gnu.org \
    --cc=fehr@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=snwint@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox