kernel memory char device

[MK27]

I tried to ask this question here but it was kind of veiled (...so I just have to ask it again).

I'm learning device drivers, blah blah, and one basic exercise (google "linux scull") is to write a driver for a character device where the "device" is just a chunk of kernel memory (eg. you now have a 10 mb /dev/chunk which is universally accessable, could be locked, etc). Since the driver while loaded is part of the kernel, and the write operations to the device (eg, echo "some stuff" > /dev/chunk) are coded in the module, you could actually structure this as a kind of data server directly in the the "read" and "write" functions:

ssize_t write_onedev(struct file *file, const char __user *buf, size_t count, loff_t *pos) {
	void *ptr=TOne.data+(long)*pos;
	if (TBytes-((long)ptr-(long)TOne.data)<count) count=TBytes-((long)ptr-(long)TOne.data);
	if (count<=0) { return -ECANCELED; }
	printk("testone [write] pos=%ld count=%d\n",(long)*pos,(int)count);
/* now instead of all this:
	memcpy(ptr,(const void*)buf,count); 
	*pos+=count;   // responsible for this
	TOne.sz=*pos;	// sequential/linear 
consider using the first byte as op code : */
        switch (buf[0]) {
               case (66) :  serve some data
               case (67) :  write incoming to specific area
       ...etc.
	return count;
}

I don't really have a particular use for this right now, but I was wondering
1) is this a good idea, or a bad idea and why.
2) does anyone know of any actual implementations of this?

Sincerely, Just Curious.

[brewbuck]

The problem is that data exchange between processes is already well-understood with pipes and shared memory, and device control operations are well-understood with ioctl(). I don't think your approach is bad, but it's also gratuitously un-UNIX.

[MK27]

The reason I don't "have much of a use for it" is because I don't have a need to do any of the orthodox "shared memory" things that this might conceivably replace, and IPC to me is generally short messages easily done with sockets. So it's hard for me to judge whether it would really be useful or not.

So thanks for your answer brewbuck, I think I see what you're saying.