All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Rene Herman <rene.herman@gmail.com>
Cc: Andrew Morton <akpm@osdl.org>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: New Mitsumi legacy CD-ROM driver
Date: Tue, 8 May 2007 12:35:24 +0200	[thread overview]
Message-ID: <20070508103524.GH4163@kernel.dk> (raw)
In-Reply-To: <464045F0.3040906@gmail.com>

On Tue, May 08 2007, Rene Herman wrote:
> Good day.
> 
> This is (the start of) a new driver for the legacy Mitsumi CD-ROM (LU-00xS 
> and FX-001x) drives that used to be supported by drivers/cdrom/mcd(x).c, a 
> driver that hasn't worked for a long time.
> 
> It's being tested on my LU-005S and is being submitted to -mm in the hope 
> of maybe finding a few more testers and also in the hope of provoking a 
> review. I'm co-authoring this with Pekka Enberg but certainly for me it's 
> the first ever contact with anything having anything to do with block.
> 
> A few specific points/questions:
> 
> * This driver's core transfer function is doing:
> 
>   rq_for_each_bio(bio, req)
>       bio_for_each_segment(bvec, bio, segno) {
>           buffer = bvec_kmap_irq(bvec, &flags);
>           ioread8_rep(ioaddr, buffer, bvec->bv_len);
>           bvec_kunmap_irq(buffer, &flags);
>       }
> 			
> I've been slightly worried about struct bio having a bi_sector field. If 
> we're not guaranteed that bio[n].bi_sector == bio[n-1].bi_sector + 1 during 
> the rq_for_each_bio() loop we can't read from I/O into bio's directly but 
> will need to use a temporary buffer and transfer into the bio's later. Is 
> this guaranteed?

bio[n - 1].bi_sector + bio_sectors(bio[n - 1]) == bio[n].bi_sector

IOW, the bio's in the chain on the request are contig in the lba space.

> * This driver purports to support highmem. Given the number of machines out 
> there that have both a Mitsumi legacy CD-ROM drive and enough physical 
> memory installed to want highmem support this may come across as being 
> overly... optimistic but is there much point to not supporting it? I 
> believe we do always need the full rq_for_each_bio/bio_for_each_segment 
> loop meaning that only the bvec_k{,un}map_irq could go, right?

Yeah, I think it's pointless to support highmem. And as long as you
don't call blk_queue_bounce_limit() to actively enable highmem, you are
not going to receive a bio/request with highmem pages. The block layer
wil bounce any highmem pages before it reaches you. So for a driver like
this, I would recommend just forgetting the mapping aspect.

I don't have time to review your driver right now, but I will applaud
your effort to write a maintenable mitsumi driver! Basically all the old
cdrom drivers are utter crap, so they are destined for removal.

-- 
Jens Axboe


  parent reply	other threads:[~2007-05-08 10:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-08  9:42 New Mitsumi legacy CD-ROM driver Rene Herman
2007-05-08  9:44 ` Rene Herman
2007-05-08 10:35 ` Jens Axboe [this message]
2007-05-08 13:39   ` Rene Herman
2007-05-08 13:49     ` Jens Axboe
2007-05-08 13:57       ` Pekka J Enberg
2007-05-08 14:04         ` Jens Axboe
2007-05-08 14:20           ` Rene Herman
2007-05-10 15:54       ` Rene Herman
2007-05-08 13:53 ` Pekka Enberg
2007-05-08 13:53   ` Jens Axboe
2007-05-08 14:17   ` Rene Herman
2007-05-08 14:34     ` Pekka J Enberg
2007-05-08 14:27   ` Pekka Enberg
2007-05-08 20:13 ` Ondrej Zary
2007-05-08 21:12   ` Bob Tracy
2007-05-10 16:03     ` Rene Herman
2007-05-10 15:59   ` Rene Herman

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=20070508103524.GH4163@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    --cc=rene.herman@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.