I've volunteerded to clean up the bigphysarea patch for inclusion in
the standard kernel.
I had more gripes with the code as it was before. It seems to have
had a cleanup already.
I grabbed it from:
http://www.uni-paderborn.de/fachbereich/AG/heiss/linux
To (re-)design such a beast, we first need to look at the interface.
kernel commandline option:
bigphysarea=1024
-> Allocate 1Mb of bigphysarea.
Change to existing patch: that one works in "pages". What's a page anyway?
Allocate a region:
caddr_t bigphysarea_alloc (int count, int align, int priority)
"count" is the number of bytes you need.
"align" the returned area will be aligned to a multiple of this number
of bytes.
"priority" is GFP_... priority to use for kmalloc requests from within
this routine.
This routine should be interrupt safe. (is very similar to "SMP
safe".)
Currently there is a ..._pages that has these arguments (which works
in number of pages) and one that's called as above, which works in
bytes, but you don't get to align the result.
Free a region:
void bigphysarea_free(caddr_t addr)
Change to the existing patch: no longer need to pass around the
"size".
Allow calling from interrupts.
performance:
initialization should be done in one go. Why the two-step approach?
name:
to allow drivers to interface with this patch and with the "new"
one, it would be better to change bigphysarea into something else.
That would allow "compatibility" defines. Suggestions welcome.
Future work:
If this is cleaned up, I'll make SCSI - generic use this. Something
like:
if (big_buff == NULL) {
big_buff = kmalloc (SG_BIG_BUFF, GFP_KERNEL);
#ifdef CONFIG_BIGPHYS_AREA
if (!big_buff) {
big_buff = bigphysarea_alloc (SG_BIG_BUFF, 0x1000, GFP_KERNEL);
}
#endif
if (!big_buff) {
/* Oops we're in trouble couldn't get the buffer */
return -ENOMEM
}
}
that should satisfy all of us with scanners that don't handle many
small requests the same as one large one....
This allows you to share the bigphysarea between your frame grabber
and the SG code. Does ftape still sometimes run out of memory? It
could fall back on bigphysarea if the allocations fail.
Regards,
Roger Wolff.
-- If it's there and you can see it, it's REAL |___R.E.Wolff@BitWizard.nl | If it's there and you can't see it, it's TRANSPARENT | Tel: +31-15-2137555 | If it's not there and you can see it, it's VIRTUAL |__FAX:_+31-15-2138217 | If it's not there and you can't see it, it's GONE! -- Roy Wilks, 1983 |_____|- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu