[lkml]   [2009]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Vramfs: filesystem driver to utilize extra RAM on VGA devices
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...)


> 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 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
> > More majordomo info at
> > Please read the FAQ at
> >
> >
> _______________________________________________
> devel mailing list

 \ /
  Last update: 2009-01-29 18:07    [from the cache]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site