Vscsiif.h still needs clean up:
1. You cannot have Linux-specific stuff in that header file. It's supposed
to be generic. Get rid of references to CONFIG_XEN_FC.
2. You cannot pollute the global namespace with unqualified names. All your
names, macros, etc should have a vscsiif_ or VSCSIIF_ prefix. Names like
DEFAULT_CAN_QUEUE and SG_TABLESIZE pollute the namespace and it's not
immediately obvious which header they come from (which it would be if they
were prefixed).
3. Do you really mean for vscsiif_btf_response to be empty? And neither
response structure has an identifier to match the request it responds to.
Can requests not be handled out of order by your drivers? That would seem
very odd.
Also CONFIG_XEN_FC is ifdef'ed all over scsifront and scsiback. You'll have
to find some way to clean that up, perhaps by providing null stub
implementations of fc functions in a header file if !CONFIG_XEN_FC.
FIXME comments in the connection setup code, accompanied by hard-coded
constants, don't bode well. Is the connection setup protocol fully baked
yet?
All this, coupled with the fact that you can only export whole HBAs, which
doesn't seem likely to be a very popular usage scenario, makes me think this
driver should wait until after 3.2.0.
--Keir
On 30/10/07 10:39, "Jun Kamada" <kama@xxxxxxxxxxxxxx> wrote:
> Keir-san,
>
> I have finished the modification of the driver by option i.).
> The pvSCSI driver can work on heterogeneous (x86_32 and x86_64)
> environment.
>
> I will attach total six patches on following mail.
>
> Best regards,
>
>
> On Thu, 25 Oct 2007 10:59:31 +0900
> Jun Kamada <kama@xxxxxxxxxxxxxx> wrote:
>
>> Keir-san,
>>
>> On Wed, 24 Oct 2007 08:42:38 +0100
>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:
>>> On 24/10/07 07:22, "Jun Kamada" <kama@xxxxxxxxxxxxxx> wrote:
>>>
>>>>> Anyway, the right answer is to ensure that your structures compile the
>>>>> same
>>>>> whether compiled with 32-bit or 64-bit gcc. Check the structure sizes,
>>>>> fields sizes and field offsets.
>>>>
>>>> You showed me two options in previous email; i.) all the shared-memory
>>>> structures defined in vscsiif.h compile identically for 32-bit and
>>>> 64-bit mode, ii.) to detect the frontend's 'bitness' in scsiback and
>>>> optionally do 32-to-64 or 64-to-32 conversion.
>>>>
>>>> I consider that current VBD implementation takes option ii.), however
>>>> you recommended me to take option i.) for pvSCSI driver.
>>>> Is my understanding right?
>>>
>>> Yes. It was an accident we ended up with structures compiling differently on
>>> 32- vs 64-bit. By the time we discovered it was an issue, we couldn't break
>>> backward compatibility.
>>
>> I understood. I'll try to modify the pvSCSI driver by option i.).
>>
>> Best regards,
>>
>> -----
>> Jun Kamada
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>
> -----
> Jun Kamada
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home