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: <47E99EBE.7010708@gmail.com>
Date:	Wed, 26 Mar 2008 09:54:22 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Mark Lord <lkml@....ca>
CC:	Greg KH <gregkh@...e.de>, "H. Peter Anvin" <hpa@...or.com>,
	Jens Axboe <axboe@...nel.dk>, Jeff Garzik <jgarzik@...ox.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 ?

Hello,

Mark Lord wrote:
> So have we.  sysfs is a total nightmare to extract information from
> under program / script control.  The idea presented in this thread,
> is to have it cross-index the contents with a method that actually
> makes it easy to access in many common scenarios, without requiring
> huge gobs of code in user space.  Or in kernel space.
> 
> And it's not just a few 10s of lines of code currently,
> but rather about 80-100 lines just to find the correct device subdir,
> and *then* a few more 10s of lines of code to retrieve the value.
> 
> In a bulletproof fashion, that is.  Sure it can be slightly smaller
> if niceties such as error checking/handling are omitted.
> 
> There's no guarantee that udev is present, and even if it were present,
> there's no guarantee that the names in /dev/ will match /sysfs/ pathnames,
> since udev is very configurable to do otherwise.
> 
> So lookups are by dev_t, which sysfs has no simple or even easy way
> of accomplishing.  O(n) at a minimum.
> 
> If we make it easier to access, then more programs will use it
> rather than us having to expand our tricky binary ioctl interfaces.
> 
> Isn't that part of the idea of sysfs -- to limit the need for new ioctls ?

The questions are...

1. Are we gonna push sysfs as the primary interface and not provide an
alternative interface (ioctl here) which can provide equivalent
information?  There are people running their systems w/o sysfs but I
think we're getting closer to this everyday.

2. Is udev an essential part of all systems?  I'm not sure about this
one.  Lots of small machines run w/o udev and I think udev is a bit too
high level to depend on for every system.

If both #1 and #2 are true, I agree with Mark that we need an easy to
map from device number to matching sysfs nodes.  Tools which are used
early during boot and emergency sessions need this mapping and many of
them are minimal C program w/o much dependency for a good reason.
Requiring each of them to implement their own way to map device node to
sysfs node is too awkward.

Probably something like /sys/class/block/MAJ:MIN or
/sys/class/devnums/bMAJ:MIN?

-- 
tejun
--
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/