Date: Tue, 27 Jul 2010 12:30:04 GMT From: Andriy Gapon <avg@icyb.net.ua> To: freebsd-fs@FreeBSD.org Subject: Re: bin/148296: [zfs] [loader] [patch] Very slow probe in /usr/src/sys/boot/zfs/zfs.c Message-ID: <201007271230.o6RCU4td010099@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/148296; it has been noted by GNATS.
From: Andriy Gapon <avg@icyb.net.ua>
To: Jimmy Olgeni <olgeni@FreeBSD.org>
Cc: "Andrey V. Elsukov" <bu7cher@yandex.ru>, bug-followup@FreeBSD.org,
Norikatsu Shigemura <nork@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201007271230.o6RCU4td010099>