linux-kernel - Re: What to do about the 2TB limit on HDIO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080325123454.4eba7644.randy.dunlap@oracle.com>
Date:	Tue, 25 Mar 2008 12:34:54 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Greg KH <gregkh@...e.de>
Cc:	Mark Lord <lkml@....ca>, "H. Peter Anvin" <hpa@...or.com>,
	Jens Axboe <axboe@...nel.dk>, Jeff Garzik <jgarzik@...ox.com>,
	Tejun Heo <htejun@...il.com>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...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, 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/