linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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(&notifier);
 	
 	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


  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).