public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: Alexander Schmidt <alexs@linux.vnet.ibm.com>
Cc: Christoph Hellwig <hch@infradead.org>, linux-mtd@lists.infradead.org
Subject: Re: [RFC] [PATCH] UBI: convert to kthread API
Date: Wed, 28 Feb 2007 12:04:13 +0200	[thread overview]
Message-ID: <1172657053.17031.20.camel@sauron> (raw)
In-Reply-To: <200702280915.26914.alexs@linux.vnet.ibm.com>

On Wed, 2007-02-28 at 09:15 +0100, Alexander Schmidt wrote:
> Basically, with using the kthread api, it is still neccessary to have the
> following functions:
> 
> 1) start the thread with kthread_create()
> 2) a main loop for the thread
> 3) enqueue work in the pending work list
> 4) kill/stop the thread
> 
> As 3) is only done by the wear leveling unit, the code could be moved
> there, IMO. Starting and stoping the thread could also be done in the
> wl init and close functions, so it seems sensible to move everything to
> the wear leveling unit.
> 
> A point that causes complexity in the code is that we have two ways of
> stopping the thread:
> 
> 1) If ubi goes into read only mode or if the thread is disabled via sysfs,
> the thread is put to sleep, pending works are not finished
> 2) If ubi is shut down, the thread finishes all pending works and then
> exits.
> 
> An enhancement here would be to remove the sysfs functionality, and make
> the thread exit when going in ro_mode, while still not finishing the
> pending work (it is not possible to leave ro_mode during runtime, right?)

My unsorted points:

A. Well, at the moment we switch to RO mode if we hit an error and do
not know how to handle it. And yes, at the moment it is forever, but
later we may want to add a sysfs entry to leave the RO mode, for example
jwb already wants it.

B. Also, at the moment UBI does not work if the bgt is killed, but this
is not nice and will be fixed at some point - we should be able to do
everything if the thread is killed.

C. The stuff which stops the thread is _debugging_ stuff and you may
remove it if it causes troubles. I will add something like "do not spawn
the thread" debugging option later when I need it.

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

  reply	other threads:[~2007-02-28 10:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-27 13:50 [RFC] [PATCH] UBI: convert to kthread API Alexander Schmidt
2007-02-27 17:47 ` Artem Bityutskiy
2007-02-27 18:04   ` Josh Boyer
2007-02-27 18:11     ` Artem Bityutskiy
2007-02-28  8:15       ` Alexander Schmidt
2007-02-28 10:04         ` Artem Bityutskiy [this message]
2007-02-28 14:48           ` Alexander Schmidt
2007-02-28 16:13             ` 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=1172657053.17031.20.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=alexs@linux.vnet.ibm.com \
    --cc=hch@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox