Messages in this thread | | | Subject | Re: Fixing the SCSI layer | Date | Sun, 5 Sep 1999 21:53:39 +0200 (MET DST) | From | list.kernel@iahastie ... |
| |
On Sun, 5 Sep 1999 tad-m2n@omoikane.co.jp wrote:
> Alan wrote: > > The code is too heavy weight. I See performance limits with the Sym= bios > > 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 lim= its the commands/second throughtput. Some latency from device (including th= e =46C card) may well be the cause.
> In addtion to the performance, I feel that not-command-oriented layer= is=20 > required, in order to: >=20 > - 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= =2E Layers + full control =3D 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 lowe= r layer, it must complete with or without error, or time out. The abort of a command can get hard to perform cleanly, depending on th= e actual state of the command you want to abort.=20
> I think that current command-oriented layer is not sufficient for con= trol=20 > all SCSI functionality.
What is a SCSI functionnality for you ? If you want all possible, you m= ust deal directly with the hardware. If you want common fuctionnalities, yo= u must interface device drivers that deal with common device models. If y= ou 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. I= t has also some design/implementation errors in my opinion.=20 =46or example, the SIM queuing (CAM3 10.4.2-10.4.3) implementation in =46reeBSD can only have race conditions on error recovery (queue freeze= ), in my opinion.=20 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 interesti= ng.
> I am not thinking too much, but I imagine below is one of choice. >=20 > step1 : implement CAM layer.
You mean CAM3. In my opinion, 1 year full time minimum + bunches of SIM= s (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.=20
> 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 file= s, > in order to leave current interfaces. >=20 > 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=E9rard.
- 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/
- 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/
| |