On Fri, 2012-02-24 at 13:13 +0100, Sebastian Andrzej Siewior wrote:
> * Roland Dreier | 2012-02-23 09:54:23 [-0800]:
>
> >> @@ -522,6 +523,7 @@ struct se_cmd {
> >> /* Used to signal cmd->se_tfo->check_release_cmd() usage per cmd */
> >> unsigned check_release:1;
> >> unsigned cmd_wait_set:1;
> >> + unsigned unknown_data_length:1;
> >> /* See se_cmd_flags_table */
> >> u32 se_cmd_flags;
> >> u32 se_ordered_id;
> >
> >why do we need this unknown_data_length member? As far
> >as I can see from Nic's tree (which has the usb-gadget fabric
> >driver merged up), the only place it is used is in this one function.
> Yes, there is only one user of it.
>
> >Why not just do
> >
> > if (flags & TARGET_SCF_UNKNOWN_SIZE)
> > cmd->data_length = size;
> >
> >at the end and avoid the obfuscation? Is there some other
> >use for this member planned?
> I don't think so. The new firewire target can probably deal without it.
> Nic did not complain about it. The alternative would be to pass flags
> additionally to transport_generic_allocate_tasks() and
> transport_generic_cmd_sequencer() to have it here _or_ introduce
> SCF_UNKNOWN_SIZE so we can grab this flag from se_cmd_flags. Either way
> I'm fine with both ways if you want to get rid of unknown_data_length.
>
Hi guys,
Passing an optional target_submit_cmd() flags into
transport_generic_alloc_tasks() probably makes the most sense to
avoiding the extra bit-field per se_cmd, and I'm happy to take a patch
to change this for transport_generic_allocate_tasks() users in lio-core.
At the moment I don't have a strong preference either way since
usb-gadget is not included into target-pending/for-next-merge just yet,
so I'll probably end up dropping this patch in target-pending/for-next.
--nab
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
