bug-parted
[Top][All Lists]
Advanced

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

Re: [PATCH] improve device probing heuristics


From: Andreas Dilger
Subject: Re: [PATCH] improve device probing heuristics
Date: Wed, 6 Feb 2002 15:33:11 -0700
User-agent: Mutt/1.2.5.1i

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.

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

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.

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

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

> 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.
I wonder if the distro folks already have something to do this stuff?

> __________________________________________________
> Do You Yahoo!?

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

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




reply via email to

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