Messages in this thread | | | Subject | RE: How to add/drop SCSI drives from within the driver? | Date | Thu, 16 Dec 2004 11:51:28 -0500 | From | "Salyzyn, Mark" <> |
| |
Alan Cox writes:
>On Iau, 2004-12-16 at 09:54, Arjan van de Ven wrote: >> I'm strongly against adding this. The reason for that is that once an >> ioctl is added, it realistically will and can never go away. >> LSI is free to have their own fork and give that to dell; but they >> should and could have known that it wasn't going to fly. (same I guess >> for adaptec ioctls). The companies who then commit to some schedule >> realize they take a huge risk, but that is no reason to foul up the >> kernel more. > >I agree. I'd like to see an agreed standard interface for dropping and >managing physical volumes and drives, as well as a standard interface >for dropping/managing logical volumes.
Simple transactions, perhaps, but there are many checks, balances and complexities associated with a full management application that do not make sense to reside in the kernel.
Aacraid uses a FIB to communicate a wide variety of RAID management commands. Dpt_i2o uses an I2O private frame to communicate the RAID management commands.
The remaining ioctls pick up driver or OS internal information as has been discussed thus far. Moving these pieces of information to sysfs does make some sense.
However, in order to add the ability to manage the arrays, especially if they follow the complexity of the container arrangement, hotspare assignments, the multitude of array types and their configuration needs and various other RAID or Cache policies; one will find the code sucked into the driver to be a lead weight. Adding a `translation' layer from FIB, I2O and other frames to a common set is *not* going to be lightweight and will not be full coverage. The recent efforts by HP to push CSMI added 30% to the size of the driver (Adaptec Branched version). Yuck (this is a scientific term) and only added `monitoring' and 'drive passthrough' capabilities.
Array status monitoring is complicated enough to pull out into an application (the recent dropping of the firmware print messages and replacement with the aeventd application).
By all means, let's set a standard for rudimentary array manipulation, but let's not loose sight of the complicated needs of the consumers of RAID equipment. Sysfs does not look like it will scale well towards a full up management interface.
Sincerely -- Mark Salyzyn - 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/
| |