In message <1141333882.320998.885.nullmailer@galant.ukfsn.org>,
Iain Hibbert writes:


>On Wed, 1 Mar 2006, Hubert Feyrer wrote:
>
>> what I wonder is what the benefits of this new USB stack is,
>
>is this completely new, rewritten or just tidied up?
>
>> and what drawbacks the existing one is supposed to have that justifies
>> replacing a working piece of software. And some estimate if it's really
>> easier to replace than to fix.
>
>One thing that I think is very important is that the current USB code has
>no documentation and its quite difficult to understand at first sight.

True.  But then again, candidate replacement code which exposes
"physical addresse" and exports "physical addresses" within itself, is
simply not workable in a NetBSD machine-independent driver.

I haven't seen Hans Petter's acutal reply, just the snippet quoted by
Izumi Tsutsui, which I quote below:


In article <200603020740.17621.hselasky@c2i.net>
hselasky@c2i.net wrote:

> Yes, it is just for convenience. The function should return the physical 
> address relative to the parenting PCI bus, which the hardware is on, which 
> should be programmed into the hardware.

which gives this reader, at least, very serious concerns about whether
or not Hans Petter has grasped bus_dma(9), or grasped what's required
of a machine-independent NetBSD driver.

For the non-NetBSD readers: a machine-independnet NetBSD driver *has*
to start with the assumption that bus DMA is going through an IOMMU;
that the IOMMU needs setup and teardown before and after each DMA
operation; that the "bus addresses" fed into that IOMMU need not have
any linear correspondence to system physical addresses; and that all
the state for the IOMMU bus-mapping is opaquely encapsulated inside a
bus_dmamp_t, which is an opaque mapping, manipulated in a vaguely
class-like and bus-depenent way, by the corresponding bus_dma_tag_t.

If you start to even *think* of that bus_dmamap_t as the result of a
vtophys(), then you've already lost.