Re: RFC: ipath ioctls and their replacements

[Greg KH <greg@kroah.com>]

On Wed, Jan 18, 2006 at 09:02:37PM -0800, Bryan O'Sullivan wrote:
> On Wed, 2006-01-18 at 18:57 -0800, Greg KH wrote:
> 
> > Shouldn't you just open the proper chip device and port device itself?
> > That drops one ioctl.
> 
> There isn't usually a "right" chip device and port.  On a NUMA system,
> you want to open the chip that is topologically closest to you, but
> failing that, you want to open something that will at least work.  You
> may *also* want to be able to open a specific unit/port pair, but that
> would not be the normal mode of operation.
> 
> The reason for doing this through a single open syscall, instead of
> making userland try each appropriate device in turn, is the same as
> why /dev/ptmx exists: it guarantees that userland can't do something
> stupid or racy.  The driver checks all units and ports under a single
> mutex, so it doesn't have to retry to see if something got closed behind
> its back, for example.

Ok, that's fair enough.  But if you want to do something like ptys, then
why not just have your own filesystem for this driver?

> > Why not just use mmap?  What's the special needs?
> 
> mmap just maps the hardware MMIO area into user memory.  The ioctl (or
> netlink message, or whatever it's going to be) does quite a lot more,
> such as tell the chip where user buffers are.

Ok.

> > >         UPDM_TID and FREE_TID are used for RDMA context management.
> > 
> > sysfs files.
> 
> Really?  Not netlink messages for these?  It is rightly only the process
> that has a unit/port open that should be able to modify these; can I
> enforce that through sysfs without jumping through too many hoops?

I really don't know your application enough to be sure.  If you want to
use netlink, that's fine too.

> Yes, it does.  There's such a profusion of disconnected interfaces in
> 2.6 for driver authors to get their heads around, it is a big help to
> get some directions through the thicket.

Well, for 99% of the drivers, there is no problem, as there is already a
specified and documented way to interact (like network, tty, block,
etc.)  You are just making your own type of special interface up as you
go, so the complexity is also there (this complexity would normally be
in some core code, which I am hoping that your code will turn into for
other devices of the same type, right?)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/