[Top][All Lists]
[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/
- [PATCH] improve device probing heuristics, Andreas Dilger, 2002/02/01
- Re: [PATCH] improve device probing heuristics, Andrew Clausen, 2002/02/06
- Re: [PATCH] improve device probing heuristics,
Andreas Dilger <=
- Re: [PATCH] improve device probing heuristics, Andrew Clausen, 2002/02/06
- Re: [PATCH] improve device probing heuristics, Andreas Dilger, 2002/02/07
- Re: [PATCH] improve device probing heuristics, Andrew Clausen, 2002/02/07
- Re: [PATCH] improve device probing heuristics, Andreas Dilger, 2002/02/08
- Re: [PATCH] improve device probing heuristics, Andrew Clausen, 2002/02/08