Re: [CFC/CFT] large changes in the loader(8) code
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF2E5F3064C6DDEFA89A2B846
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
On 16.07.2012 14:23, Andriy Gapon wrote:
> on 26/06/2012 15:50 Andrey V. Elsukov said the following:
>> 3. ZFS code now uses new API and probing on the systems with many disk=
s
>> should be greatly increased:
>> zfs/zfs.c
>> i386/loader/main.c
>=20
> First of all, it's hard to parse the above sentence. "probing ... shoul=
d be
> greatly increased". Probing what? :-) If probing time, then we don't =
want that ;-)
>=20
> I looked through the ZFS-related part and here are a few comments:
Thanks for that.
> 1. I think that the predominant indentation style of i386/loader/main.c=
should be
> preserved for consistency.
>=20
> 2. I am not sure if I like the approach of moving partition tasting cod=
e into
> common ZFS code (zfs.c). On one hand, it now makes sense because the n=
ew
> partition iteration code is machine-independent. On the other hand, th=
e reason
> that I added arch_zfs_probe method was to give platforms full control o=
ver which
> partitions and in what order are probed. It seems to be important for =
some of them.
> So, I like how your new partition interface makes it much easier to ZFS=
-probe
> partitions, but I would prefer to have that code in arch_zfs_probe impl=
ementations
> rather than in zfs_probe_dev.
=46rom the other point of view, ZFS is not a just file system and it work=
s
directly with disks and partitions. And it seems to me this code will be =
common
for other architectures.
> 3. Related to the above. In what shape is sparc64 ZFS support in your=
branch?
> Have you tried to adapt it to the new model too?
> It's the platform that has special requirements for disk/partition prob=
ing order.
> Marius can help with additional information and testing here.
Currently i have not received any feedback reports from the users who can=
test
patches on the other architectures. I added VTOC8 support to the part.c, =
but it
seems it is not needed and ofw can work without this.
--=20
WBR, Andrey V. Elsukov
--------------enigF2E5F3064C6DDEFA89A2B846
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
iQEcBAEBAgAGBQJQA/OiAAoJEAHF6gQQyKF6REAH/A2waKFDxiljXNm+liofAd9Q
GaIpYj+jNAIKMHHMLIdY2vM5HTQ61wIMHD7d83/uUekhBCAb/tqhhGelZn224O9j
bHGPhW+YY36RVf2qs7QzX+ldSuHWq3B8MXzh5zzy71Znd4XzPfPudRqIynHLE5Jj
04OQNWjIgvTQqOJxIZwIT03vnKICRo2DWPWtxY0njMklBVoNfDMhyLwW2UBGjXfF
sx4qks45aL+hc+uuZTJoRf/RwWRDk2srs9LtYAWr6B2Mez6JbyaOR5FwUmYNmDK1
7/AAF621+QFxZHlcUsrPW2hxugIBB49/6IkHEfxP19Oap8cj5edUucP1zxqI4B4=
=80zQ
-----END PGP SIGNATURE-----
--------------enigF2E5F3064C6DDEFA89A2B846--
討論串 (同標題文章)
完整討論串 (本文為第 57 之 62 篇)：