On Sat, 2008-12-20 at 09:21 +1000, Dave Airlie wrote: > On Sat, Dec 20, 2008 at 9:19 AM, Eric Anholt <e...@anholt.net> wrote: > > On Tue, 2008-12-09 at 14:00 -0500, Ben Gamari wrote: > >> Hey everyone, > >> > >> This is the latest version of my procfs file handling patch. I have > >> ported the old proc files to use the seq_file interface greatly > >> simplifying the code. I have also put in place infrastructure for > >> exporting data through debugfs, creating a dri/ directory in the debugfs > >> root similar to procfs. I moved /proc/dri/*/vma along with all of the > >> i915_gem_* files into this directory. Like the proc code, the debugfs > >> code uses seq_file. This code has all been tested and appears to work. > >> > >> Lastly, I ported the old ring buffer dump code to the drm. This creates > >> a file in debugfs (i915_gem_ringbuf) from which the ring buffer can be > >> dumped. Currently, the code is only capable of dumping the ring buffer > >> itself. It'll probably be a few weeks before I have time to think about > >> getting batchbuffer dumping working. This is the outline I currently > >> have, > >> - Search through the active batchbuffer list looking for a batchbuffer > >> located at the offset indicated in the MI_BATCH_BUFFER_START instruction > >> - Pin this batchbuffer into memory somewhere > >> - Dump its contents > >> - Unpin > >> > >> I know practically nothing about gem at the moment, so it'll take me a > >> while to get up to speed. If someone else wants to try adding > >> batchbuffer dumping, they are more than welcome. > >> > >> At this point, I think the patch is nearing a merge-worthy point. Let me > >> know what else is needed to get it merged. > > > > Could this get split up into a step that converts the existing code to > > using seq_printf (which seems great!), a second step moving appropriate > > parts to debugfs (I'm not really sold on this), and another step adding > > the intel ring dumping (I'm very interested in this)? Then we can look > > at the individual parts of the project more easily than reviewing a > > 1700-line patch :) > > I'm all for that as well, the problem with using /proc for this stuff > is upstream > doesn't want us to use proc for this stuff. In the end we need distros > to start mounting > debugfs maybe I can start kicking some heads in that direction.
Yeah, that's my only objection to debugfs -- if I can't ask someone for /whatever/path/i/dont/care/i915_gem_interrupt and have it work, I'm sad. -- Eric Anholt e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
