Re: Vramfs: filesystem driver to utilize extra RAM on VGA devices
From: Jonathan Campbell
Date: Mon Jan 26 2009 - 18:51:39 EST
vramfs is designed to take the memory range and directly turn it into a
usable filesystem.
The structures are not actually in VRAM, but the file contents are.
Vramfs has a builtin mechanism as described to avoid conflicting with
the region in use by the framebuffer console.
I don't really know about the mtd device, but I thought it would be good
kernel coding practice to write a filesystem driver to pull off a stunt
like that.
I also wrote this in consideration of the GPU which probably wouldn't
know how to handle the fragmentation that would inevitably happen if
ext3 needed to write blocks in a non-contiguous manner, this fs enforces
the rule that files are always unbroken with only a start and length.
Also, doesn't mtd come in as a block device?
So you'd have to format the memory region using a filesystem like ext3,
right?
And as a block device you can't use mmap() to map that region directly
into your process space, right?
Jonathan Campbell wrote:
So far I've tested it against 2.6.25.17 and 2.6.28 on both x86 and
x86_64 with reads, writes, directory creation, symlink creation, and
mmap() and it seems to work fine.
Just give it a range of memory on the bus, or the
domain:bus:device:function numbers of a VGA PCI device, and it will
mount the VGA video RAM and allow files to exist there.
As a special hack: you can also specify the size of the active
framebuffer console so that fbcon doesn't collide with this driver
(unless you want to see what your files look like splattered across
your screen, ha). The active VRAM area becomes a "sentinel" file
named "framebuffer".
What do you guys think?
How is this different from the MTD driver we already have?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/