Message-ID: <43F49BF4.5090705@cfl.rr.com>
Date: Thu, 16 Feb 2006 10:36:20 -0500
From: Phillip Susi <psusi@cfl.rr.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Seewer Philippe <philippe.seewer@bfh.ch>
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>
In-Reply-To: <43F433F6.2000500@bfh.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3153
Lines: 64

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.
> 

-
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/