Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755632AbYCYNei (ORCPT ); Tue, 25 Mar 2008 09:34:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754916AbYCYNeT (ORCPT ); Tue, 25 Mar 2008 09:34:19 -0400 Received: from rtr.ca ([76.10.145.34]:4519 "EHLO mail.rtr.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754828AbYCYNeR (ORCPT ); Tue, 25 Mar 2008 09:34:17 -0400 Message-ID: <47E8FF58.8050209@rtr.ca> Date: Tue, 25 Mar 2008 09:34:16 -0400 From: Mark Lord Organization: Real-Time Remedies Inc. User-Agent: Thunderbird 2.0.0.12 (X11/20080213) MIME-Version: 1.0 To: Linus Torvalds Cc: Jens Axboe , Jeff Garzik , Tejun Heo , Greg KH l , Andrew Morton , Linux Kernel , IDE/ATA development list , linux-scsi Subject: Re: What to do about the 2TB limit on HDIO_GETGEO ? References: <47E875AD.1000901@rtr.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1619 Lines: 43 Linus Torvalds wrote: > > On Mon, 24 Mar 2008, Mark Lord wrote: >> The return value uses "unsigned long", >> which on a 32-bit system limits drive offsets to 2TB. > > One relevant question is: does anybody seriously care about the > combination of "32 bit" and "huge modern drives" any more? > > Sure, we can add a 64-bit version that ends up being used only on 32-bit > systems, but quite frankly, I think the solution here is to just ignore > the issue and see if anybody really even cares. > > Because quite frankly, the kind of people who buy modern 2TB drives > generally don't then couple them to CPU's that are five+ years old. .. Yeah. Except Dell will undoubtedly have them in desktops within 2 years, and tons of people (myself included) still use 32-bit (K)Ubuntu on our systems, simply for the better binary compatibility that it is perceived to give with things like browser plugins and stuff. Using sysfs interfaces might be a good alternative, if they were easier to use, but drives are not directly accessible there using the dev_t value from stat(2). Instead, software has to search everything inside /sys/block/ looking for a "dev" file whose contents match, rather than just trying to access something like this: /sys/block/8:1/start or /sys/block/majors/8/minors/1/start Or any one of a number of similar ways to arrange it. Cheers -- 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/