thread-index: AcYyDnhEyIuCt3h+SSaHW4BYvb1IIw==
Content-Class: urn:content-classes:message
Importance: normal
Message-ID: <43F2EE04.9060500@bfh.ch>
Date: Wed, 15 Feb 2006 10:01:56 +0100
From: "Seewer Philippe" <philippe.seewer@bfh.ch>
Organization: BFH
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050811)
MIME-Version: 1.0
To: "Bartlomiej Zolnierkiewicz" <bzolnier@gmail.com>
Cc: "Phillip Susi" <psusi@cfl.rr.com>, <linux-kernel@vger.kernel.org>
Subject: Re: RFC: disk geometry via sysfs
References: <43EC8FBA.1080307@bfh.ch> <43F0B484.3060603@cfl.rr.com> <43F0D7AD.8050909@bfh.ch> <43F0DF32.8060709@cfl.rr.com> <43F206E7.70601@bfh.ch> <43F21F21.1010509@cfl.rr.com> <43F2E8BA.90001@bfh.ch> <58cb370e0602150051w2f276banb7662394bef2c369@mail.gmail.com>
In-Reply-To: <58cb370e0602150051w2f276banb7662394bef2c369@mail.gmail.com>
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2776
Lines: 64


Bartlomiej Zolnierkiewicz wrote:
> On 2/15/06, Seewer Philippe <philippe.seewer@bfh.ch> wrote:
>>
>>Hi Phillip
>>
>>I'd like to close this discussion if possible.
>>
>>I think we both know that disk geometry is a fiction and except for a
>>few "older" devices which still need support, Linux couldn't care less
>>about it (and in an ideal world this would include myself).
>>
>>On the other hand, at least in the x86 world, we must live with the fact
>>that there are other os around, which, as you so aptly put, aren't sane.
>>In order to work with them and if necessary to fix things, geometry
>>information is necessary. One part is the bios geometry, available
>>through edd or other means. The other part is the geometry the kernel
>>exports (whatever sane values it contains or where they come from).
>>
>>Both are necessary for debugging and fixing. And sometimes it actually
>>makes sense to overwrite the kernel with values that are "compatible".
>>Whether gleaned from the bios via edd or computed by hand does not
>>matter as long as the user has to it by himself. I've given a few
>>examples for this, others can be found by googling (For example the ide
>>disk geometry rewrite for http://unattended.sourceforge.net).
>>
>>I completely agree with all that the kernel should never try to report
>>bios geometry for a disk unless absolutely necessary and should not
>>attempt to fix things automagically.
>>
>>But, as long as the Linux kernel does something with disk geometry, and
>>this could mean just returning some bogus values, it makes sense to
>>export these values read/write in sysfs. Because we all know, sysfs is
>>much easier to handle than say for example ioctls.
> 
> 
> This made me thinking - if all the kernel does is returning some bogus
> values and we need to fix applications to use sysfs interface why not
> instead just fix applications to not use ioctl interface?
> 
> Bartlomiej

Good point (and the one I was afraid of coming up).

This would mean dropping the HDIO_GETGEO ioctl completely and force
applications such as fdisk/sfdisk and even dosemu to determine disk
geometry for themselves. Which I think actually would be the most
correct approach.

But this would come to a similar situation as in the beginnings of 2.6
when we had partitioning problems because bios geometry support was
dropped.

That's something I don't have the guts to decide (and luckily can't), so
I'd rather go with sysfs and provide a means to be as compatible as
possible without doing anything automagically.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/