On Fri, Oct 23, 2015 at 12:18:34AM -0700, Gregory Fong wrote: > 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.
Mdev supports kernels that are from before the old sysfs was replaced and deprecated, in the 2.6.2x era. (IIRC, the original research was done right around 2.6.21/2.6.22.) sysfs had a lot of churn in the 2.6.2x era. HTH, Isaac Dunham _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
