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/