On Mon, 2009-01-26 at 15:50 -0800, Jonathan Campbell wrote: > 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. > How do you accomplish that? (I haven't yet looked at your code...) -PWM > 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 at vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > > _______________________________________________ > devel mailing list > devel at linuxdriverproject.org > http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
