Subject: Re: allocmem in interrupt context
To: Matthew Orgass <email@example.com>
From: Iain Hibbert <firstname.lastname@example.org>
Date: 10/30/2005 11:14:42
On Sat, 29 Oct 2005, Matthew Orgass wrote:
> On 2005-10-28 email@example.com wrote:
>> and none of those approaches splvm() so memory allocations should be ok, hm?
> No, memory allocation might sleep, so it needs a process context.
I have nearly always used M_NOWAIT or M_DONTWAIT but, point taken..
relatedly, can one use tsleep from a soft interrupt context? The time has
not yet arrived, but I might sometime need to send commands in response to
events, and sending commands may sleep (because of flow control) so I'm
thinking I would have to look into replacing the soft interrupt which
currently services incoming packets with a kthread tsleep/wakeup
>> It may be (certainly is, in fact) that I am unclear on the way the USB
>> code works, documentation is minimal it seems.. not sure why the memory
>> is being allocated in there in any case, as I am providing a buffer though
>> it is not an usbd_alloc_buffer() buffer, was getting the transfer into an
>> MBUF (cluster) data area so I can just pass it off directly.
> The buffer needs to be used for DMA, so it needs to come from bus_dma
> allocation. Unless you have a usbd_alloc_buffer buffer it will allocate a
> new one.
Hm, I see.. in that case, allocating an mbuf cluster prior to the transfer
and receiving directly into it may not have been as efficient as I
imagined.. I will look at it again.
Is usb_transfer_complete() in dev/usb/usbdi.c (and hence my callback)
called in a process context? I'm thinking it would likely be a usb_task
but I can't quite figger it (ie, it would be ok to use m_copyback() in the