From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266156AbUGES7f (ORCPT ); Mon, 5 Jul 2004 14:59:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266163AbUGES7f (ORCPT ); Mon, 5 Jul 2004 14:59:35 -0400 Received: from mion.elka.pw.edu.pl ([194.29.160.35]:40418 "EHLO mion.elka.pw.edu.pl") by vger.kernel.org with ESMTP id S266156AbUGES7c (ORCPT ); Mon, 5 Jul 2004 14:59:32 -0400 From: Bartlomiej Zolnierkiewicz To: Andries Brouwer Subject: Re: Restoring HDIO_GETGEO semantics for 2.6 (was: Re: [RFC] Restoring HDIO_GETGEO semantics) Date: Mon, 5 Jul 2004 21:05:05 +0200 User-Agent: KMail/1.5.3 Cc: Szakacsits Szabolcs , Andries Brouwer , "Patrick J. LoPresti" , bug-parted@gnu.org, Steffen Winterfeldt , Thomas Fehr , linux-kernel@vger.kernel.org, Andrew Clausen , buytenh@gnu.org, msw@redhat.com References: <200407051513.48334.bzolnier@elka.pw.edu.pl> <20040705140044.GB24899@wsdw14.win.tue.nl> In-Reply-To: <20040705140044.GB24899@wsdw14.win.tue.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200407052105.05585.bzolnier@elka.pw.edu.pl> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Andries, the question was "What should we do with HDIO_GETGEO breakage?" not "Why does somebody need the BIOS geometry?". :-) We can fix HDIO_GETGEO to behave like in 2.4 or remove it (preferable), current situation is bad. On Monday 05 of July 2004 16:00, Andries Brouwer wrote: > On Mon, Jul 05, 2004 at 03:13:48PM +0200, Bartlomiej Zolnierkiewicz wrote: > > We can restore ide-geometry.c or try to return values obtained from > > EDD code through IDE driver. Alternatively we can add new ioctl for > > start of partition and remove HDIO_GETGEO from IDE driver completely > > but probably it is too late for this for 2.6 (we should do it early > > in 2.7 then). Andries? > > For Linux purposes geometry is almost irrelevant. > (But, as I remarked in another letter, some RAIDs need something.) > > This means as a first approximation that "geometry" is not a kernel > business. Certainly the present discussion is not about the ide-driver. > Indeed, what people want is the geometry that a certain BIOS will assign > to a disk. That depends on the BIOS, and on whether the user has > set things up with Normal / Large / LBA in the BIOS setup. > (In case the disk was left out of the BIOS setup, this particular > concept of geometry does not exist at all.) > > So, the question is whether information from the BIOS can be > exposed. Well, that is not impossible, and EDD already does this. > > Why would people want to know what a BIOS would do? > So far I have mostly seen two classes of wishes. > One is to install lots of new Windows systems on blank disks > - that is done faster and more conveniently from Linux - > where there is no partition table yet to inspect. > The other is to create or modify NTFS filesystems. > > Such are reasonable wishes, but rather special purpose. > For the time being I have good hopes that it will turn out > to be possible to do these things. Maybe using present EDD. > Maybe by extending EDD a little. > > Five years ago I wrote a library that takes collected BIOS info, > and collected Linux info, and tries to match BIOS disks with > Linux disks. Of course it is impossible to do this right, but > one can find heuristics that often work. Such heuristics do not > belong in the kernel, but a user space application can decide, > given the known situation, whether a guess is probably right, > or perhaps consult the user. > > I am awaiting the discussion with Szaka. > > Andries