Re: With Daniel Phillips Patch

[David S. Miller]

   From: "Justin T. Gibbs" <[e-mail]>
   Date: Wed, 22 Aug 2001 13:41:16 -0600

   >
   >Drivers for SAC only PCI devices shall not be bloated by 64-bit type,
   >not in any case whatsoever.
   
   Where's the bloat?  The driver's S/G list is in the driver's native format.

All the world is not a scsi driver.  Consider networking
and other types of drivers that need not make use of
scatter lists.

   >Either your device is 64-bit capable or not, what is so complicated?
   
   The complication arrises when there is a performance impact associated
   with 64bit support.  You may want to completely compile out 64bit support.
   If I can use the exact same API if the user decides to configure my
   device to not enable large address support, then my complaint is only
   that it seems supurfluous to have two different APIs and types.

You can indeed use the same API.  There are two situations.

1) The performance impact is "platform specific", so let the
   platform decide for you:

	Use pci64_foo() and set the DMA mask to what you can support.
	Ie. a normal DAC supporting driver.

2) The performance impact is "device specific", so only use
   the 32-bit API.   

   >What is the virtual address of physical address 0x100000000
   >on a 32-bit cpu system if the page is not currently kmap()'d?
   
   Why does the driver care?  The driver asked to have some virtual address
   mapped into a bus address.  Are you saying the system can't understand
   figure out what physical page this is and from that the necessary
   IOMMU magic to make it visible to the device?
   
It is the object that the block and networking systems work with
that is the issue.

Do you know how physical memory is mapped under Linux?  Everything
non-HIGHMEM is directly mapped.  Everything else must be temporarily
"kmap()'d" so that the kernel and perform loads and stores to that
page.

The only object representation that works for all kinds of pages,
HIGHMEM or not, is the "struct page *page; unsigned long offset;"
tuple.

If this wasn't a problem, Jens's would not be doing any of the
work he is doing right now :-)

   It seems to me that you are complaining that the "backend" implementation
   for IA64 sucked.  Okay.  Fine.  But the drivers were never exposed to
   that suckage.

No, I have in fact no problem with IA64's backend, I don't care how
any platform implements anything.  It is the front end that sucked
balls, and this part I care about because it is the APIs drivers have
to deal with.  Specifically, my gripes are:

1) It took virtual addresses.  Result: does not work on 32-bit
   platforms.

2) It did not take into consideration at all the issues surrounding
   DAC usage on some platforms, such as:

	a) transfers using DAC cycles might run slower than
	   those using SAC cycles
	b) DAC cycles may be preferred even in the presence of
	   slower transfers because the device is "DMA mapping
	   hungry" ala. compute cluster cards.

Let me ask you again: Have you tried to write a driver to the new
APIs at all?  I have for 6 totally different devices, on drivers
written by totally different people (including those I wrote myself)
and they all worked out beautifully.

Later,
David S. Miller
[e-mail]