Re: [PATCH] improve device probing heuristics

[Andreas Dilger]

On Feb 07, 2002  05:49 -0800, Andrew Clausen wrote:
> > > Obviously, this means you have to traverse the
> > > entire cache, but don't you need to do this
> > > anyway?
> > > 
> > > (And iterating the cache should be cheap?)
> > 
> > Well, libblkid still needs a class of functions that
> > I was talking about
> > above, namely, to find all of the block devices on
> > that system.  Before
> > it has a cache, it has to have a list of devices to
> > add to the cache.
> 
> So we can't assume the cache has already been
> populated, by, say, initscripts?

And how do the initscripts know what devices are connected to a
system?  How do they know when new devices are added?

> > Yes, maybe I could add a void * (or maybe even a list, in case
> > there are multiple layers like foo->libparted->libblkid) to
> > each device struct which the calling application can use to
> > associate private data with the device.
> 
> Sounds like a good idea.  Maybe I should do the same with libparted.

Hmm, how about this:

struct blkid_header {
        list_head head;
        int magic;
};

This would be at the start of each struct (or it could hold a void *
to point to their data), and it would be up to the application
(or blkid?) to get the correct private data for their layer.

> The problem is: on input, each flag has one
> of 3 states: don't care, must-be-0, must-be-1.
> 
> So, I think code like:
> 
> for (dev = blkid_first; dev; dev = blkid_next (dev)) {
>    if (dev->flags & BLKID_REMOVABLE)
>       continue;
>    ...
> }

> Your objection is: you want to be able to control
> which device gets "deeply" probed (i.e. go hunting
> for signatures)

Well, at this level, it is only iterating through the devices
by name.  blkid would itself use this iterator to do the probing
for each device to build its cache.  The problem with the "next"
type code as opposed to callback code is that it is harder to
make the detection code run incrementally.  It will need to save
all sorts of state between calls, or do the full iteration on the
first call and only return items from the list on subsequent calls.

> Perhaps each device should have yet-another-flag:
> BLKID_PROBED
> 
> If this flag isn't set, then you have a subset of the information
> you would otherwise have available... this subset should be cheap
> to get from the OS.  (Is it easy to define such a subset?)

Well, at the lowest level I was thinking about only returning device
pathnames as a string.  A higher level would do the blkid_probe()
calls, and blkid_probe_all() would just iterate over the list of
found devices.

> There should be a function blkid_find_all() that finds all devices
> without probing them. (This should be cheap?)

Well, at one level this would just return all of the devices currently
in the blkid cache.  The current method of doing that is simply:

list_for_each(p, &cache->bic_devs) {
        blkid_dev *dev = list_entry(p, blkid_dev, bid_devs);

        ...
}

This would not discover new devices though, and does not even validate
that these devices still exist.

> > Well, I had thought there were tools/libs in the
> > installers which could give you a list of, say, 
> > disks, serial ports, etc.  Maybe their code is too
> > huge for some needs, or maybe it is dying to use
> > "the" block device iteration library, who knows.
> 
> There's kudzu, which could be worth a look...

Yes, I've heard of it, but it didn't spring to mind as something that
might be doing this already.  I'll have to take a look.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/