From: "Seewer Philippe" <philippe.seewer@bfh.ch>
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
Date: Wed, 15 Feb 2006 10:01:56 +0100 [thread overview]
Message-ID: <43F2EE04.9060500@bfh.ch> (raw)
In-Reply-To: <58cb370e0602150051w2f276banb7662394bef2c369@mail.gmail.com>
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.
next prev parent reply other threads:[~2006-02-15 9:02 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-10 13:06 RFC: disk geometry via sysfs Seewer Philippe
2006-02-13 9:56 ` Bartlomiej Zolnierkiewicz
2006-02-15 7:57 ` Seewer Philippe
2006-02-13 16:32 ` Phillip Susi
2006-02-13 19:02 ` Seewer Philippe
2006-02-13 19:22 ` linux-os (Dick Johnson)
2006-02-13 19:36 ` Phillip Susi
2006-02-14 16:35 ` Seewer Philippe
2006-02-13 19:34 ` Phillip Susi
[not found] ` <43F206E7.70601@bfh.ch>
2006-02-14 18:19 ` Phillip Susi
2006-02-15 8:39 ` Seewer Philippe
2006-02-15 8:51 ` Bartlomiej Zolnierkiewicz
2006-02-15 9:01 ` Seewer Philippe [this message]
2006-02-15 14:06 ` Alan Cox
2006-02-15 14:11 ` Seewer Philippe
2006-02-15 15:15 ` Alan Cox
2006-02-15 15:29 ` Phillip Susi
2006-02-16 8:12 ` Seewer Philippe
2006-02-16 15:36 ` Phillip Susi
2006-02-16 15:41 ` Seewer Philippe
2006-02-16 16:15 ` Phillip Susi
2006-02-15 15:20 ` Phillip Susi
2006-02-15 16:06 ` Alan Cox
2006-02-15 16:20 ` Phillip Susi
2006-02-15 17:32 ` Alan Cox
2006-02-15 18:43 ` Phillip Susi
2006-02-15 19:23 ` linux-os (Dick Johnson)
2006-02-15 20:54 ` Phillip Susi
2006-02-15 21:41 ` linux-os (Dick Johnson)
2006-02-15 22:43 ` Phillip Susi
2006-02-16 12:33 ` linux-os (Dick Johnson)
2006-02-16 15:26 ` Phillip Susi
2006-02-16 16:15 ` Seewer Philippe
2006-02-16 17:01 ` Phillip Susi
2006-02-16 16:39 ` linux-os (Dick Johnson)
2006-02-16 17:09 ` Phillip Susi
2006-02-16 19:01 ` linux-os (Dick Johnson)
2006-02-16 19:55 ` Phillip Susi
2006-02-16 8:18 ` Seewer Philippe
2006-02-16 18:14 ` Matt Domsch
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=43F2EE04.9060500@bfh.ch \
--to=philippe.seewer@bfh.ch \
--cc=bzolnier@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=psusi@cfl.rr.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox