Messages in this thread | | | Date | Mon, 9 Aug 2004 16:17:24 +0200 | From | Jens Axboe <> | Subject | Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices |
| |
On Mon, Aug 09 2004, Joerg Schilling wrote: > > >From: Jens Axboe <axboe@suse.de> > > >On Mon, Aug 09 2004, Joerg Schilling wrote: > >> >From axboe@suse.de Fri Aug 6 17:10:35 2004 > >> > >> >> Let me give you a short answer: If DMA creates so many problem on Linux, > >> >> how about imlementing a generic DMA abstraction layer like Solaris does? > >> > >> >We do have that. But suddenly changing the alignment and length > >> >restrictions on issuing dma to a device in the _end_ of a stable series > >> >does not exactly fill me with joyful expectations. It's simply that, > >> >not lack of infrastructure. > >> > >> If you _really_ _had_ a DMA abstraction layer, then ide-scsi would use > >> DMA for all sector sizes a CD may have. The fact that ide-scsi does > >> not use DMA easily proves that you are wrong. > > >For someone who apparently doesn't even bother to look at the source, > >it's hard to discuss these things. "DMA abstraction layer" continues > >your fine history of being deliberatly vague in that it can mean > >basically anything or nothing. > > In case you don't know what DMA abstraction is:
Translation from shillyness to english: In case I didn't know what Joerg regards as DMA abstraction.
> DMA abstraction includes everything that is going to be done to set up > DMA after the buffer address and the size is known. > > If you were true and Linux would include _and_ use DMA abstraction, then > we would have DMA with ide-scsi for all CD sector sizes.
Just because we have an api for helping drivers map data for dma, doesn't necessarily mean that they all use it. In 2.6.8 ide-scsi will use dma for all transfers. As I've already stated, I wont be fixing 2.4. I've also included reasons for this. You seem to think that a 'DMA abstraction layer' means there will be no hardware bugs, I only wish that was so.
> >> AGAIN: if you believe you did invent a better method, _describe_ it. > >> As you did not describe a _working_ method different from the one I > >> request, you need to agree that you are wrong - as long as your > >> description is missing. > > >I did not invent a better method, but one exists - in Linux this is the > >device special file. > > Interesting: tell us more about how Linux handles kernel user > interfaces by using a device special file instead of including the > same include file in the kernel code as well as in the applicatin > code?
We were talking about device addressing, right? Or are you ramblinb on about API stability again?
> >> I am able to distinct between something that only looks like a kernel > >> problem and something that really is a kernel problem. As long as you > > >You've already shown that statement to be false many times in this > >thread. > > YOu have only shown that you in many caes try to ignoore the truth ;-(
I'm surprised an ego of your size can even be contained inside a normally sized (I'm assuming, having never met you) human body. I guess in your opinion, anything oozing from your brain is by definition the truth? That's the only way that I can see your above sentence making sense to you.
> >Listen, you silly little man: if you want things fixed in the kernel, > >you provide a patch. Understand that concept? > > Listen arrogant little man: I have enough to to with writing free > software. I report bugs and if you are the author, you fix your bugs > or I need to tell the users of your software that you are unwilling to > maintain your software.
Yet you refuse to do the same yourself.
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |