Re: [PATCH] improve device probing heuristics

[Andrew Clausen]

Hi Andreas,

--- Andreas Dilger <address@hidden> wrote:
> On Feb 06, 2002  09:44 -0800, Andrew Clausen wrote:
> > Your patch looks sane, but I think this is getting
> out of hand.
> > 
> > In 2.5.x, can we have something like
> /dev/block-devices/*, which
> > are symlinks back into /dev/ide/...?
> 
> Well, if you have devfs, I _think_ you will find the
> disks under
> /dev/discs/some/long/path.  I don't think you can
> reasonably expect
> devfs to be available on many systems.

I have no idea... I'm on someone else's slackware
system that crashes once every 2 hours (on average),
my server in .au is down, the slackware machine
doesn't have auto*, devfs, etc...

Apart from that, I'm enjoying my holidays :)
I met a girl... (actually, the story doesn't
get much more Interesting than that, due to
family politics...);

> > Or perhaps we should be using your libblkid?  (the
> /dev approach isn't
> > suitable for iSCSI, for example...)
> 
> Well, I had considered this also.  In fact, I might
> make a separate
> file (lib?) which is only concerned with iterating
> whole block devices
> and/or partitions.  I think this is used in many
> places, so it might
> be a benefit to keep this separable from blkid as a
> whole.

I'm not sure... one important feature of blkid
is it creates a single identity for a device,
even if it has multiple addresses.

Parted needs to deal with how devices are
addressed.  ("Which disk did you want to
partition, exactly?")  So, I think it makes no
sense to separate blkid.

OTOH, both libparted and libblkid have
an abstraction of what a "device" is.
This seems fairly important.  (For example,
libext2fs also has one... the io channel
thing)

Perhaps liblkid should provide a standard
that everyone can use?

In other words, maybe libparted/device.c,
libparted/linux.c, libparted/gnu.c should
be part of libblkid?

Dunno... I'm still rather confused about
how everything should be...

> Basically, you would want something like:
> 
> int blkid_iterate_devname(blkid_cache *cache,
>                         int (fn *)(char *devname, long flags, void
> *private), 
>                         long flags, void *private);
> 
> and it calls (*fn) for each disk/partition that it
> detects, passes the
> application private data through, and flags.

Either that, or a "get_next" function...

BTW: will we need fancy data structures for
big systems?

> For input flags, I see:
> 
> BLKID_ITER_DISK  - call fn for whole disk devices
> (flag to fn also)
> BLKID_ITER_PART  - call fn for partitions (flag to
> fn also)
> BLKID_ITER_FULL  - don't get fancy with trying to
> probe a reduced set of
>                    apparently available devices
> (e.g. don't use the
>                    /proc/partitions or /devfs/discs
> data), but do a
>                    probe of all devices that we know
> to look for
> BLKID_ITER_CACHE - call fn for devices listed in the
> blkid cache even
>                    if they are not found via regular
> probe

I think I prefer the following:
* each device has a bit-field of:
   - BLKID_PHYSICAL   (or BLKID_LOWLEVEL)
   - BLKID_STALE   (entry invalidated?)
   - BLKID_REMOVABLE
   etc.
* the function fn can do an "if" to exclude
items from the traversal.

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

> I need the blkid_cache parameter only to support the
> last flag.  The
> question also arises on whether we would want to
> allow specifying
> iteration over a subset of devices (e.g. only IDE,
> SCSI, (specific?) RAID)?

This is another field...?

(dev->bus?)

> I do not currently have iteration functions for all
> of the structs
> which I export via libblkid, but looking at
> libparted has really shown
> me that I need to do that.

In the end, you need it because the user
wants to see a list of devices, and click
on the one she wants.

>  The current interface is
> "list_for_each()",
> and the assumption that the struct list_head will
> never move.
> 
> I have also considered having accessor functions for
> each data field
> in each struct, so it hides struct internals from
> the applications,
> but that is a lot of work to code...

Does this ever gain you anything?
I think it boils down to: 'How "internal" are
the internals?'.  If the internals are so
internal that you need to hide them, you
probably got the ontology ("being") of the
object wrong.  i.e. the wrong fields in the
struct.

> > However, there are a few differences.  We are only
> interested in
> > "low-level" devices.  Perhaps liblkid can keep a
> flag, and provide
> > some nice interface for finding low-level devices?
> 
> Yes, I would call the "low-level" devices as
> whole-disk or unpartitioned
> devices.  You would probably want to ignore MD
> devices and loop, while
> others might not.  Likewise with CDROMs.  Argh, this
> is getting big.

Indeed.

> I wonder if the distro folks already have something
> to do this stuff?

The distro folks use libparted's list *grin*.
(which is how the code got so complicated in
the first place)

> Eeek.  You _do_ have mail problems, don't you ;-)...

:(  I could redirect my .gnu.org mail spool,
just I subscribe directly to most things
address@hidden I could also
download from there, but that leaves a mess
to sort out later.  (Probably not too hard...
and worth doing if I'm going to be without
a server for a week).  OTOH, since I'm having
plenty of problems at this end also, and I'm
going to Sao Paulo soon...

Andrew



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