Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759166AbYCYTf7 (ORCPT ); Tue, 25 Mar 2008 15:35:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755674AbYCYTft (ORCPT ); Tue, 25 Mar 2008 15:35:49 -0400 Received: from agminet01.oracle.com ([141.146.126.228]:43715 "EHLO agminet01.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754060AbYCYTfs (ORCPT ); Tue, 25 Mar 2008 15:35:48 -0400 Date: Tue, 25 Mar 2008 12:34:54 -0700 From: Randy Dunlap To: Greg KH Cc: Mark Lord , "H. Peter Anvin" , Jens Axboe , Jeff Garzik , Tejun Heo , Linus Torvalds , Andrew Morton , Linux Kernel , IDE/ATA development list , linux-scsi Subject: Re: What to do about the 2TB limit on HDIO_GETGEO ? Message-Id: <20080325123454.4eba7644.randy.dunlap@oracle.com> In-Reply-To: <20080325192515.GA24234@suse.de> References: <47E875AD.1000901@rtr.ca> <47E87942.2020409@rtr.ca> <47E88A13.70808@zytor.com> <47E90019.3050006@rtr.ca> <47E90458.7030801@zytor.com> <47E9383F.3050908@rtr.ca> <20080325192515.GA24234@suse.de> Organization: Oracle Linux Eng. X-Mailer: Sylpheed 2.4.7 (GTK+ 2.8.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2070 Lines: 59 On Tue, 25 Mar 2008 12:25:15 -0700 Greg KH wrote: > On Tue, Mar 25, 2008 at 01:37:03PM -0400, Mark Lord wrote: > > H. Peter Anvin wrote: > >> Mark Lord wrote: > >>> > >>> Yeah, that would be just as good, really. Maybe even better. > >>> > >>> Mark Lord wrote (later on): > >>>> 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. > >>> .. > >> It shouldn't be under /sys/block... there are enough many things that scan > >> /sys/block and assume any directory underneath it has the current format. > > .. > > > > So long as we only add things, and not remove them, then any software > > that scans /sys/block/ shouldn't care, really. > > > > But yes, it could go elsewhere, too. > > Perhaps a /sys/dev/ directory, populated with symbolic links > > (or hard links?) back to the /sys/block/ entries, something like this: > > > > /sys/dev/block/8:0 -> ../../../block/sda > > /sys/dev/block/8:1 -> ../../../block/sda/sda1 > > /sys/dev/block/8:2 -> ../../../block/sda/sda2 > > ... > > > > That's just a suggestion, really. > > And what about character devices? > > > > Perhaps Greg will chime in. > > I've been waiting to see if sanity will take hold of anyone here. > > Come on people, adding symlinks for device major:minor numbers in sysfs > to save a few 10s of lines of userspace code? Can things get sillier? > > You can add a single udev rule to probably build these in a tree in /dev > if you really need such a thing... > > And what's wrong with your new ioctl recomendation? Ah, there's some sanity. :) --- ~Randy -- 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/