--IvGM3kKqwtniy32b
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 03, 2005 at 11:57:49AM +1100, Simon Burge wrote:
> Bill Studenmund wrote:
>=20
> > > while i agree that using sysctl for "control" interface is not
> > > perhaps the right thing, using it to export data is something
> > > that's been true for a long time and using it to remove set-id
> > > bits from various apps has been a goal of the project for a
> > > long time.  it's not just security, either - it means that ps(1)
> > > works always now, even 32 bit ps(1) 64 bit kernel.
> >=20
> > To be honest, I wish we didn't use sysctl here. I think it is an abuse =
of
> > the interface. I think there are ways we could have done the same thing
> > with other methods.
>=20
> I'm curious - why?  :)

Because it feels like the wrong tool for the job. I think sysctl is fine
for twiddling system knobs and seeing what devices are there (like how=20
some drivers tie into it).

But I think serving up binary data blobs out of the kernel isn't a good=20
fit. Obviously it works, but I still think it's a mismatch.

Someone else (forgot who, I've been hitting 'D' a lot in this thread)=20
pointed out that sysctl makes the programmer think about structured=20
objects, and that that is the main thing sysctl does for a design like=20
this. I agree. But we can achieve that differently as well. :-)

> sysctl has been used since rev 1.1 of ps(1) (well, libkvm) to retrieve
> kernel data.  _D+I Of 4.4 BSD_ says sysctl was introduced to stop kmem
> grovellers having to open /dev/kmem and read from it.  As the person who
> generalised the interface so that ps(1) is 32/64 bit clean and forever
> backward-compatible, I'm a believer that sysctl is the right way to do
> this...

In the text you didn't quote, I said that I think sysctl is better than=20
kmem groveling. So we agree on that. But just because we both agree sysctl=
=20
is better than kmem groveling does NOT mean sysctl is the best way to do=20
the job. :-)

I do like the work you did on ps. But that doesn't mean you couldn't have=
=20
done the same thing with ioctl()s on say a "/dev/kinfo" device. Include a=
=20
pointer in the ioctl structure, and the kernel can differentiate 64-bit=20
and 32-bit calls, and manage the same magic. :-)

Take care,

Bill

--IvGM3kKqwtniy32b
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDkPkjWz+3JHUci9cRAvM/AJ9CkSLcBbfXD1wHWBYRF7YGZOlwawCcCVBZ
9btklt0SQldFYHz0vTsxG2M=
=ZuZb
-----END PGP SIGNATURE-----

--IvGM3kKqwtniy32b--