lkml.org 
[lkml]   [1998]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: NT DDK vs. Linux DDI, a practical comparison [long]
Date

>o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s said:
>> That's not a particularly good solution, because it requires
>> user intervention to make it work, and in the grand tradition
>> of the lilo >64mb hack, it leaves a wonderful opportunity to
>> see just how the machine can not work the way you want it to
>> if you add or subtract memory.

Steve:
>It is not too bad a solution after all, as the bigphysarea patch takes
>a lilo parameter as well, and so requires user interaction. I think this
>is not unreasonable as such devices need not be considered mainstream.

Yup.

>The ideal solution might be to use the mem parameter to shave off some
>excess memory, then make a bigphysarea allocator into a module. Perhaps
>Alessandro's code would do the job?

Yes, that's it.

>[...] it might be possible to use the mem= parameter and let
>the bigphysarea module autodetect the top.

It's easy to detect where RAM ends, just write and check back :)
I know of one person using several frame grabbers doing contiguous DMA
by means of my allocator module.

Unofrtunately, It's not updated to 2.[12], the current version is 2.0 only.

Best
/alessandro

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.032 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site