mdev scan

[Rob Landley]

On Friday 04 July 2008 17:07:20 Denys Vlasenko wrote:
> On Friday 04 July 2008 13:39, Holland, John wrote:
> > Hi,
> >
> > I'm having problems scanning usb_endpoint '/dev's on older kernels,
> > 2.6.13 in particular. The usb_endpoints are beyond the constant
> > MAX_SYSFS_DEPTH somewhere under /sys.
>
> How much is ok on those kernels? 4? 5?

Why is there a MAX_SYSFS_DEPTH?  PATH_MAX is 1 page (4096 bytes) and that's 
the size of the buffer I originally allocated...

> > Is there any particular reason for scanning /sys/block and /sys/class
> > separately other than to ascertain a nodes type?
>
> I guess scanning whole /sys will go into e.g. /sys/module too
> and it can be rather deep.

Looking at arbitrary parts of sysfs has no defined semantics.  There's nothing 
to say you won't find a "dev" node that isn't.

> > The first is to ignore links while traversing,
>
> Yeah, pity mdev author forgot to document why ACTION_FOLLOWLINKS
> is necessary (example would be most useful).

What's ACTION_FOLLOWLINKS?  I don't see it in the 1.10.0 util-linux/mdev.c...

> Now we need to guess whether it's real necessity or just an oversight...

I'm not quite sure what the question was here, or whether or not I'm the 
author you're referring to or somebody who's modified it since, but in 
general, recursing arbitrarily deep while following symlinks in sysfs will 
lead to endless loops on certain kernel versions.  (Specifically following 
the "device" symlink can lead to an infinite recursion on some kernels.  On 
other kernels, _everything_ under "block" and "class" is a symlink to a 
directory under devices.)

The sysfs authors consider the /sys directory to exist for udev and for no 
other purpose, and they think it's ok to force you to upgrade udev when you 
upgrade a kernel.  This is an export to userspace _without_ a documented or 
stable API.  I made it work with a big hammer, and the toybox version of mdev 
has the semantics right for the 2.6.25 kernel, last I checked.

> > the second is to drop the maximal search depth and last determine a nodes
> > type by searching for '/block/' in the first len('/class/block/')
> > characters in the resulting search path.
> >
> > A solution may however, result in longer scan times, but reduces
> > executable size and code complexity.
>
> Solution for what problem?

I'm kind of curious about that part myself...

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.