The potential impact is that if the existing server returns iounit==0,
there will be two Rread count 0. Which is perfectly fine with 9P, just
a bit slower. I am not sure how Plan9 handles the case.
Thanks,
Lucho
On Mon, Aug 23, 2010 at 10:11 AM, Eric Van Hensbergen <ericvh@xxxxxxxxx> wrote:
> On Tue, Aug 17, 2010 at 3:39 PM, Latchesar Ionkov <lucho@xxxxxxxxxx> wrote:
>> The only solution I can think of is to use the iounit value the file
>> server returns (and not the msize as we do now). If iounit is 0, allow
>> short reads, if iounit is more than zero and the read returns less
>> that the iounit, don't try anymore.
>>
>> This kind of passes the problem to the file server, but I guess that's
>> the right place to solve it anyway.
>>
>
> What's the potential impact on existing serves? What does Plan 9 expect?
>
> read(5) says:
> The count field in the reply indicates the number of bytes returned.
> This may be less than the requested amount. If the offset field is
> greater than or equal to the number of bytes in the file, a count of
> zero will be returned.
>
> I'd say if we wanted to do something different, I would need to be
> conditional by 9p2000.u/9p2000.L -- I don't want to break existing
> servers/clients that might rely on this behavior to frame messages
> (like pipes, the IP stack, etc.)
>
> -eric
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
