o Implement /dev/graphics virtualizable access to

	  registers.  The actual context switch code is not
	  yet there.  But the rest of the magic (mapping/unmapping
	  the registers on demand is already in).

	o Interface for allowing binary-only console modules added.

	o My RRM bits, nothing really interesting now.

For now, I am assuming in the code that there will be a minor per
real graphics device, and that the X server will go and open
/dev/graphicsN instead of opening /dev/graphics and using the
gfx_attach_board->board variable.

The interface the X server uses is not clear.

I believe it will be pretty easy to provide the stripped down
shmiq interface.  Not only that, but we can even provide the
same ABI (yes, ABI) for SGI shmiq input modules (yep, looks
pretty easy once you have an strace that shows this information).

Now, the only thing missing is figuring what is wrong my current
conception of the use of shmiq.  I just can't get it.

1 files changed, 17 insertions, 6 deletions

diff --git a/drivers/sgi/char/graphics.h b/drivers/sgi/char/graphics.h
index 6a26e785d..a0477df1e 100644
--- a/drivers/sgi/char/graphics.h
+++ b/drivers/sgi/char/graphics.h
@@ -1,12 +1,23 @@
 #define MAXCARDS 4
 
 struct graphics_ops {
-	struct task_struct *owner;
+	/* SGIism: Board owner, gets the shmiq requests from the kernel */
+	struct task_struct *g_owner;
 
-	/* Board info */
-	void *board_info;
-	int  board_info_len;
+	/* Last process that got the graphics registers mapped  */
+	struct task_struct *g_user;
 	
-	void (*save_context)(void);
-	void (*restore_context)(void);
+	/* Board info */
+	void               *g_board_info;
+	int                g_board_info_len;
+
+	/* These point to hardware registers that should be mapped with
+	 * GFX_ATTACH_BOARD and the size of the information pointed to
+	 */
+	unsigned long      g_regs;
+	int                g_regs_size;
+
+	void (*g_save_context)(void);
+	void (*g_restore_context)(void);
 };
+