On Mon, Oct 19, 2015 at 9:03 AM, Joshua Judson Rosen
<[email protected]> wrote:
> On 2015-08-03 17:25, Gregory Fong wrote:
>> /sys/block will only be scanned with CONFIG_SYSFS_DEPRECATED=y and
>> deprecated sysfs enabled (using CONFIG_SYSFS_DEPRECATED_V2=y or the
>> related kernel boot param).  In that case, all of /sys/block/* will be
>> a real directory, so we don't need to follow symlinks.
>
> So, was this comment about the necessity of following /sys/block/loop*
> symlinks incorrect then? Howso?
>
>> -             /* ACTION_FOLLOWLINKS is needed since in newer kernels
>> -              * /sys/block/loop* (for example) are symlinks to dirs,
>> -              * not real directories.
>> -              * (kernel's CONFIG_SYSFS_DEPRECATED makes them real dirs,
>> -              * but we can't enforce that on users)
>> -              */

As far as I can tell, that comment is wrong in that you do not have to
and should not ever follow symlinks in /sys/block/ (you must, of
course, follow them in /sys/class/block), because there are these
possible cases:

Deprecated sysfs is enabled:
- the information will be duplicated in /sys/class/block anyway (no
negative effect but no benefit to following the symlinks)
- any symlinks followed will point to something different in
/sys/block than in /sys/class/block (results in the problem I describe
in the commit message where /dev/mtd0 is incorrect created as a block
device)
Deprecated sysfs is disabled:
- /sys/block contains real directories so it doesn't matter whether we
follow symlinks

Granted, the oldest kernel version I tested on at the time was 2.6.37
(also tested with 3.3 and 3.14).  Things may have been different
before that.

Best regards,
Gregory
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to