Re: RFC: ipath ioctls and their replacements

[Greg KH <greg@kroah.com>]

On Wed, Jan 18, 2006 at 07:49:11PM -0800, Andrew Morton wrote:
> Greg KH <greg@kroah.com> wrote:
> >
> 
> Sorry for sticking my head in a beehive, but.  Stand back and look at it:
> 
> > Shouldn't you just open the proper chip device and port device itself?
> > Why not just use mmap?  What's the special needs?
> > sysfs file.
> > Use poll.
> > Use netlink for subnet stuff.
> > Use debugfs.
> > Use the pci sysfs config files, don't duplicate existing functionality.
> > netlink or debugfs.
> 
> For a driver-bodging interface design, this is simply nutty.

One can rightfully argue that they are doing some huge messy things, and
deserve the extra mess if they persist in trying to do it.

> And it makes the driver developer learn a pile of extra stuff and it
> introduces lots of linkages everywhere and heaven knows what the driver's
> userspace interface description ends up looking like.
> 
> ioctl() would have to be pretty darn bad to be worse than all this random
> stuff.

It is.  It's giving any driver writer the ability to pretty much create
as many different and new and incompatible system calls directly into
the kernel, making their driver "just a little different" from every
other type of driver.  Do you really feel confident in allowing this?

I sure do not.

But if they use the interfaces that are present in the kernel (sysfs,
debugfs, netlink, firmware interface), their driver will automatically
work with the already-written userspace tools and their driver will
usually not contain nasty bugs that show up on 64->32bit issues, and
security problems where every user can mess with things they should not
(like lots of ioctls have been known to have in the past.)

We are trying very hard here to make it easier on both the users and the
driver writers (that's why we wrote that infrastructure in the first
place.)

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/