Re: [PATCH] improve device probing heuristics

[Andrew Clausen]

Hi Andreas,

> > 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?

They use blkid!  I mean: the initscripts
call blkid_probe_all()?

> How do they know when new devices are
> added?

Good point.

> > 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;
> };

I think I prefer this interface (essentially
the same idea):

#define BLKID_GET_PRIVATE(obj, id) \
   blkid_get_private ((obj)->private_list, id)
#define BLKID_SET_PRIVATE(obj, id, data) \
  blkid_set_private ((obj)->private_list, id, data)

int blkid_alloc_private_id();

struct blkid_header*
blkid_get_private (struct blkid_header *header,
                   int id)
{
  struct blkid_header *walk;
  for (walk = header; walk; walk = walk->next) {
      if (walk->id == id)
          return walk;
  }
  return NULL;
}

You get the idea... (perhaps variables should
be renamed a bit, etc.)

> > 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.

Why?  Can't the caller invoke blkid_probe()
if it's interested?  That way, the caller
can use arbitary logic to determine how
to probe incrementally.

The "discover all names" operation should be
very cheap, so it should be reasonable to
provide a function that creates dummy entries
that can be iterated later.

> 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.

?

> > [wrt BLKID_PROBED]
> 
> 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.

sounds reasonable, except it's inconvienient
with my idea above.  (It's nice to have a
dummy device that you can call blkid_probe()
on, that becomes a full cache entry)
 
> This would not discover new devices though, and does
> not even validate
> that these devices still exist.

BTW: does this validation issue kill the idea of
incremental probing?

I think everything that changes a volume should
invalidate cache entries.  (mkfs, pvcreate & friends)
Hopefully, they're already using libblkid
to clear old signatures anyway ;)

What about removable disks?  How do they ever get
removed from the cache?

> > 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.

IIRC it does.  (But it's hard for me to check ATM)

Andrew


__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com