> 	What's the deal with /dev/grf? I downloaded the 
> views package and it seems most of them are just stubs
> to the grf code. I thought someone said that /dev/grf is
> leaving? 

I wrote the stuff with no grf in mind so I named things grfxxx()
Alas it wasn't enough. Point being that all those calls to grfxxx() 
are calls to functions in grfabs*.[ch] and are not /dev/grf? functions.

/dev/grf won't ever leave unless /dev/view is expanded enough to handle
odd things like banked devices with text modes and such.

> 	Anyways, about blitting and such. I'd like to
> see ioctls on the view device for all accelerated graphics
> functions. We will regret not putting them in there once 'true'
> accelerators come out for the amiga. (like the S3 chipset)

I agree.

> try the /dev/view ioctls and if there is an ENOSUP or something
> it would do the regular 'cfb' routines.

Like I said the calls should be made and succeed always that way 
the ddx layer doesn't need to worry about it.  /dev/view should support
default CPU related functions to fill in for missing blitter capabilities
in the specific graphic board.

> 	I would love to help out with this stuff. 
> 
> 	How does one allocate memory in the NETBSD kernel?
> How about Linux? 

one way is with malloc()..

> 	Lastly, is there a latest version of the views device
> (that doesn't use grf) on the net somewhere? IF not, where are
> the latest NEtBSD kernel sources?

As pointed out above, views were never based on /dev/grf.

> 	-Phil

Chris.

------------------------------------------------------------------------------