On Wed, Nov 23, 2016 at 08:30:20AM +0100, Vincent Bernat wrote:
> ❦ 22 novembre 2016 10:49 GMT, Stefan Hajnoczi :
>
> >> I guess the question is that while the patch above could be accepted for
> >> the upcoming 2.8 (I don't see it breaking existing systems), a patch
> >>
❦ 22 novembre 2016 10:49 GMT, Stefan Hajnoczi :
>> I guess the question is that while the patch above could be accepted for
>> the upcoming 2.8 (I don't see it breaking existing systems), a patch
>> that would implement the transformation would be a lot more involved,
>> and
On Mon, Nov 21, 2016 at 04:05:41PM +0100, Samuel Thibault wrote:
> Stefan Hajnoczi, on Mon 21 Nov 2016 14:46:16 +, wrote:
> > On Sun, Nov 20, 2016 at 09:41:36AM +0100, Vincent Bernat wrote:
> > > From: Vincent Bernat
> > >
> > > Some network equipments are requesting a
On November 21, 2016 7:05:41 AM PST, Samuel Thibault
wrote:
>Stefan Hajnoczi, on Mon 21 Nov 2016 14:46:16 +, wrote:
>> On Sun, Nov 20, 2016 at 09:41:36AM +0100, Vincent Bernat wrote:
>> > From: Vincent Bernat
>> >
>> > Some network equipments are
On November 21, 2016 7:35:28 AM PST, Vincent Bernat
wrote:
> ❦ 21 novembre 2016 14:46 GMT, Stefan Hajnoczi :
>
>> The commit description says it would be "far more complex" to
>implement
>> netascii. Is the LF -> CR LF and CR -> CR NUL
❦ 21 novembre 2016 14:46 GMT, Stefan Hajnoczi :
> The commit description says it would be "far more complex" to implement
> netascii. Is the LF -> CR LF and CR -> CR NUL transformation so hard?
Currently, the code uses lseek to send each block. It is just a matter
of
On November 21, 2016 6:46:16 AM PST, Stefan Hajnoczi
wrote:
>On Sun, Nov 20, 2016 at 09:41:36AM +0100, Vincent Bernat wrote:
>> From: Vincent Bernat
>>
>> Some network equipments are requesting a file using the netascii
>> protocol and this is not
Stefan Hajnoczi, on Mon 21 Nov 2016 14:46:16 +, wrote:
> On Sun, Nov 20, 2016 at 09:41:36AM +0100, Vincent Bernat wrote:
> > From: Vincent Bernat
> >
> > Some network equipments are requesting a file using the netascii
> > protocol and this is not configurable. Currently,
On Sun, Nov 20, 2016 at 09:41:36AM +0100, Vincent Bernat wrote:
> From: Vincent Bernat
>
> Some network equipments are requesting a file using the netascii
> protocol and this is not configurable. Currently, qemu's tftpd only
> supports the octet protocol. This commit makes it
On 20.11.2016 09:41, Vincent Bernat wrote:
> From: Vincent Bernat
>
> Some network equipments are requesting a file using the netascii
> protocol and this is not configurable. Currently, qemu's tftpd only
> supports the octet protocol. This commit makes it accept the netascii
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [v2] tftp: fake support for netascii protocol
Type: series
Message-id: 20161120084136.721-1-vincent.ber...@exoscale.ch
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [v2] tftp: fake support for netascii protocol
Message-id: 20161120084136.721-1-vincent.ber...@exoscale.ch
Type: series
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
From: Vincent Bernat
Some network equipments are requesting a file using the netascii
protocol and this is not configurable. Currently, qemu's tftpd only
supports the octet protocol. This commit makes it accept the netascii
protocol as well but do not perform the requested
13 matches
Mail list logo