From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Wed, 12 May 1999 16:34:24 -0700 (PDT)

Re: MMIO accel with kgicon drivers.

On Wed, 12 May 1999, Marcus Sundberg wrote:

> Jon M. Taylor wrote:
> > 
> > On Tue, 11 May 1999, Marcus Sundberg wrote:
> > > Proc entries can have a struct file_operations associated with them,
> > > so they can basicly do everyting a device node can do.
> > > But another (and IMHO more suitable) alternative is the devfs
> > > filesystem which will hopefully go into early 2.3 kernels.
> > > I've been using devfs for the last months and it's really nice.
> > 
> >         What is the effective functional difference between dynamically-created
> > /proc entries and devfs entries?  Other than devfs is supposed to be
> > backwards-compatible with existing /dev-using code....
> 
> None I'd guess, but it seems more apropriate to have devices in /dev.

	I'm kinda bummed that devfs didn't make it into 2.2, but since the
equivalent capabilities are available with procfs I guess I will just use
that for now.  In fact I see that the current KGIcon system handles the
monitor driver that way.  The notion of dynamic device nodes is IMHO a very
powerful and very useful one.  I worked with a very senior OS engineer at
NEC, and after describing KGI, etc to him, he brought up the idea of a
'vnode' interface as some other commercial unices have.  He was referring to
basically the same ideas we are discussing here, except that vnodes go a bit
further and basically allow you to attach new _filesystems_ at each entry
point, which is overkill for our purposes because we are just dealing with
device nodes.

	If you can represent your device nodes as arbitrarily-deep directory
trees which can contain anything at all, instead of single nodes with fixed
interfaces, you now have the ability to represent all possible abstraction
levels of anything that can be represented as a device node - which in Unix
is just about everything!  This sort of system would be VERY useful for
KGI[con], because the capabilities of the hardware that we abstract can vary
so widely.  If we had the ability to hierarchically abstract all features,
features sets/subsets and the relationships between these abstractions, we
could do _anything_:

/dev/kgi/info
/dev/kgi/card0/info
/dev/kgi/card0/fbdev-interface
/dev/kgi/card0/xaa-interface
/dev/kgi/card0/opengl-interface
/dev/kgi/card0/video4linux-interface
/dev/kgi/card0/ramdac/info
/dev/kgi/card0/ramdac/streams/stream-0-ctrl

...etc...

	So, from the highest general level of device abstraction (terminals,
consoles, even X) to the lowest device-specific stuff (STREAMS, 3D accels,
video, back massager attachment |->, etc), all capabilities of any device or
device subsection can be fully exposed and abstracted **without affecting the
interfaces which expose the features of other device abstractions**. 
Interfaces could be connected simply by establishing virtual symlinks within
the devfs system:

/dev/fb0 -> /dev/kgi/card0/fbdev-interface
/dev/kgi/head0/monitor -> /dev/kgi/monitor0

...etc...

	...and the best part is that all of this is completely in line with the
'everything is a file' paradigm that is at the core of Unix.  In fact, since
the devfs file system is virtual, each head could see a different /dev tree
layout!  No more con2fbmap-type stuff - every process only sees /dev/fb,
which could be mapped to a physical or virtual framebuffer arbitrarily.  
The possibilities of such a system are almost limitless.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed