> Alan wrote:
> > The code is too heavy weight. I See performance limits with the Symbios
> > FC card too. In paticular the commands/second is very very limited.
As I wrote in some other mail, I doubt it is our old SCSI code that limits
the commands/second throughtput. Some latency from device (including the
FC card) may well be the cause.
> In addtion to the performance, I feel that not-command-oriented layer is
> required, in order to:
>
> - implement FC/net layer on the top of mid-layer.
> (this may include target mode driver)
Hmmm. We can imagine any kind of control when the host acts as a target.
Layers + full control = slow, in my opinion.
Perhaps something like the CAM3 "host target mode" should be enough.
> - have better sg driver (ex, abort handling, etc)
What do you want to abort ? Once a command has been passed to the lower
layer, it must complete with or without error, or time out.
The abort of a command can get hard to perform cleanly, depending on the
actual state of the command you want to abort.
> I think that current command-oriented layer is not sufficient for control
> all SCSI functionality.
What is a SCSI functionnality for you ? If you want all possible, you must
deal directly with the hardware. If you want common fuctionnalities, you
must interface device drivers that deal with common device models. If you
want to have a handle on the commands sent to a device, you must use
"passthru" services and deal with the device model (and features) by
yourself.
> As described in section 'Future Derections' of enhanced sg's manual,
> I would also like to invest CAM driver in FreeBSD.
I suggest you to invest CAM3 specifications first. The FreeBSD CAM is a
derivative and is very different from official CAM1/3 on some points. It
has also some design/implementation errors in my opinion.
For example, the SIM queuing (CAM3 10.4.2-10.4.3) implementation in
FreeBSD can only have race conditions on error recovery (queue freeze), in
my opinion.
But obviously FreeBSD CAM seems to be a far better SCSI stack that the
current Linux SCSI code and looking into it is certainly very interesting.
> I am not thinking too much, but I imagine below is one of choice.
>
> step1 : implement CAM layer.
You mean CAM3. In my opinion, 1 year full time minimum + bunches of SIMs
(low level drivers) to adapt or rewrite.
> step2 : make a 'wrapper' of low driver to the CAM layer.
Not a good idea, in my opinion. My suggestion is to allow both the CAM
stack and the old SCSI stack to be configured in the kernel, allowing
low-level drivers (SIMs) to be converted when time will allow.
> this wrapped driver is limited in functionality.
> step3 : implement CAM specific low and high layer and
> implemnt net and sg target mode layer.
> It is safer that new sd/sg layer uses different device files,
> in order to leave current interfaces.
>
> Does someone have this kind of curiousity?
I have had any kind of curiousity about SCSI.
> I would like to see if my thought is acceptable by linux hackers.
> If there is already such a plan, I hope to help it.
I don't have such a plan due to lack of time.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/