[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1208269202.3131.3.camel@localhost.localdomain>
Date: Tue, 15 Apr 2008 09:20:02 -0500
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Dan Williams <dan.j.williams@...el.com>,
"H. Peter Anvin" <hpa@...or.com>,
Kay Sievers <kay.sievers@...y.org>,
Tejun Heo <htejun@...il.com>, Mark Lord <lkml@....ca>,
Greg KH <gregkh@...e.de>, Jens Axboe <axboe@...nel.dk>,
Jeff Garzik <jgarzik@...ox.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
IDE/ATA development list <linux-ide@...r.kernel.org>,
linux-scsi <linux-scsi@...r.kernel.org>
Subject: Re: What to do about the 2TB limit on HDIO_GETGEO ?
On Tue, 2008-04-15 at 00:18 -0700, Andrew Morton wrote:
> On Fri, 11 Apr 2008 16:25:32 -0700 "Dan Williams" <dan.j.williams@...el.com> wrote:
>
> > > It doesn't really seem to be to belong under class at all. I would suggest
> > > /sys/dev/char/ and /sys/dev/block/, for char and block respectively.
> > >
> >
> > This thread fizzled out without a patch... here goes:
> >
> > ...
> >
> > sysfs: add /sys/dev/{char,block} to lookup sysfs path by major:minor
>
> Crickets are chirping and I can't remember what the conclusion to all this
> was. In fact the thread was more than ten-deep so I probably fell asleep.
>
> I queued it up so that others cannot do the same ;)
The expressed preference was simply to expand the ioctl (or add a new
one that got the required information without having to go through the
old HDIOGETGEO path to extract the value from a fictitious geometry).
Greg was a bit sceptical of the value of the above proposal ...
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists