DragonFly BSD
DragonFly kernel List (threaded) for 2003-11
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

ioctl() and sysctl()

From: "David P. Reese, Jr." <daver@xxxxxxxxxxxx>
Date: Wed, 12 Nov 2003 18:29:00 -0800

I'm at the point where I have to touch ioctl() and sysctl() to finish
my work on stackgap removal from the linux emulator and separation of
COMPAT_43 from the main tree.

The ioctl() syscall is emulated by in the linuxolator and involves a
stackgap allocation when servicing the LINUX_CDROMSUBCHNL ioctl().
In order to remedy the problem, I have to get rid of deep
copyin()/copyout()'s.  For example, the smb device has the following
ioctl() cmd structure:

    struct smbcmd {
            char cmd;
            int count;
            u_char slave;
            union {
                    char byte;
                    short word;

                    char *byte_ptr;
                    short *word_ptr;

                    struct {
                            short sdata;
                            short *rdata;
                    } process;
            } data;

In this case, data.byte_ptr, data.word_ptr and data.process.rdata require
a copyin()/copyout() within the smb driver itself.

In order to prevent deep copyin()/copyout()'s, the ioctl() syscall would
have to know about each structure passed in from userland, copying the
entire structure _including_ stuff pointed to by any nested pointers.
I'm not quite sure how to do this.  What's more troubling is how to
accomplish this without changing the ioctl() interface seen in userland.

For the COMPAT_43 removal, my next task is making sysctl() operate on
in kernel buffers.  There already exists a kernel_sysctl() function
that supposedly operates on in kernel buffers with an interface similar
to userland_sysctl().  Thankfully, I think I can use kernel_sysctl()
instead of completely reimplementing the sysctl() infrastructure.

If I take this route, COMPAT_43 may be completely removed from the main
tree in about a week.  In the long run, sysctl() should probably be
revamped using some sort of message passing as Matt suggested a week
or so ago.  Maybe after finishing the COMPAT_43 removal, I'll start
prototyping some sort of sysctl() replacement in userland.  I know it
will be a big project.  I just hope its not too big.

   David P. Reese, Jr.                                     daver@xxxxxxxxxxxx

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]