linux-kernel - Re: [PATCH] sysfs: add /sys/dev/{char, block} to lookup sysfs path by major:minor

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]

Date:	Mon, 14 Apr 2008 10:00:46 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Dan Williams <dan.j.williams@...el.com>
CC:	gregkh@...e.de, linux-kernel@...r.kernel.org, kay.sievers@...y.org,
	neilb@...e.de, htejun@...il.com, lkml@....ca
Subject: Re: [PATCH] sysfs: add /sys/dev/{char,	block} to lookup sysfs path
 by major:minor

Dan Williams wrote:
> 
> What are the alternatives?:
> 1/ Add an ioctl to return the path: Doable, but sysfs is meant to reduce
>    the need to proliferate ioctl interfaces into the kernel, so this
>    seems counter productive.
> 
> 2/ Use udev to create these symlinks: Also doable, but it adds a
>    udev dependency to utilities that might be running in a limited
>    environment like an initramfs.
> 

3, of course, is what applications have to do today, which is to do a 
full-tree search of sysfs.

Given that this appears to be fairly little code it would make sense to 
me; one could argue if /sys/dev/block/8/32 would be better than 
/sys/dev/block/8:32, but (a) I don't think it matters and (b) the 
non-atomicity of the former would

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