kernel memory char device

MK27 · 05-01-2009, 06:01 AM

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:

Code:

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 · 05-01-2009, 10:37 AM

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 · 05-02-2009, 06:42 AM

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.

05-01-2009, 06:01 AM	#1
MK27 critical genius Join Date: Jul 2008 Location: SE Queens Posts: 5,230	kernel memory char device 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: Code: 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. __________________ "A man can't just sit around." -- Larry Walters
MK27 is offline

05-01-2009, 10:37 AM	#2
brewbuck Senior software engineer Join Date: Mar 2007 Location: Portland, OR Posts: 5,768	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. __________________ "Congratulations on your purchase. To begin using your quantum computer, set the power switch to both off and on simultaneously." -- raftpeople@slashdot
brewbuck is offline

05-02-2009, 06:42 AM	#3
MK27 critical genius Join Date: Jul 2008 Location: SE Queens Posts: 5,230	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. __________________ "A man can't just sit around." -- Larry Walters
MK27 is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Another syntax error	caldeira	C Programming	31	09-05-2008 01:01 AM
Code review	Elysia	C++ Programming	71	05-13-2008 09:42 PM
Sorting Linked Lists	DKING89	C Programming	6	04-09-2008 07:36 AM
Strings are V important...	NANO	C++ Programming	15	04-14-2002 11:57 AM