linux-kernel - Re: [RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 & 4 testers wanted)

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:	Thu, 24 May 2007 00:35:13 +0400
From:	Michael Tokarev <mjt@....msk.ru>
To:	Greg KH <greg@...ah.com>
CC:	linux-kernel@...r.kernel.org, Kay Sievers <kay.sievers@...y.org>
Subject: Re: [RFC PATCH] /sys/block -> /sys/class/block  (Fedora 3 & 4	testers
 wanted)

Greg KH wrote:
[]
> From: Kay Sievers <kay.sievers@...y.org>
> Subject: Driver core: convert block from raw kobjects to core devices
> 
> This moves the block devices to /sys/class/block. It will create a
> flat list of all block devices, with the disks and partitions in one
> directory. For compatibility /sys/block is created and contains symlinks
> to the disks.

What's the proper way now to figure out which device type it is --
block or char?

Before, I had a function (in my udev-alike userspace app), something akin
sysfs_scan_devices(char *topdir, mode_t type), and called it twice --

  sysfs_scan_devices("/block", S_IFBLK);
  sysfs_scan_devices("/devices", S_IFCHR);

How it's supposed to work now?  (Note that it skips symlinks for obvious
reason, hence it can't find anything in /sys/block, even with the compat
"layer" in place)

(Not complaining, but asking instead)

Thanks.

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