>>>>> Bill White writes: RM> :-) Well, keep learning! Next you will find out that the kernel RM> has nothing whatsoever to do with ioctls.
BW> Ok, so my interest is piqued. You use ioctls to control devices, BW> logical or physical, right? There's no art to find the ioctl's construction in the Mach. ;) To use Roland's words, I'll attempt to pull an answer out of my arse, because I'm learning too, and it'll give me a chance to try verbalizing my knowledge. An ioctl sent to a file descriptor is the Unix approximation of an RPC sent to a Mach device port. Ioctls are all part of the Unixoid layer of abstraction, which means they're implemented by the GNU C library, not the Hurd servers or Mach microkernel. libc/sysdeps/mach/hurd/ioctl.c is where the `ioctl' function is defined. Try following its execution. libc/hurd/hurd/ioctl.h declares the data structures and libc/hurd/hurdioctl.c implements the framework for ioctls that can be handled internally by the C library (i.e. aren't really device driver requests). How did I know this? I already knew that libc/sysdeps/mach/hurd and libc/hurd are generally the places to look when you want to start understanding how a C library call is implemented on the Hurd, so I just looked for files named '*ioctl*' in those directories. BW> My obvious conjecture is that you can put the lower half of the BW> DD in the kernel, the upper half in a task, and, if you are very BW> careful and the wind is right, you can transfer data up and down BW> without copying it. Nothing nearly that complicated... Roland's just reminding you that file descriptors and ioctls are unixisms, and to grok the Hurd, you have to remember the abstractions it's built on, in this case, ports and RPC. -- Gordon Matzigkeit <[EMAIL PROTECTED]> //\ I'm a FIG (http://www.fig.org/) Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
