Re: NFSD status.
>>>>> 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 <gord@fig.org> //\ I'm a FIG (http://www.fig.org/)
Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
Reply to: