Messages in this thread Patch in this message | | | Date | Wed, 5 Dec 2001 22:53:46 +0100 | From | Christoph Hellwig <> | Subject | Re: gendisk list access (was: [Evms-devel] Unresolved symbols) |
| |
On Wed, Dec 05, 2001 at 02:52:59PM -0600, Kevin Corry wrote: > So one of my questions is: what is in store for the gendisk list in 2.5? > There is a comment in add_gendisk() about some part of that code going away > in 2.5 (although it's vague as to what the comment refers to),
There are two comments, first
* XXX: you should _never_ access this directly. * the only reason this is exported is source compatiblity.
over the declaration of gendisk_head - since 2.5.1-pre2 gendisk_head is static and the comment is gone.
The second is
* In 2.5 this will go away. Fix the drivers who rely on * old behaviour.
This is in add_gendisk and means that we currently work around callers trying to do add_gendisk on the same structure twice. This will go away as soon as the 'sd' driver is fixed.
> but no > corresponding comment in del_gendisk(). Are these two APIs coming or going? > I've also noticed get_start_sect() and get_nr_sects() in genhd.c in the > latest 2.5 patches. Are there any more new APIs that will be coming?
For early 2.5 the above API will remain - for mid to late 2.5 I plan to get rid of per-major gendisk completly. My design on a replacement is not yet written down, but the details are:
- the minor_shift member moves into the block queue - each block queue gets a pointer to be used for partitioning, this will be opaque to the drivers. - a per-queue 'struct gendisk' equivalent (minus the fields that aren't used) will go into above pointer. - partitions will be registered as normal block devices, to the layers outside the partitioning handling there will be no difference between a block device and a partition.
Hope this helps..
> In order for EVMS to run this list correctly during volume discovery, and to > sufficiently abstract access to the gendisk list variables, and to keep > everything SMP safe, it seems we would need APIs such as lock_gendisk_list(), > unlock_gendisk_list(), get_gendisk_first(), and get_gendisk_next(). I've > included a patch below (against 2.4.16) for genhd.c with examples of these > APIs. EVMS could then use these to lock the list, traverse the list and > process all entries, and then unlock.
This API looks really ugly to me. Did you take a look at my 'walk_gendisk' patch I sent to the evms list some time ago? (attached again).
Christoph
-- Of course it doesn't work. We've performed a software upgrade.
diff -uNr -Xdontdiff linux.shrink_icache/drivers/block/genhd.c linux.walk_gendisk/drivers/block/genhd.c --- linux.shrink_icache/drivers/block/genhd.c Wed Oct 31 12:52:32 2001 +++ linux.walk_gendisk/drivers/block/genhd.c Fri Nov 2 15:06:00 2001 @@ -121,6 +121,32 @@ EXPORT_SYMBOL(get_gendisk); +/** + * walk_gendisk - issue a command for every registered gendisk + * @walk: user-specified callback + * @data: opaque data for the callback + * + * This function walks through the gendisk chain and calls back + * into @walk for every element. + */ +int +walk_gendisk(int (*walk)(struct gendisk *, void *), void *data) +{ + struct gendisk *gp; + int error = 0; + + read_lock(&gendisk_lock); + for (gp = gendisk_head; gp; gp = gp->next) + if ((error = walk(gp, data))) + break; + read_unlock(&gendisk_lock); + + return error; +} + +EXPORT_SYMBOL(walk_gendisk); + + #ifdef CONFIG_PROC_FS int get_partition_list(char *page, char **start, off_t offset, int count) diff -uNr -Xdontdiff linux.shrink_icache/include/linux/genhd.h linux.walk_gendisk/include/linux/genhd.h --- linux.shrink_icache/include/linux/genhd.h Fri Nov 2 15:02:48 2001 +++ linux.walk_gendisk/include/linux/genhd.h Fri Nov 2 15:06:00 2001 @@ -93,6 +93,7 @@ extern void add_gendisk(struct gendisk *gp); extern void del_gendisk(struct gendisk *gp); extern struct gendisk *get_gendisk(kdev_t dev); +extern int walk_gendisk(int (*walk)(struct gendisk *, void *), void *); #endif /* __KERNEL__ */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |