Re: SLAB vs. pci_alloc_xxx in usb-uhci patch [RFC: API]

[David Brownell <david-b@pacbell.net>]

> > unlike the slab allocator bug(s) I pointed out.  (And which
> > Manfred seems to have gone silent on.)
> 
> which bugs?

See my previous email ...  its behavior contradicts its spec,
and I'd sent a patch.  You said you wanted kmalloc to have
an "automagic redzoning" feature, which would involve one
more change (to the flags used in kmalloc init when magic
redzoning is in effect).  I'd expected a response.


> >  * this can easily be optimized, but the best fix would be to
> >  * make this just a bus-specific front end to mm/slab.c logic.
>                ^^^^
> 
> Adding that new frond end was already on my todo list for 2.5, but it
> means modifying half of mm/slab.c.

Exactly why I think we need a usable solution changing that
half!  And why I asked for feedback about the API, not a
focus on this particular implementation.


> >  if (align < L1_CACHE_BYTES)
> >   align = L1_CACHE_BYTES;
> 
> Why?

To see who was awake, of course!  That shouldn't be there.


> > /* Convert a DMA mapping to its cpu address (as returned by pci_pool_alloc).
> >  * Don't assume this is cheap, although on some platforms it may be simple
> >  * macros adding a constant to the DMA handle.
> >  */
> > extern void *
> > pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle);
> 
> Do lots of drivers need the reverse mapping? It wasn't on my todo list
> yet.

Some hardware (like OHCI) talks to drivers using those dma handles.

- Dave