On Mon, 30 Oct 2000, Tigran Aivazian wrote:
> On Mon, 30 Oct 2000, Richard B. Johnson wrote:
> > > So, if you don't need physically contiguous (and fast) allocations perhaps
> > > you could make use of vmalloc()/vfree() instead? There must be also some
> > > "exotic" allocation APIs like bootmem but I know nothing of them so I stop
> > > here.
> >
> > Okay. Looks like I need a linked-list so I can use noncontiguous memory.
>
> Just to remind, I was talking of physically and not just virtually
> contiguous. vmalloc will still give you a virtually-contiguous chunk. But
> if by "I need a linked-list" you mean that each node of the list may be
> talking to some hardware but the hardware won't know about the whole list,
> then you still need to use physically-contiguous allocator like
> __get_free_pages() for each data node, i.e. if your hardware actually
> needs physically contiguous chunk to talk to. Also, in this case, using
> vmalloc() to allocate just the "linkage/admin overhead" is silly, just
> using kmalloc or even creating a private slab object cache is probably a
> better idea.
>
> Regards,
> Tigran
>
If I can only get 128k bytes of RAM that is still present during
an interrupt, because of a kmalloc() limitation, then I need to
allocate multiple buffers and keep their pointers in a list, right?
It doesn't actually have to be a linked list, the buffers are
never deallocated until the module is removed.
char *ram_128k[16];
16 buffers with 128k in each.
In the interrupt, I just write to the previously-allocated 16 buffers.
In the read(), I just read from them.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:27 EST