> Can't it be done completely in userland, using /dev/sg* and SCSI generic
> ioctls?
Yes, this is another reasonable point and approach to consider too. I thought
about this at Sun when I was doing this- I even briefly mulled over using this
as a 'requirement' to try and drive Solaris to (finally!) have a reasonable
userland scsi access. In fact, the first implementation was a simple ioctl
passthru.
The advantage of doing it as a driver semeed to be for identification and
remapping purposes, as well as possibly some critical state management. If you
remap both SAF-TE and RSM trays (those are the older Sun disk trays- they have
yet another early, incompatible, form of SES) to SES and present one
interface, it's a bit easier- the ioctl interface becomes a point of
abstraction that has some appeal. Granted a user library is fine. If you want
a kernel thread to flash the LEDs on your root disk that has gone sour, it has
some attraction. So, if you plan to have the kernel take immediate action on
SES info and respond via SES to soem event, there is that to consider.
But it's a bit of a stretch, so there is indeed quite a reasonable reason to
put it all as a user library.
-matt
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
