Vladislav Bolkhovitin wrote:
Mike Christie wrote:
But there are other cleanups like moving some of the state to per
target, cleaningup the scattlist allocation code and moving it to
scsi-ml so the SCSI ULDs can use them and convert them. There is also
thing like converting to the right APIs for 2.6 (rm kernel_thread, rm
scsi_request, rm proc, fixup class interface refcouting problems,
fixup scsi_device lack of refcounting usage, etc).
Oh yeah I think the other major issue at least I had with scst was
that it was scsi specific and we wanted try and seperate things so if
drivers like IET and vscsi are allowed then we could also do other
drivers like a ATA over ethernet target driver or allow any other
target driver that wanted to to hook in. I think you noted that we
were spererating some protocol specific things as a distadvantage or
mentioned it for some reason but I am not completely sure why and we
may not agree on that issue too.
SCSI has a lot of very specific stuff like UA handling and (at least)
some parts of task management, especially if we consider honoring NACA,
QErr, TST, UA_INTLCK_CTRL bits, therefore I'm not sure that to have
common target parts for other protocols worths complicating the
mid-layer with code and interfaces that will separate SCSI-specifics
from non-SCSI protocols. So, good luck with it :-)
I am talking about the memory allocation bits for starters. For example
the way you allocate the scatterlists and memory is useful to other
parts of the kernel not just scst. The userspace interface, if we added
the netlink parts to scst could be useful too.
-
: 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
