linux-kernel - Vramfs: filesystem driver to utilize extra RAM on VGA devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 26 Jan 2009 15:20:17 -0800
From:	Jonathan Campbell <jon@...dgrounds.com>
To:	Linux Kernel List <linux-kernel@...r.kernel.org>
CC:	devel@...verdev.osuosl.org
Subject: Vramfs: filesystem driver to utilize extra RAM on VGA devices

Hey guys.
About a month ago while covered in the Seattle snowstorm I hacked 
together this pseudofilesystem that might be of interest.

I thought that this driver could solve two issues that I have:

one, that today's graphics cards have relatively obscene amounts of RAM 
on them even if you're not using it. If you're running it as a server 
and not using it for 3D graphics, why not mount the VRAM on the graphics 
card as a filesystem and store things there to get some extra space?

two, if 3D hardware acceleration and access to GPU or texture memory 
could be provided to user-space, one way to do it would be to provide 
sections of VRAM as a filesystem that most languages (yes---even Perl!) 
could use to work with todays graphics cards. They could treat the 
texture memory the way they treat files in /dev/shm: read/write it for 
general access or mmap it for direct manipulation. At least, it makes 
far more sense to me from a programming point of view than to abstract 
it using specialized ioctls through the DRI. It might make writing an 
OpenGL driver for this kind of arrangement cleaner, too.

http://www.nerdgrounds.com/vramfs-20090126-1458.tar.gz

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?

Jonathan Campbell
Impact Studio Pro

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/