Re: [RFC v2 16/21] tcm: Add PSCSI subsystem plugin

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Boaz Harrosh
Date: Tuesday, November 2, 2010 - 7:23 am

On 09/23/2010 12:51 AM, Nicholas A. Bellinger wrote:

What about sector-less devices? OSD, Scanners, printers ...
+		default:
+			break;


Just as a future note:
One of the things I'm missing from LIO is the notion of SCSI_TYPE or SCSI
class. So things like this can be done in a plugin manner as per TYPE
Like in the Kernel we have the ULDs for that.


Here!   req->cmd = TASK_CMD(task)->t_task_cdb;

I don't see in this patch the actual memcpy of TASK_CMD(task)->t_task_cdb into
pt->pscsi_cdb, which I suspect is done in Generic code through the use of
->get_cdb(struct se_task *);?

If so then it means all the plugins have their own copy of the CDB? Now I finally
understand the get_max_cdb_len().

All that could be totally clean. All plugins use the TASK_CMD(task)->t_task_cdb
directly. Then get_max_cdb_len(), get_cdb(), the memcpy() and all these extra buffers
just magically go away.


What about sense Surly that is generic just as cdb is. Could you use the
task's sense?


/**
 * blk_execute_rq_nowait - insert a request into queue for execution
 * @q:		queue to insert the request in
 * @bd_disk:	matching gendisk
 * @rq:		request to insert
 * @at_head:    insert request at head or tail of queue
 * @done:	I/O completion handler
 *

Surly you did not mean to use at_head==1? That is a very bad BUG. I bet
this plugin was never heavily used.


Please forgive me I must be looking at an old patch but this is what I could find
in my mail box. 

	task->task_size? there must be two of them one for write/uni one for bidi_read


dito


Good received from caller

		return task_sg_num ??

	return task_sg_num ??


The second __pscsi_map_task_SG can fail. Do you make sure to free
the successful first __pscsi_map_task_SG? 


All over these. Don't cast a void pointer.


??


		req->next_rq = NULL

Actually pt->pscsi_req_bidi is never used, it's set and reset
only req->next_rq is used. You are fine without it. You have
pt->pscsi_req and pt->pscsi_req->next_rq;


Scsi has two residual results. One inside each request. 


Nic all over these patches you have
+	struct pscsi_plugin_task *pt = (struct pscsi_plugin_task *) task->transport_req;
Don't cast void pointers, please. That would be a big fat change just search for transport_req.

OK So I'm stopping to review from email and will next go to the gitweb URL you sent me. Because
in all my mailbox patches I cannot find where the task->transport_req is set, which means I'm
missing some of them. The thing I wanted to know is if there is a 1-to-1 lifetime association
between a plugin task like  pscsi_plugin_task and the task-> which holds it. (On ->transport_req)
If yes, you might consider an embedded se_task in each plugin_task and the use of container_of.
Faster, more robust and cleans code considerably.

But I'll have a look at the latest code later.

Thanks
Boaz

--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC v2 16/21] tcm: Add PSCSI subsystem plugin, Nicholas A. Bellinger, (Wed Sep 22, 3:51 pm)
Re: [RFC v2 16/21] tcm: Add PSCSI subsystem plugin, Boaz Harrosh, (Tue Nov 2, 7:23 am)
Re: [RFC v2 16/21] tcm: Add PSCSI subsystem plugin, Vladislav Bolkhovitin, (Thu Nov 4, 6:14 am)
Re: [RFC v2 16/21] tcm: Add PSCSI subsystem plugin, Nicholas A. Bellinger, (Mon Nov 8, 10:13 pm)
Re: [RFC v2 16/21] tcm: Add PSCSI subsystem plugin, Boaz Harrosh, (Tue Nov 9, 2:16 am)
Re: [RFC v2 16/21] tcm: Add PSCSI subsystem plugin, Nicholas A. Bellinger, (Tue Nov 9, 2:56 am)