bin/148296: [zfs] [loader] [patch] Very slow probe in /usr/src/sys/boot/zfs/zfs.c

[Andriy Gapon]

The following reply was made to PR bin/148296; it has been noted by GNATS.

From: Andriy Gapon <avg at icyb.net.ua>
To: Jimmy Olgeni <olgeni at FreeBSD.org>
Cc: "Andrey V. Elsukov" <bu7cher at yandex.ru>, bug-followup at FreeBSD.org,
        Norikatsu Shigemura <nork at FreeBSD.org>
Subject: Re: bin/148296: [zfs] [loader] [patch] Very slow probe in /usr/src/sys/boot/zfs/zfs.c
Date: Tue, 27 Jul 2010 15:24:21 +0300

 on 27/07/2010 15:06 Jimmy Olgeni said the following:
 > 
 > On Mon, 26 Jul 2010, Andriy Gapon wrote:
 > 
 >> I still think that we need a method for querying partition scheme and
 >> available
 >> partitions for a disk.  Perhaps for "biosdisk" only at this point.
 > 
 > I poked around a bit...
 > 
 > If we #include "../i386/libi386/libi386.h" (which seems a bit ugly here)
 > then we can examine the partition layout using _data._gpt.gpt_nparts and
 > _data._gpt.gpt_partitions from struct open_disk:
 > 
 >   struct i386_devdesc *desc = ((struct i386_devdesc
 > *)(files[fd].f_devdata));
 > 
 >   struct open_disk *od = desc->d_kind.biosdisk.data;
 > 
 >   /* get actual partition count and types */
 > 
 > However, struct open_disk and gpt_part are local to biosdisk.c, so they
 > should probably be moved to a header.
 > 
 > Maybe struct open_disk could be moved to stand.h where struct open_file
 > already resides?
 > 
 > In that case we would only need to pull i386_devdesc from libi386.h here.
 
 Well, we could have some accessor functions that would provide the information
 rather than directly poking the internal disk structures...
 
 -- 
 Andriy Gapon