On Wed, 13 Feb 2002, Vojtech Pavlik wrote:
> On Tue, Feb 12, 2002 at 11:27:42PM -0800, Andre Hedrick wrote:
> > On Wed, 13 Feb 2002, Vojtech Pavlik wrote:
> >
> > > On Tue, Feb 12, 2002 at 09:52:07PM -0800, Andre Hedrick wrote:
> > >
> > > > HELL NO!
> > >
> > > Hell why?
> >
> > Does Virtual DMA mean anything?
>
> Sure. Virtual-Direct-Marketing-Association, then there is the VDS,
> Vitrual-DMA-Services, which is a DOS DMA access specification, then
> there is the VDMA on PCI - this is a term used for normal PCI BM DMA
> passing through an IOMMU-capable bridge. Then there is Virtual-DMA on
> floppy controllers and NE*000's - which allows feeding the data to the
> card via PIO when there is no ISA DMA controller available in the
> system.
>
> None of this is relevant to IDE on Linux.
Well not yet but here is a hint, all future hardware will be MMIO.
Meaning all IO is performed under DMA over the ATA-Bridge.
Specifically PIO operations are transacted over VDMA to the Bridge and
executed as PIO by the Bridge.
> Perhaps you mean PIO using SG-lists to put the data into the right
> places. But I still don't see a problem with this and the proposed patch.
>
> > Does a function struct for handling IO and MMIO help?
>
> Ugh? What is "function struct"?
Since the future will be a mess, and it is possible to have IO/MMIO on the
same HOST it will be come more fun than you can imagine.
> > All you two are doing is causing more work for me to build a working
> > model.
>
> It's possible - but then that is because we have different development
> strategies. Ours is to start with minimum code and if something needs to
> be made different, then duplicate and edit that. But only when needed.
> Yours seems to be to duplicate everything first, make the changes and
> then look at what can be merged.
Mine is knowing the future of hardware and preparing for it to come.
Why else would I packetize the ATA-Command Block?
> In theory they both give the same results.
>
> I don't think that happen's in reality. Duplicating first never gets
> merged together later, as many tiny differences emerge. Believe me, I
> know this - this already happened many times in the kernel and is a huge
> amount of work to undo - keep shared code shared.
>
> > But it is clear you must poke and screw things up, so I will continue to
> > undo it in my trees until I have it working.
>
> If you think so, sure, you're free to do that.
Well give you can not have access to hardware which doesn't exist ...
Cheers,
Andre Hedrick
Linux Disk Certification Project Linux ATA Development
-
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/
This archive was generated by hypermail 2b29 : Fri Feb 15 2002 - 21:00:53 EST