Pauline Middelink wrote:
>On Sun, 05 Aug 2001 around 13:51:37 +0300, Constantine Gavrilov wrote:
>
>>Hi,
>>
>>I wrote a small kernel module that defines and exports bfree() and
>>bmalloc() functions. The idea is to use this kernel module as a
>>replacement for big physcial area kernel patch.
>>
>
>Ahum, but this is _not_ a kernel replacement for the bigphysarea
>patch. If also requires the patch to be integrated in the main-stream
>kernel. Following your reasoning you could just as well get Linus
>to accept the bigphysarea patch and voila, all the problems you
>describe are gone.
>
You missed the point here. Of course big physical area is preferrable
and it is guaranteed to work for larger pre-allocations as well. If you
ask me, I am for big physical area API in the Linus kernel. It is a
clean drop-in and will not touch anything. Advantages are obvious, of
course. And no, this code does not require modifications to the kernel
source since it is a module. I do not have to re-compile the kernel with
a big physical area api, I just need to compile a module against the
kernel I have. The idea here is if I ship a 3-d party module that
requires contiguous memory support, I can add this code to the source of
the module and it will work with the distribution kernels. The idea is
to allow the 3d party (or included) modules to work with non-patched
distribution kernels.
>>For example, zoran kernel driver relies on the big physical area API for
>>v4l (used for video-in-a-window) to work. While the driver will compile
>>and load with a non-patched kernel, v4l will not work reliably without
>>big physical area support since the chip needs about 2megs of contiguous
>>memory to display in a window. This means one really has to use a
>>patched kernel.
>>
>
>Check, or load the zoran module very early in the boot process.
>
For Zoran case, loading early will not really help because memory is not
allocated unil one opens /dev/video. However, this can be easily fixed.
In any case, I want to be able to load/unload my card drivers. Our usage
of VPXpress cards based on Zoran chips requires that. So, the module
pre-allocating the ememory is more flexible.
>
>Wasn't it easier to just take bigphysarea and made a module out
>of it? It seems you already took a lot of the code, so why not
>take the last step?
>
I used some code from Zoran driver and none from the big physical area
patch (please see below). The code re-implements bfree() and balloc()
interfaces that Zoran driver uses. It is the bree() and balloc()
functions in Zoran driver that my module re-implemented that were using
the big physical area functions. I got myself confused somewhat. To
call it a big physical area replacement, I had to implement
bigphysarea_alloc, bigphysarea_free, bigphysarea_alloc_pages,
bigphysarea_free_pages and possibly add the proc support. I can still do
that.
>>I have left the user-mode code that I used to debug allocation and
>>garbage collection. Compiled into a user-space program, the code will
>>allocate/free random chunks from a pre-allocated space and print out the
>>used list.
>>
>
>/proc/bigphysarea?
>
What good does it make if you your garbage collection structures get
corrupted and kernel oopses?
>
>Eh, if you insist of using this much of the bigphysarea ideas,
>you could at least give us some credit/mention?
>
>> email : linux@optibase.com
>>
>
> Met vriendelijke groet,
> Pauline Middelink
>
Well, duly noted. Everyone knows what big physical area API is and who
supports it. Is it not so? I did not mean to rob you of credit. I do use
ideas of big physical area API, but no code was used from the patch
itself. The sample pre-allocation and release code was taken from YOUR
Zoran driver. This is what I use from your code in my init_module():
................................................
reserve_start = (unsigned
long)__get_free_pages(GFP_USER|GFP_DMA,get_order(size));
if (reserve_start) {
adr = reserve_start;
while (size > 0) {
mem_map_reserve(virt_to_page(phys_to_virt(adr)));
adr += PAGE_SIZE;
size -= PAGE_SIZE;
}
}
....................................................
And this is what I use from your code in my cleanup_module():
.....................................................
if (reserve_start) {
adr = reserve_start;
size = reserve * PAGE_SIZE;
while (size > 0) {
mem_map_unreserve(virt_to_page(phys_to_virt(adr)));
adr += PAGE_SIZE;
size -= PAGE_SIZE;
}
free_pages(reserve_start,get_order(reserve * PAGE_SIZE));
}
.......................................................
The rest basically is the play with data structures. Yes, I do
re-implement bfree() and balloc(). In your Zoran driver, these
functions were defined to use bigphysarea_alloc_pages and
bigphysarea_free_pages interfaces from big physical area patch that you
maitain for the new kernels. I have done it in order to allow the use of
drivers that rely on this patch with non-patched kernels. I did this
work for the possible inclusion into the future drivers for our Xpress
cards. These cards use Zoran chips and we have used your driver code. We
have given you due credit in the driver source and in the documentation
(for example, see http://www.optibase.com/linux/docs.asp).
-- ---------------------------------------- Constantine Gavrilov Linux Leader Optibase Ltd 7 Shenkar St, Herzliya 46120, Israel Phone: (972-9)-970-9140 Fax: (972-9)-958-6099 ----------------------------------------- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 07 2001 - 21:00:34 EST