public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.



  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