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

On Fri, Feb 04, 2005 at 09:44:17PM +0100, Frank van der Linden wrote:
> On Fri, Feb 04, 2005 at 06:36:08PM +0100, Reinoud Zandijk wrote:
> I see where your confusion comes from.. ioctl is wrapped in a piece of
> code which copies in/out data depending on _IOR/_IOW/_IOWR. So, the
> ioctl backend implementations (devices) don't deal with the copyin/copyou=
t.
>=20
> However, ioctl is and always has been a userspace interface.

As der Mouse pointed out (and I was about to, but his mail arrived before=
=20
I started composing this one :-), there are IOCTLs that are definitely=20
kernel-only. DIOCGPART returns pointers (in kernel space) to the struct=20
disklabel and the partition, which would have very little utility in=20
userland.

And from looking at all of the filesystem code using IOCTLs, I think=20
there's a lot of utility in letting kernel code make IOCTL calls. Having=20
just added uses of DIOCCACHESYNC, I suspect we will find more as time goes=
=20
by.

> If you want something usable from kernel space, implement a seperate
> function which can be called by both the ioctl code and your code.

My concern with this is that the device vnode may well be the abstraction=
=20
point we want to use. So that would mean adding a new device entry point=20
that will do almost the same thing as an ioctl but for kernel space. That=
=20
sounds like a duplication of effort; it seems simpler just to teach the=20
ioctl routines how to deal with kernel-level calls. AFAIK only ones that=20
store a pointer in the ioctl structure (and have their own copyin/copyout)=
=20
need adjusting. That's only a few of them.

Things like cache control, partition info, and wedge info are device
abstractions that every (appropriate) device should support, and that I
can see file systems and other kernel-level device users wanting to=20
access.

So I think the best thing to do is to come up with a clean and sane way to=
=20
make all IOCTL use kernel-able and to document it. :-)

Take care,

Bill

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

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

iD8DBQFCBAv4Wz+3JHUci9cRAm+oAJ9DYpMwurtrq0j58E9CIglVV/WE9ACeNS1/
nmXPjATMM+MHCXJDeCS6U1M=
=1QcK
-----END PGP SIGNATURE-----

--jRHKVT23PllUwdXP--