lkml.org 
[lkml]   [2004]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.031 / U:0.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site