All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: Vinit Agnihotri <vinit.agnihotri@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBI: Can we handle -EINTR differently in erase/write path???
Date: Tue, 17 Jul 2007 13:36:47 +0300	[thread overview]
Message-ID: <1184668607.3531.144.camel@sauron> (raw)
In-Reply-To: <9b52d64c0707122307j419d2d98xa771c2c09a280164@mail.gmail.com>

On Fri, 2007-07-13 at 11:37 +0530, Vinit Agnihotri wrote:
> Hi heres few code snip from erase_worker(); from wl.c
> if (err != -EIO) {
>         /*
>          * If this is not %-EIO, we have no idea what to do. Scheduling
>          * this physical eraseblock for erasure again would cause
>          * errors again and again. Well, lets switch to RO mode.
>          */
>         ubi_ro_mode(ubi);
>         return err;
>     }
> Suppose while erasure in progress & someone pressed "Ctrl+C" then UBI
> straight way marks entire device as Read only & its really painful
> because then you cant even delete that volume as UBI is read only.
> Which I guess its not good way. If use cases are considered it is
> highly likely that user can hit "Ctrl+c" , like he want to cancel
> erase at that time or something like that. So we can handle -EINTR
> differently by following way

Please, feel free to ignore my silly question and just send the
patch :-)

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

  parent reply	other threads:[~2007-07-17 10:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-13  6:07 UBI: Can we handle -EINTR differently in erase/write path??? Vinit Agnihotri
2007-07-13 13:06 ` Josh Boyer
2007-07-14 11:59   ` Vinit Agnihotri
2007-07-17  8:16 ` Artem Bityutskiy
2007-07-17 10:36 ` Artem Bityutskiy [this message]
2007-07-17 10:48   ` Vinit Agnihotri
2007-07-18  8:52 ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1184668607.3531.144.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=vinit.agnihotri@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.