Hi Andrew,
On Sun, 6 Feb 2005, Andrew Morton wrote:
> Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> > On Thu, 3 Feb 2005, Andrew Morton wrote:
> > > I did a patch which switched loop to use the file_operations.read/write
> > > about a year ago. Forget what happened to it. It always seemed the
Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
>
> On Thu, 3 Feb 2005, Andrew Morton wrote:
> > I did a patch which switched loop to use the file_operations.read/write
> > about a year ago. Forget what happened to it. It always seemed the right
> > thing to do..
>
> How did you implement the writ
On Thu, 3 Feb 2005, Andrew Morton wrote:
> I did a patch which switched loop to use the file_operations.read/write
> about a year ago. Forget what happened to it. It always seemed the right
> thing to do..
How did you implement the write? At the moment the loop driver gets hold
of both source
On Fri, 4 Feb 2005, Anton Altaparmakov wrote:
> On Thu, 2005-02-03 at 11:23 -0800, Bryan Henderson wrote:
> >
> > I think the point is that we can't have a "handler for writes," because
> > the writes are being done by simple CPU Store instructions in a user
> > program. The handler we're talki
On Thu, 2005-02-03 at 11:23 -0800, Bryan Henderson wrote:
> >> > > And for the vmscan->writepage() side of things I wonder if it would
> be
> >> > > possible to overload the mapping's ->nopage handler. If the target
> page
> >> > > lies in a hole, go off and allocate all the necessary pagecache
>I did a patch which switched loop to use the file_operations.read/write
>about a year ago. Forget what happened to it. It always seemed the
right
>thing to do..
This is unquestionably the right thing to do (at least compared to what we
have now). The loop device driver has no business assumi
>> > > And for the vmscan->writepage() side of things I wonder if it would
be
>> > > possible to overload the mapping's ->nopage handler. If the target
page
>> > > lies in a hole, go off and allocate all the necessary pagecache
pages, zero
>> > > them, mark them dirty?
>> >
>> > I guess it wou
On Thu, 2005-02-03 at 02:47 -0800, Andrew Morton wrote:
> Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> > On Wed, 2005-02-02 at 14:34 -0800, Andrew Morton wrote:
> > > Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Below is a patch which adds a function
> > > > mm/filemap.c::find
Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2005-02-02 at 14:34 -0800, Andrew Morton wrote:
> > Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> > >
> > > Below is a patch which adds a function
> > > mm/filemap.c::find_or_create_pages(), locks a range of pages. Please
> > > see
>
On Wed, 2005-02-02 at 14:34 -0800, Andrew Morton wrote:
> Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> >
> > Below is a patch which adds a function
> > mm/filemap.c::find_or_create_pages(), locks a range of pages. Please see
> > the function description in the patch for details.
>
> This i
Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
>
> Below is a patch which adds a function
> mm/filemap.c::find_or_create_pages(), locks a range of pages. Please see
> the function description in the patch for details.
This isn't very nice, is it, really? Kind of a square peg in a round hole.
Hi Matthew,
On Wed, 2005-02-02 at 15:43 +, Matthew Wilcox wrote:
> On Wed, Feb 02, 2005 at 03:12:50PM +, Anton Altaparmakov wrote:
>
> I think the below loop would be clearer as a for loop ...
>
> err = 0;
> for (nr = 0; nr < nr_pages; nr++, start++) {
> if (sta
On Wed, Feb 02, 2005 at 03:12:50PM +, Anton Altaparmakov wrote:
I think the below loop would be clearer as a for loop ...
err = 0;
for (nr = 0; nr < nr_pages; nr++, start++) {
if (start == lp_idx) {
pages[nr] = locked_page;
Hi,
On Thu, 27 Jan 2005, Andrew Morton wrote:
> Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> > What would you propose can I do to perform the required zeroing in a
> > deadlock safe manner whilst also ensuring that it cannot happen that a
> > concurrent ->readpage() will cause me to miss a page
14 matches
Mail list logo
