On Wed, Aug 19, 2009 at 10:39:16PM +0200, Ingo Molnar wrote: > A general interface design question: you added a new > ioctl XFS_IOC_TRIM case. It's a sub-case of an > ugly-looking demultiplexing xfs_file_ioctl(). ioctl is per defintion a multiplexer. > What is your threshold for turning something into a > syscall? When are ioctls acceptable in your opinion? > > I'm asking this because we are facing a similar problem > with perfcounters: we need to extend the ioctl > functionality there but introducing a new syscall looks > wasteful. > > So i'm torn about the 'syscall versus ioctl' issue, i'd > like to avoid making interface design mistakes and i'd > like to solicit some opinions about this. I've attached > the perfcounters ioctl patch below. Only add a syscall if it has _one_ clear defined purpose, which has kernel-wide meaning. Do not add an syscall that is just another multiplexer without structure. Most likely it will just be even worse than sys_ioctl. Also really don't bother adding a system call that is specific to one singler driver or filesystem. Besides horrible logistics - you'd need some always built-in stub calling out to the possibly modular drivers/filesystem - it also simply doesn't make any semantical sense. I can't say I like the ioctl use in perfcounters much, but adding a special syscalls instead would be even more horrible. As for the trim support this really just was an RFC to start bringing some code into play instead of the endless masturbation about hat code that doesn't exist happens on hardware most people don't have. The interface will most ceetainly change and I hope we will have a common interface for all filesystems (or at least those that care). -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
