Messages in this thread | | | Date | Thu, 24 Aug 2000 09:02:28 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: PATCH - final (I hope) tidy up for generic_make_request interface |
| |
On Thu, 24 Aug 2000, Neil Brown wrote: > > > > Which implies that we should not have it in the generic path, but in the > > per-queue path. > > I'm beginning to see your point... > > Maybe we should then have a "blk_queue_highmem_capable(q,flag)" > function whereby drivers can tell elevator_make_request that they > are highmem aware, and so the create_bounce will be skipped ??
No. No flags. That's the mistake SCSI did, and it is a fundamental mistake. It makes it basically impossible to "shift out" old code.
I'd much rather have two separate functions for this - sure, they can share most of the code by using common inline functions and what not, but I'd be a lot happier with drivers just using the function that they are most comfortable with directly.
Anyway, this is not a change I'd like to have at this point. This is definitely a 2.5.x thing.
> md_make_request needs it (I thought) because it accesses the data in the > buffers ... sometimes.
Yes. But like rd_make_request(), it only does so from the CPU, not from any real device (obviously). So it doesn't actually need to create a _physical_ bounce-buffer the way a real device needs to that does DMA etc. It can just use the same "kmap()" functionality that all the other generic kernel code uses.
Real devices are special. We don't know what they will end up doing, and some (many) of them actually care deeply about the physical address as opposed to just wanting to have the CPU able to touch the page.
> So, in summary: > I was advocating the "keep it simple for now" position advocated by > the comment, and applying the one solution to all drivers.
I agree with that notion. I don't think your patch was a bad one. I just think that it would make it a more straightforward operation later when we _do_ start to make it aware of clever devices to not do it the way you did.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |