From: Rene Herman <rene.herman@gmail.com>
To: Jens Axboe <jens.axboe@oracle.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, 08 May 2007 15:39:01 +0200 [thread overview]
Message-ID: <46407D75.7050603@gmail.com> (raw)
In-Reply-To: <20070508103524.GH4163@kernel.dk>
On 05/08/2007 12:35 PM, Jens Axboe wrote:
Thanks very much for the prompt answer!
> 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.
Okay great, thanks, everything fine then.
> 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.
Yep, the driver is setting BLK_BOUNCE_ANY.
> 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.
Okay, I agree highmem doesn't make any practical sense for this driver but
I'm not really sure what it would gain. if !CONFIG_HIGHMEM the bvec_kmap_irq
turns info "(page_address((bvec)->bv_page) + (bvec)->bv_offset)" directly
anyway. I am a bit unsure about it all but it's not the case that we can
then leave out the entire bio_for_each_segnment() loop is it?
(generic kernels with HIGHMEM enabled are I guess an argument...)
> 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.
I noticed by the way there was a bit too much emphasis on the "I" in this
message; it's in fact Pekka Enberg who started this and did the core stuff!
Yes ,the current legacy CD-ROM drivers really are complete crap by now. Once
this mitsumi driver is in final shape it should serve as a nice template for
the few other types that I'd like to keep supported and the rest can just go.
Thanks again for the prompt comments.
Rene.
next prev parent reply other threads:[~2007-05-08 13:41 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
2007-05-08 13:39 ` Rene Herman [this message]
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=46407D75.7050603@gmail.com \
--to=rene.herman@gmail.com \
--cc=akpm@osdl.org \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
/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