On Fri, Oct 23, 2015 at 4:52 PM, Isaac Dunham <[email protected]> wrote: > 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.
Thanks Isaac. Anyway, this is what we have: - this patch fixes a bug in mdev when using deprecated sysfs on relatively recent kernels (since 2011, i.e. 2.6.37+ and probably some earlier ones too), and we have a couple of explanations of how this is addresses the problem (mine and Mike McTernan's) - it _may_ break some things on older kernels, and I don't have the means to test this at the moment. Personally I'd rather have things working on the kernel versions that most people will be using these days, but I realize busybox's goal is to have support for kernels since 2.4. So anyone who can test and report back on what happens with this patch on kernels older than 2.6.37 would be much appreciated. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
