Subject: Re: CVS commit: src/sys
To: Brett Lymn <blymn@baesystems.com.au>
From: Quentin Garnier <cube@cubidou.net>
List: source-changes
Date: 05/08/2006 10:39:26
--xp5T+jWXk9cMuWlh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 08, 2006 at 01:59:17PM +0930, Brett Lymn wrote:
[...]
> > I can understand that you'd want to remove support for the old
> > HW_DISKSTATS API, but that's not a reason to close the door to any mean
> > of providing binary compatibility for older binaries.
> >=20
>=20
> My testing may have been flawed but an old iostat binary I had did
> work with a kernel containing the updated sysctl.
>=20
> I just checked the old struct disk_sysctl that was returned prior to
> my changes and the only field I added was a type field that was
> previously just a pad entry to fix up 64bit alignment.  So, the only
> difference is that the nfs mounts will now be returned as extra
> storage.

I'll have a closer look at it, but if you're actually binary compatible,
then it was even less of a reason to do that replacement.

You have 2 different kind of "old" users:  programs that look at the MIB
{ CTL_HW, CTL_HW_DISKSTATS }, and those who resolve "hw.diskstats".  I'm
not sure if there are many of the latter type, but it costs virtually
nothing to add COMPAT_30 support for them.

Of course, stuff like gkrellm will be changed to resolve "hw.iostats" and
use struct iostat in their source, anyway.

> > So please, please, have a MIB number dynamically allocated for iostats,
> > and leave HW_DISKSTATS as it was, so that maybe someone could provide
> > the necessary COMPAT_30 stub to support older binaries.
> >=20
>=20
> OK - can you point me at a sample of a dynamically allocated MIB
> number?  I will fix the code up.  The COMPAT_30 stub should just be a
> matter of filtering out the NFS storage from the returns.

Easy: s/HW_IOSTATS/CTL_CREATE/.  Then, in the userland source, you have
to use sysctlbyname(), or first sysctlmibinfo() if you need several calls
to sysctl() afterwards (although I think resolution done by sysctlbyname()
is cached at some point).

> > I haven't looked at the details of the involved struct, but it'd better
> > be COMPAT_NETBSD32-friendly or I'll be really angry :-)
> >=20
>=20
> Well, don't get angry at me :)  I didn't mess with the alignment of
> the structure.

Yes, it's fine.  One thing less to worry about.

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

--xp5T+jWXk9cMuWlh
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iQEVAwUBRF8DvtgoQloHrPnoAQL5Owf+Knh3EGpxQyM7nvOinyLKAnACEL3AgpZs
/pOXATFYBHBT+r6sJlPm+VkZO7S4CY+a+HB8ISFp2CgUSp6Lk+xpd2asetYpFwwy
mDKKM08uZqof7CaStEMMDQb9B0yv0sN1L9ydgKO9OVN+p9f9c4XGfdz9aWGHidyE
YSpyj87Ww2tz3LtIzFKD0c2E+j+4W2dtfpcrZnXcLORAfHwy5ar0ik0Vd3jwq7gI
VOL+ks6X03Xnedj0reBXVDNgC0Kz5RlOvW+NWvzFmam8CzYdz2rm+hHHL5RxeEvH
kIf7H/evJny44RRoU7iphXo0zm2VYZv5mlM32bK5T+mNchN1u3LocA==
=UGhm
-----END PGP SIGNATURE-----

--xp5T+jWXk9cMuWlh--