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.
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.
I have one, but is is a scanner simulator. The sacrifice of hardware was
done for the low cost and low volume.
The problem to be solved by bigphysarea is that of unusual devices that
consume unusual amounts of contiguous physical memory. A little bit of user
cooperation makes good sense anyhow.
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? The disadvantage here is that the
mem= parameter and a module parameter must match, though it might be
possible to use the mem= parameter and let the bigphysarea module autodetect
the top. Hm...
-- Steve Williams "The woods are lovely, dark and deep. steve@icarus.com But I have promises to keep, steve@picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."
- 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/