On Wed, Aug 19, 2009 at 3:15 PM, adam radford<aradford@xxxxxxxxx> wrote: > Linus, > > There seem to be quite a few new SCSI drivers being submitted to the > Linux kernel where the driver > authors have tried to implement a management interface ioctl(), only > to have it bounced out, without a > clear explanation of why it was not allowed. There are often ramblings > about how it is 'hard to tell which ioctl crashed the system', etc. > > We have some custom ioctl interfaces in the 3w-9xxx and 3w-xxxx SCSI > drivers used by the open source > 'smartmontools' package to read smart data from the individual DISKS > underneath a RAID array. > > When we submit new driver support for our 6GB SAS-RAID card, a driver > with this (already tried and tested) interface apparently won't > be accepted. > > Should we re-write large parts of smartmontools (that are already > working and rock solid) to use a new > sysfs interface? Is that really going to make it somehow 'better' or > more secure? Isn't the whole point of sysfs 'one value per file' ? > We have a binary interface that sends back data, and bolting this onto > sysfs somehow doesn't seem like the right approach. > > Creating a dummy 'processor' device within the driver so we can take > scsi passthrough, ata passthrough, and other binary data commands > through /dev/sgX when there are no disks present on a RAID array seems > like a gigantic hack. Processor devices are usually enclosures. > > I would like to open a discussion of this whole business of "NO NEW > IOCTLS". I can see Greg KH, and others bouncing out drivers that > contain ioctl interfaces, and I see some of the biggest SCSI HBA > vendors asking what interface they should use and being told netlink, > sysfs, etc. > > What are the functional and security benefits of using SYSFS > (sysfs_create_bin_file()), and re-writing open source userspace > management software (like smartmontools) that already uses existing > ioctls in drivers VS. accepting new ioctls and enforcing > CAP_SYS_ADMIN(), ioctl numbering from Documentaiton/ioctl-number.txt > and some "__user" compiler annotations for safety? > > Will we be changing even 'fdisk' to not call BLKSSZGET, BLKRRPART, > etc in the future since 'ioctls are bad', or is the Linux kernel/scsi > community forcing these rules on driver writers only? > > -Adam > James, Christoph, Do you guys have any comments on this? -Adam -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
