[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)
Andrew
__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com