Re: [RFT][PATCH] generic device DMA implementation

Re: [RFT][PATCH] generic device DMA implementation

[Adam J. Richter]

Odd number of ">" = David Brownell
Even number of ">>" = Adam Richter

>[...] This [DMA mapping operations] needs to work on more than
>just the "platform bus"; "layered busses" shouldn't need special casing,
>they are just as common. 

	It is not necessarily the case that every non-DMA device has
nexactly one DMA device "parent."  You can have SCSI devices that are
multipathed from multiple scsi controllers.  Software RAID devices can
drive multiple controllers.  Some devices have no DMA in their IO
paths, such as some parallel port devices (and, yes, there is a
parallel bus in that you can daisy chain multiple devices off of one
port, each device having a distinct ID).  If drivers are explicit
about which DMA mapped device they are referring to, it will simplify
things like adding support for multipath failover.

	On the other hand, it might be a convenient shorthand be able to
say dma_malloc(usb_device,....) instead of
dma_malloc(usb_device->controller, ...).   It's just that the number of
callers is small enough so that I don't think that the resulting code
shrink would make up for the size of the extra wrapper routines.  So,
I'd rather have more clarity about exactly which device's the DMA
constrains are being used.

	By the way, one idea that I've mentioned before that might
help catch some memory alocation bugs would be a type scheme so that
the compiler could catch some of mistakes, like so:

/* PCI, ISA, sbus, etc. devices embed this instead of struct device: */
struct dma_device {
	u64		dma_mask;
	/* other stuff? */

	struct device	dev;
};

void *dma_malloc(struct dma_device *dma_dev, size_t nbytes,
		 dma_addr_t *dma_addr, unsigned int flags);


	Also, another separate feature that might be handy would be
a new field in struct device.

struct device {
	....
	struct dma_device *dma_dev;
}

	device.dma_dev would point back to the device in the case of PCI,
ISA and other memory mapped devices, and it would point to the host
controller for USB devices, the SCSI host adapter for SCSI devices, etc.
Devices that do fail over might implement device-specific spinlock to
guard access to this field so that it could be changed on the fly.

	So, for example, the high level networking code could embed
could conslidate mapping of outgoing packets by doing something like:

	skbuff->dma_addr = dma_map_single(netdev->dev->dma_dev,
			                  skbuff->data, ...)

	...and that would even work for USB or SCSI ethernet adapters.

	

>You had mentioned SCSI busses; USB, FireWire,
>and others also exist.  (Though I confess I still don't like BUG() as a
>way to fail much of anything!)

	BUG() is generally the optimal way to fail due to programmer
error, as opposed to program error.  You want to catch the bug as
early as possible.  If you have a system where you want to do
something other exiting the current process with a fake SIGSEGV (say
you want to try to invoke a debugger or do a more graceful system call
return), you can redefine BUG() to your liking.  Writing lots of code
to carefully unwind programmer error usually leads to so much more
complexity that the overall effect is a reduction in reliability, and,
besides, you get into an infinite development cycle of trying to
recover from all possible programmer errors in the recovery code, and
then in the recovery code for the recovery code and so on.

>Please look at the 2.5.53 tree with my "usbcore dma updates (and doc)"
>patch, which Greg has now merged and submitted to Linus.

	This looks great.  Notice that you're only doing DMA
operations on usb_device->controller, which is a memory-mapped device
(typically PCI).

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

Re: [RFT][PATCH] generic device DMA implementation

[David Brownell]

Adam J. Richter wrote:
 > Odd number of ">" = David Brownell
 > Even number of ">>" = Adam Richter

Toggle that one more time ... ;)

 >
 > 	On the other hand, it might be a convenient shorthand be able to
 > say dma_malloc(usb_device,....) instead of
 > dma_malloc(usb_device->controller, ...).   It's just that the number of
 > callers is small enough so that I don't think that the resulting code
 > shrink would make up for the size of the extra wrapper routines.  So,

Since about 2.5.32 that API has been

     void *usb_buffer_alloc(usb_device *, size, mem_flags, dma_addr_t *)

Sure -- when dma_alloc() is available, we should be able to make it
inline completely.  Done correctly it should be an object code shrink.


 > struct device {
 > 	....
 > 	struct dma_device *dma_dev;
 > }
 >
 > 	device.dma_dev would point back to the device in the case of PCI,
 > ISA and other memory mapped devices, and it would point to the host
 > controller for USB devices, the SCSI host adapter for SCSI devices, etc.

With 'dma_device' being pretty much the 'whatsit' I mentioned:  some state
(from platforms that need it, like u64 dma_mask and maybe a list of pci
pools to use with dma_malloc), plus methods basically like James' signatures
from 'struct bus_dma_ops'.

Yes, that'd be something that might be the platform implementation (often
pci, if it doesn't vanish like on x86), something customized (choose dma
paths on the fly) or just BUG() out.


 > 	BUG() is generally the optimal way to fail due to programmer
 > error, as opposed to program error.  You want to catch the bug as
 > early as possible.

I can agree to that in scenarios like relying on DMA ops with hardware
known not to support them.  If it ever happens, there's deep confusion.

But not in the case of generic dma "map this buffer" operations failing
because of issues like temporary resource starvation; or almost any
other temporary allocation failure that appears after the system booted.


 >>Please look at the 2.5.53 tree with my "usbcore dma updates (and doc)"
 >>patch, which Greg has now merged and submitted to Linus.
 >
 > 	This looks great.  Notice that you're only doing DMA
 > operations on usb_device->controller, which is a memory-mapped device
 > (typically PCI).

Actually it isn't necessarily ... some host controllers talk I/O space
using FIFOs for commands and data, rather than memory mapping registers,
shared memory request schedules, and DMAing to/from the kernel buffers.
Linux would want a small tweak to support those controllers; maybe it'd
be as simple as testing whethere there's a dma_whatsit object pointer.

The usb_buffer_*map*() calls could now be inlined, but I thought I'd rather
only leave one copy of all the "don't go through null pointer" checking.
If we ever reduce such checking in USB, those routines would all be
good candidates for turning into inlined calls to dma_*() calls.

- Dave

[2.5.52] NFS works with 2.4.20, not with Win2K/SFU

[Scott Robert Ladd]

Heck if I know whose bug this is...

One of my systems runs kernel 2.5.52; its NFS shares mount fine with my
2.4.20 system, and the 2.4.20 shares mount properly on the 2.5.52 system.
All's happy in Linuxland.

Unfortunately, Windows is *not* happy. My system using Windows 2000
w/"Services for Unix" can mount the NFS exports from the 2.4.20 machine --
but while the Win2K box can *see* the 2.5.52 shares, it suffers terribly
when trying to mount them -- sometimes locking up, sometimes telling me the
share can't be found.

Another oddity: The Win2k machine sees the 2.4.20 system by IP address, and
the 2.5.52 system by name.

I have the 2.5.52 kernel compiled for NFS4. Both the 2.5.52 system and
2.4.20 have identical /etc/exports and /etc/hosts.

I'm quite willing to lay this in the lap of those jolly folk in Redmond, but
I was wondering if anyone knew of incompatibility between 2.5.52 NFS and
Win2K/SFU.

..Scott

--
Scott Robert Ladd
Coyote Gulch Productions,  http://www.coyotegulch.com
No ads -- just very free (and somewhat unusual) code.

Re: [2.5.52] NFS works with 2.4.20, not with Win2K/SFU

[J Sloan]

No telling what kind of odd bugs could be in
ms services for unix, I was not at all impressed
with what I saw of it at Linux world last Aug -
It seemed to be mostly a broken toy...

My experience suggests that you'll have much
better luck using samba for your unix-to-pc
connectivity needs.

Just a thought,

Joe

Scott Robert Ladd wrote:

>Heck if I know whose bug this is...
>
>One of my systems runs kernel 2.5.52; its NFS shares mount fine with my
>2.4.20 system, and the 2.4.20 shares mount properly on the 2.5.52 system.
>All's happy in Linuxland.
>
>Unfortunately, Windows is *not* happy. My system using Windows 2000
>w/"Services for Unix" can mount the NFS exports from the 2.4.20 machine --
>but while the Win2K box can *see* the 2.5.52 shares, it suffers terribly
>when trying to mount them -- sometimes locking up, sometimes telling me the
>share can't be found.
>
>Another oddity: The Win2k machine sees the 2.4.20 system by IP address, and
>the 2.5.52 system by name.
>
>I have the 2.5.52 kernel compiled for NFS4. Both the 2.5.52 system and
>2.4.20 have identical /etc/exports and /etc/hosts.
>
>I'm quite willing to lay this in the lap of those jolly folk in Redmond, but
>I was wondering if anyone knew of incompatibility between 2.5.52 NFS and
>Win2K/SFU.
>
>..Scott
>
>--
>Scott Robert Ladd
>Coyote Gulch Productions,  http://www.coyotegulch.com
>No ads -- just very free (and somewhat unusual) code.
>
>-
>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/
>
>  
>

RE: [2.5.52] NFS works with 2.4.20, not with Win2K/SFU

[Scott Robert Ladd]

> My experience suggests that you'll have much
> better luck using samba for your unix-to-pc
> connectivity needs.

I'm already using Samba; however, since most of my network is Linux-based
with NFS shares, it seemed reasonable to try and use NFS for everything. I
dislike creating two access points (NFS and Samba) for the same share -- but
then again, I probably over-estimated the ability of Windows.

..Scott