From: Jens Axboe <axboe@suse.de>
To: David Woodhouse <dwmw2@infradead.org>
Cc: "Nicolas Pitre" <nico@cam.org>,
"Alan Cox" <alan@lxorguk.ukuu.org.uk>,
"Russell King" <rmk@arm.linux.org.uk>,
"Jörn Engel" <joern@wohnheim.fh-wedel.de>,
"Marcus Meissner" <meissner@suse.de>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Only use MSDOS-Partitions by default on X86
Date: Wed, 7 May 2003 09:22:37 +0200 [thread overview]
Message-ID: <20030507072237.GW905@suse.de> (raw)
In-Reply-To: <1052254888.7532.58.camel@imladris.demon.co.uk>
On Tue, May 06 2003, David Woodhouse wrote:
> On Tue, 2003-05-06 at 19:49, Jens Axboe wrote:
> > I see, that would indeed be a bigger job :). Just the block layer would
> > not be hard, especially if you make the restriction that the block
> > drivers usable would be ones that used a make_request strategy for
> > handling requests. That would allow you to kill ll_rw_blk.c,
> > deadline-iosched.c, and elevator.c. That's some 21k of text and 2k of
> > data on this box.
>
> That's a little short of what I was intending. Ideally we stick 'struct
> request', 'struct buffer_head' and 'struct bio' inside #ifdef
> CONFIG_BLK_DEV, then kill all the dead code which uses them.
struct request can be a goner with my patch, the others not really.
request is really a block private property, so it's easy to kill off.
You are going for the really minimal approach, basically ruling out lots
of filesystems and requiring major surgery all around. While I can see
that make sense for an embedded kernel, I'm having a hard time
envisioning this as something mergable :-)
> mtdblock.c cleanup noted with interest -- I'll play with that shortly;
> thanks. Note that you don't actually need flash hardware, you can load
> the 'mtdram' device which fakes it with vmalloc-backed storage instead.
> Not too useful for powerfail-testing but for mounting something like
> ext2 on mtdblock on mtdram it's fine.
I'm attaching an updated version, I don't think it's safe to use atomic
kmaps across the do_cached_read/write.
Also, I want bio_endio() to increment the sector position of the bio as
well. Makes for a nicer api, and the sector var in mtdblock would then
be killable.
===== drivers/mtd/mtdblock.c 1.43 vs edited =====
--- 1.43/drivers/mtd/mtdblock.c Mon Apr 21 01:21:18 2003
+++ edited/drivers/mtd/mtdblock.c Wed May 7 09:18:30 2003
@@ -381,105 +381,55 @@
* to dequeue requests before we are done.
*/
static struct request_queue mtd_queue;
-static void handle_mtdblock_request(void)
+static volatile int leaving = 0;
+static DECLARE_MUTEX_LOCKED(thread_sem);
+static DECLARE_WAIT_QUEUE_HEAD(thr_wq);
+
+static int mtdblock_make_request(request_queue_t *q, struct bio *bio)
{
- struct request *req;
- struct mtdblk_dev *mtdblk;
- unsigned int res;
+ struct mtdblk_dev **p = bio->bi_bdev->bd_disk->private_data;
+ struct mtdblk_dev *mtdblk = *p;
+ struct bio_vec *bv;
+ sector_t sector;
+ int i, err = 0;
- while ((req = elv_next_request(&mtd_queue)) != NULL) {
- struct mtdblk_dev **p = req->rq_disk->private_data;
- spin_unlock_irq(mtd_queue.queue_lock);
- mtdblk = *p;
- res = 0;
-
- if (! (req->flags & REQ_CMD))
- goto end_req;
-
- if ((req->sector + req->current_nr_sectors) > (mtdblk->mtd->size >> 9))
- goto end_req;
-
- // Handle the request
- switch (rq_data_dir(req))
- {
- int err;
-
- case READ:
- down(&mtdblk->cache_sem);
- err = do_cached_read (mtdblk, req->sector << 9,
- req->current_nr_sectors << 9,
- req->buffer);
- up(&mtdblk->cache_sem);
- if (!err)
- res = 1;
- break;
+ down(&mtdblk->cache_sem);
- case WRITE:
- // Read only device
- if ( !(mtdblk->mtd->flags & MTD_WRITEABLE) )
- break;
-
- // Do the write
- down(&mtdblk->cache_sem);
- err = do_cached_write (mtdblk, req->sector << 9,
- req->current_nr_sectors << 9,
- req->buffer);
- up(&mtdblk->cache_sem);
- if (!err)
- res = 1;
+ if (bio_data_dir(bio) == WRITE && !(mtdblk->mtd->flags & MTD_WRITEABLE))
+ goto end_io;
+
+ sector = bio->bi_sector;
+
+ bio_for_each_segment(bv, bio, i) {
+ char *dst;
+
+ if (sector + (bv->bv_len >> 9) > (mtdblk->mtd->size >> 9)) {
+ err = -EIO;
break;
}
-end_req:
- spin_lock_irq(mtd_queue.queue_lock);
- if (!end_that_request_first(req, res, req->hard_cur_sectors)) {
- blkdev_dequeue_request(req);
- end_that_request_last(req);
- }
+ dst = kmap(bv->bv_page) + bv->bv_offset;
- }
-}
+ if (bio_data_dir(bio) == READ)
+ err = do_cached_read(mtdblk, sector << 9, bv->bv_len, dst);
+ else
+ err = do_cached_write(mtdblk, sector << 9, bv->bv_len, dst);
-static volatile int leaving = 0;
-static DECLARE_MUTEX_LOCKED(thread_sem);
-static DECLARE_WAIT_QUEUE_HEAD(thr_wq);
+ kunmap(bv->bv_page);
-int mtdblock_thread(void *dummy)
-{
- struct task_struct *tsk = current;
- DECLARE_WAITQUEUE(wait, tsk);
+ if (err)
+ break;
- /* we might get involved when memory gets low, so use PF_MEMALLOC */
- tsk->flags |= PF_MEMALLOC;
- daemonize("mtdblockd");
-
- while (!leaving) {
- add_wait_queue(&thr_wq, &wait);
- set_current_state(TASK_INTERRUPTIBLE);
- spin_lock_irq(mtd_queue.queue_lock);
- if (!elv_next_request(&mtd_queue) || blk_queue_plugged(&mtd_queue)) {
- spin_unlock_irq(mtd_queue.queue_lock);
- schedule();
- remove_wait_queue(&thr_wq, &wait);
- } else {
- remove_wait_queue(&thr_wq, &wait);
- set_current_state(TASK_RUNNING);
- handle_mtdblock_request();
- spin_unlock_irq(mtd_queue.queue_lock);
- }
+ sector += bv->bv_len >> 9;
+ bio_endio(bio, bv->bv_len, 0);
}
- up(&thread_sem);
+end_io:
+ up(&mtdblk->cache_sem);
+ bio_endio(bio, bio->bi_size, err);
return 0;
}
-static void mtdblock_request(struct request_queue *q)
-{
- /* Don't do anything, except wake the thread if necessary */
- wake_up(&thr_wq);
-}
-
-
static int mtdblock_ioctl(struct inode * inode, struct file * file,
unsigned int cmd, unsigned long arg)
{
@@ -557,8 +507,6 @@
}
}
-static spinlock_t mtddev_lock = SPIN_LOCK_UNLOCKED;
-
int __init init_mtdblock(void)
{
spin_lock_init(&mtdblks_lock);
@@ -572,8 +520,7 @@
register_mtd_user(¬ifier);
init_waitqueue_head(&thr_wq);
- blk_init_queue(&mtd_queue, &mtdblock_request, &mtddev_lock);
- kernel_thread (mtdblock_thread, NULL, CLONE_FS|CLONE_FILES|CLONE_SIGHAND);
+ blk_queue_make_request(&mtd_queue, mtdblock_make_request);
return 0;
}
--
Jens Axboe
next prev parent reply other threads:[~2003-05-07 7:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20030505210811.GC7049@wohnheim.fh-wedel.de.suse.lists.linux.kernel>
[not found] ` <1052218090.28792.15.camel@dhcp22.swansea.linux.org.uk.suse.lists.linux.kernel>
[not found] ` <20030506120939.GB15261@wohnheim.fh-wedel.de.suse.lists.linux.kernel>
2003-05-06 12:28 ` [PATCH] Only use MSDOS-Partitions by default on X86 Marcus Meissner
2003-05-06 12:42 ` Jörn Engel
2003-05-06 14:03 ` Russell King
2003-05-06 15:32 ` Jörn Engel
2003-05-06 17:13 ` Russell King
2003-05-06 17:23 ` Nicolas Pitre
2003-05-06 17:26 ` Alan Cox
2003-05-06 18:30 ` Jens Axboe
2003-05-06 18:42 ` Nicolas Pitre
2003-05-06 18:49 ` Jens Axboe
2003-05-06 19:10 ` Nicolas Pitre
2003-05-06 19:20 ` Jens Axboe
2003-05-06 19:54 ` Jens Axboe
2003-05-06 21:01 ` David Woodhouse
2003-05-07 7:22 ` Jens Axboe [this message]
2003-05-07 7:41 ` David Woodhouse
2003-05-07 7:43 ` Jens Axboe
2003-05-06 17:42 ` [PATCH] Only use MS-DOS-Partitions " Riley Williams
2003-05-05 21:08 [PATCH] Only use MSDOS-Partitions " Jörn Engel
2003-05-06 10:48 ` Alan Cox
2003-05-06 12:09 ` Jörn Engel
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=20030507072237.GW905@suse.de \
--to=axboe@suse.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dwmw2@infradead.org \
--cc=joern@wohnheim.fh-wedel.de \
--cc=linux-kernel@vger.kernel.org \
--cc=meissner@suse.de \
--cc=nico@cam.org \
--cc=rmk@arm.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).