--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 15, 2005 at 04:09:12AM -0500, der Mouse wrote:
> > ioctls should either sleep or not sleep.  I do not think the behavior
> > of a given ioctl should change depending on the calling context.
>=20
> Well, whether I agree depends on whether you count using copyout versus
> bcopy counts as changing the behaviour.

I don't. While which address space to use is an important point, it can be=
=20
relegated to the copy routine. Remember that only pointers in the original=
=20
ioctl parameters need this treatment. Everything else already is in kernel=
=20
space. :-)

> Actually, even that aside, I'm not sure I agree.  For example, if the
> ioctl has to malloc something, it may want to use M_WAITOK when called
> by userland and M_NOWAIT if called by someone that can't sleep.  (Of
> course, it currently doesn't have any good way to tell whether it's
> called by a can't-sleep context, but all that means is that a certain
> thing which is relatively reasonable can't be done at present.)

I think that such a behavior would make it very hard to audit code.=20
Auditors would have to keep in mind exactly what context the call is in to=
=20
know what will happen.

> > If we need a sleeping and a non-sleeping variant, we should have two
> > calls. :-)
>=20
> When they share all their code except for, say, a flag bit for malloc,
> I have to wonder if the code duplication is worth it.

If that's all it is, then you just make two cases in the switch statement=
=20
use the same code, and add a test just before a malloc call. You don't=20
have to duplicate much.

Realistically, though, what really needs this? AFAICT ioctl calls are, by=
=20
design, things that can be done in interrupt context or they aren't. I=20
don't really see the need for the morphism you describe.

And if we ever need such morphism, we can explicitly document it in the=20
call's description.

Take care,

Bill

--0F1p//8PRICkK4MW
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCE5ctWz+3JHUci9cRAooIAJ9xl7kD2VUd3YGcins1b6ytIFhTWQCdETcd
LGz3pZljU+ij9lZZMXo8X1s=
=LVl8
-----END PGP SIGNATURE-----

--0F1p//8PRICkK4MW--