[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] improve device probing heuristics

From: Andrew Clausen
Subject: Re: [PATCH] improve device probing heuristics
Date: Fri, 8 Feb 2002 08:38:04 -0800 (PST)

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)


Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]