Hello,
I'm sending this to fsdevel as we're using vfs functions to open
inodes and read/write from them in btrfs send/receive and a review by
vfs folks would probably be a good thing here. I extracted the vfs
related functions from the current version and copied them into this
mail below.
write_b
Hi,
> write_buf:
> Used to write the stream to a user space supplied pipe. Please note
> the ERESTARTSYS comment there, I need some help here as I don't know
> how to handle that correctly. If I ignore the return value, it loops
> forever. If I bail out to user space, it reenters the ioctl and sta
Hi Alex,
On Mon, September 24, 2012 at 11:13 (+0200), Alex Lyakas wrote:
> Hi,
>
>> write_buf:
>> Used to write the stream to a user space supplied pipe. Please note
>> the ERESTARTSYS comment there, I need some help here as I don't know
>> how to handle that correctly. If I ignore the return val
Hi Jan,
I hope to get my proposal working soon, then expect for some code from
me to look at.
Thanks!
Alex.
On Mon, Sep 24, 2012 at 11:27 AM, Jan Schmidt wrote:
> Hi Alex,
>
> On Mon, September 24, 2012 at 11:13 (+0200), Alex Lyakas wrote:
>> Hi,
>>
>>> write_buf:
>>> Used to write the stream t
Hi Jan,
as I promised, here is some code for you to look at.
First I will describe the approach in general.
# Get rid of the pipe. Instead, user-space passes a buffer and kernel
fills the specified user-space buffer with commands.
# When the buffer is full, kernel stops generating commands and
re
Am Donnerstag, 4. Oktober 2012 schrieb Alex Lyakas:
> Hi Jan,
> as I promised, here is some code for you to look at.
>
> First I will describe the approach in general.
>
> # Get rid of the pipe. Instead, user-space passes a buffer and kernel
> fills the specified user-space buffer with commands.
Matrin,
On Sat, Oct 6, 2012 at 11:40 AM, Martin Steigerwald wrote:
> Am Donnerstag, 4. Oktober 2012 schrieb Alex Lyakas:
>> Hi Jan,
>> as I promised, here is some code for you to look at.
>>
>> First I will describe the approach in general.
>>
>> # Get rid of the pipe. Instead, user-space passes
Am Sonntag, 7. Oktober 2012 schrieb Alex Lyakas:
> Matrin,
Martin, but bet was just a typo.
> On Sat, Oct 6, 2012 at 11:40 AM, Martin Steigerwald
wrote:
> > Am Donnerstag, 4. Oktober 2012 schrieb Alex Lyakas:
> >> Hi Jan,
> >> as I promised, here is some code for you to look at.
> >>
> >> Firs
Martin,
I apologize for misspelling your name.
Yes, user-space can handle a buffer pool of any number of buffers,
like one thread fetching a free buffer, handling it to the kernel,
then putting it on some ready-buffer queue and signalling to a another
thread that fetches ready (full) buffers and h
Am Sonntag, 7. Oktober 2012 schrieb Alex Lyakas:
> On Sun, Oct 7, 2012 at 12:53 PM, Martin Steigerwald
wrote:
> > Am Sonntag, 7. Oktober 2012 schrieb Alex Lyakas:
[…]
> >> On Sat, Oct 6, 2012 at 11:40 AM, Martin Steigerwald
> >
> > wrote:
> >> > Am Donnerstag, 4. Oktober 2012 schrieb Alex Lyak
Hi Alex,
On Thu, October 04, 2012 at 17:59 (+0200), Alex Lyakas wrote:
> as I promised, here is some code for you to look at.
And quite a lot of it. I hadn't thought of such a big change when I wrote
"preferably in form of a patch".
As a side note, your patch doesn't follow the general kernel co
Hi Jan,
thanks for taking time to look at the code.
On Mon, Oct 8, 2012 at 11:26 AM, Jan Schmidt wrote:
> Hi Alex,
>
> On Thu, October 04, 2012 at 17:59 (+0200), Alex Lyakas wrote:
>> as I promised, here is some code for you to look at.
>
> And quite a lot of it. I hadn't thought of such a big c
On Mon, October 08, 2012 at 13:38 (+0200), Alex Lyakas wrote:
>>> I realize this is a big change, and a new IOCTL has to be introduced
>>> in order not to break current user-kernel protocol.
>>> The pros as I see them:
>>> # One data-copy is avoided (no pipe). For WRITE commands two
>>> data-copies
Hi Jan,
On Mon, Oct 8, 2012 at 3:37 PM, Jan Schmidt wrote:
> On Mon, October 08, 2012 at 13:38 (+0200), Alex Lyakas wrote:
I realize this is a big change, and a new IOCTL has to be introduced
in order not to break current user-kernel protocol.
The pros as I see them:
# One dat
14 matches
Mail list logo