Thread-Index: AcYzD2lbInBQq2MqQ6KYHOcjVHpUdw==
Content-class: urn:content-classes:message
Importance: normal
Message-ID: <43F49D16.6060801@bfh.ch>
Date: Thu, 16 Feb 2006 16:41:10 +0100
From: "Seewer Philippe" <philippe.seewer@bfh.ch>
Organization: BFH
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050811)
MIME-Version: 1.0
To: "Phillip Susi" <psusi@cfl.rr.com>
Cc: "Alan Cox" <alan@lxorguk.ukuu.org.uk>,
       "Bartlomiej Zolnierkiewicz" <bzolnier@gmail.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> <43F433F6.2000500@bfh.ch> <43F49BF4.5090705@cfl.rr.com>
In-Reply-To: <43F49BF4.5090705@cfl.rr.com>
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3360
Lines: 70


Phillip Susi wrote:
> Seewer Philippe wrote:
> 
>> Thats the problem point here. As of 2.6 the kernel does no longer know
>> anything about bios geometry. The exception here might be for older
>> drives which do not support lba, where the physical geometry is the one
>> the bios reports (if not configured diffently).
>>
>> This is, as we all know, intentional. Because it's quite impossible to
>> always and accurately match bios disk information to drives reported by
>> drivers.
>>
> 
> If it is intentional that the kernel not keep track of the bios
> geometry, then it should not track geometry at all.  The only reason for
> the existence of GETGEO is so partitioning tools can figure out what to
> put in the MBR for the disk geometry.  If they do not get the values
> that the bios reports, then they are getting useless information.
> 
> Why give the illusion that they got the right information when you are
> just lieing to them?  Wouldn't it be better to fail the request so the
> tool knows it can't get the right info from the system?
> 
>> Not only windows but other os as well.
>>
>> The problem here is a general interface problem. Tools want one
>> interface (be it ioctl or sysfs). If they can depend on a kernel
>> interface only partially and have to determine values themeself
>> otherwise, that interface should be dropped. Again i'm talking about the
>> interface, not actual code which might still depend on c/h/s.
>>
> 
> Exactly, the interface should be completely dropped since it really is
> useless to the tools anyhow without accurate information from the bios.
> 
>> On the other hand, if we keep that interface (or perhaps ioctl for
>> compatibility and sysfs for newer things) and introduce a means to tell
>> the driver via userspace what we want, many things can be solved. For
>> example for older drives which need chs, userspace can tell the driver
>> what the bios uses if values differ. For other implementations which
>> return defaults which are correct in 80% of all cases, the other 20% can
>> be overridden.
>>
> 
> That is true, but since the kernel doesn't use this information, it
> amounts to holding onto a user space configuration parameter.  Since
> it's just a user space configuration parameter, shouldn't that go in a
> conf file in /etc or something, rather than burdening the kernel with
> that information?  And since the kernel won't remember the settings
> across boots, then you're going to end up with them stored in a conf
> file anyhow with a boot time script that copies it to the kernel, so
> that fdisk can read it back from the kernel later.  Since you likely
> will only partition a drive when installing, is there even a need to
> store it at all, let alone in the kernel?  Just let fdisk ask the user
> or choose defaults.
> 
>> It's of course not really the kernel's responsability to fix things (or
>> better allow the user to fix things) not important to Linux, but i think
>> for the sake of compatility necessary.
>>
> 
The problem does not end with fdisk. There are tons of tools (sfdisk,
parted, dosemu, ...) which would be affected.
-
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/