lkml.org 
[lkml]   [2000]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Reserving a (large) memory block
From
Date

> I have a device that sits on the memory bus. It looks like RAM
> until a (module) device driver gets at it. At that point I want it
> to be reserved memory (private to driver). Now I can do this in
> init if I know the location of the device in memory and its size.
> The problem is that to detect the device(s) and their size I use the> i2c and smbus modules. Ergo, to reserve the physical memory I need
> a kernel which is pretty well fully booted (ie the heap etc is
> already built) so I can load those modules and find
the devices,
> which means that grabbing and reserving bits of physical memory is
> unsafe (because the heap etc is already built). However, if I had
> access to the filesystem at init time, I could go read a file that
> told me where the device(s) are and how big they are, do the
> reservations, and then have the module double check the reservations
> against the reality of what's installed.
>
> Problem is: I don't (think I) have filesystem access at init time,
> and can't safely reserve specific physical memory after init which
> seems to leave my only option being to pass in the reservation specs
> from the bootloader, which is what rather I'm trying to avoid.
>
> Or am I missing something?

Possibly... would it be pratical to have part of the module kernel
resident, and the pull its memory location/size off the kernel command
line? Something like memdevice0_mem_start=0xdeadbeef
memdevice0_mem_size=0xf00f? This would avoid crazy filesystem kludges,
but may not be practical for usability reasons...

-Ryan
-
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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.038 / U:3.508 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site