[lkml]   [2006]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC: ipath ioctls and their replacements
    I've been flailing away at the ioctls in our driver, with a good degree
    of success. However, one in particular is proving tricky:

    > Opening the /dev/ipath special file assigns an appropriate free
    > unit (chip) and port (context on a chip) to a user process.
    > Think of it as similar to /dev/ptmx for ttys, except there isn't
    > a devpts-like filesystem behind it. Once a process has
    > opened /dev/ipath, it needs to find out which unit and port it
    > has opened, so that it can access other attributes in /sys. To
    > do this, we provide a GETPORT ioctl.

    I still don't see how to replace this with anything else without
    performing unnatural acts.

    We use struct file's private_data to keep a pointer to the device in
    use, which works fine for ioctl.

    However, if I'm coming into the kernel over a netlink socket, I have no
    obvious way of going from my table of devices to the processes that have
    each one open, and I see no evidence that any other device driver tries
    to do anything like this either.

    Short of keeping a reference to the task_struct in the device, or
    walking the sending process's file table if we receive a netlink message
    (both of which are disgusting), I see no way to make this ioctl go away.

    Am I missing something?


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-01-25 23:35    [W:0.020 / U:4.888 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site