On 06 Sep 2000 13:54:49 +0800
Ryan Cumming <[EMAIL PROTECTED]> wrote:
>> 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 bo
> 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 t
On Thu, 31 Aug 2000 14:09:48 +0200 (CEST)
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> On Thu, 31 Aug 2000, Alan Cox wrote:
>> We then just follow the bios. You can also reserve blocks of
>> memory by hacking arch/i386/mm/init.c and marking them reserved
> in 2.4 there is an explicit interface for
> Yeah, that's what I'm looking at right now: how early I have to get
> in to be safe.
For 2.2 arch/i386/mm/init.c
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Thu, 31 Aug 2000 17:12:03 +0100 (BST)
Alan Cox <[EMAIL PROTECTED]> wrote:
>> Now the device behaves just like memory to the BIOS during POST
>> etc, and is in fact, exactly memory if no device drivers are
>> loaded. If a device driver is loaded and it detects one or more
>> of these devices
On Thu, 31 Aug 2000 11:32:21 -0500
Timur Tabi <[EMAIL PROTECTED]> wrote:
> ** Reply to message from [EMAIL PROTECTED] on Thu, 31 Aug 2000
> 08:57:20 -0700
>> Now the device behaves just like memory to the BIOS during POST
>> etc, and is in fact, exactly memory if no device drivers are
>> loaded
** Reply to message from [EMAIL PROTECTED] on Thu, 31 Aug 2000 08:57:20 -0700
> Now the device behaves just like memory to the BIOS during POST
> etc, and is in fact, exactly memory if no device drivers are loaded.
> If a device driver is loaded and it detects one or more of these
> devices then
** Reply to message from Ingo Molnar <[EMAIL PROTECTED]> on Thu, 31 Aug 2000
14:09:48 +0200 (CEST)
> in 2.4 there is an explicit interface for this that also guarantees that
> the allocation consists of fully valid RAM (no matter how complex the RAM
> map): alloc_bootmem(). We allocate 300MB+ wo
> Now the device behaves just like memory to the BIOS during POST
> etc, and is in fact, exactly memory if no device drivers are loaded.
> If a device driver is loaded and it detects one or more of these
> devices then they and their memory ranges become obviously special.
> Now, we can detect t
On Thu, 31 Aug 2000 10:54:56 +0100 (BST)
Alan Cox <[EMAIL PROTECTED]> wrote:
>> I'm working on a device driver for a device that sits on the PC
>> memory bus. I need to reserve/protect the memory range that the
>> device occupies from the rest of the kernel/system. How do I do
>> that? I thin
On Thu, 31 Aug 2000, Alan Cox wrote:
> We then just follow the bios. You can also reserve blocks of memory by
> hacking arch/i386/mm/init.c and marking them reserved
in 2.4 there is an explicit interface for this that also guarantees that
the allocation consists of fully valid RAM (no matter ho
> I'm working on a device driver for a device that sits on the PC
> memory bus. I need to reserve/protect the memory range that the
> device occupies from the rest of the kernel/system. How do I do
> that? I think I see how I can mark blocks that are never to be
> touched, but in this case the
Em Wed, Aug 30, 2000 at 03:42:15PM -0700, J C Lawrence escreveu:
> Alan,
>
> I'm working on a device driver for a device that sits on the PC
> memory bus. I need to reserve/protect the memory range that the
> device occupies from the rest of the kernel/system. How do I do
> that? I think I see
Alan,
I'm working on a device driver for a device that sits on the PC
memory bus. I need to reserve/protect the memory range that the
device occupies from the rest of the kernel/system. How do I do
that? I think I see how I can mark blocks that are never to be
touched, but in this case the dr
14 matches
Mail list logo
