May 2011 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

if cdev_add() fails, do you need to "put" the cdev's kobject?
by Robert P. J. Day May 4, 2011

May 4, 2011

still perusing various drivers to use as examples in class, and i ran across this snippet in the load routine of drivers/char/raw.c: ===== start excerpt ===== cdev_init(&raw_cdev, &raw_fops); ret = cdev_add(&raw_cdev, dev, MAX_RAW_MINORS); if (ret) { kobject_put(&raw_cdev.kobj); goto error_region; } ===== end ===== of course it's wise to check the return code from cdev_add() to make sure it worked, but is it really necessary to call kobject_put() there? i don't recall other character drivers calling that if they note that cdev_add() failed. it's probably harmless, but it can't be necessary, can it? unless that driver is doing something unusual somewhere else in its code. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 2

need help with my first device driver
by Prashant Shah May 3, 2011

May 3, 2011

Hi, I am trying to write a comedi (drivers/staging/comedi) based driver for the National Instruments USB 6008 USB based data acquisition card. I have created a basic but more simpler structure for the drivers based on usbdux driver which are already present. I have got to the point where the device is detected and drivers are loaded. The /dev/comedi0 device file is created. I am unable to deal with the data transfer. When I try to run xoscope that is used to read the output from the card - the card freezes (the status lights stop blinking). Output from the lsusb : https://github.com/prashants/temptest/blob/8e81e7fb4ea260fa24e68f43c185d768… Source of the driver : https://github.com/prashants/temptest/blob/8e81e7fb4ea260fa24e68f43c185d768… Device : http://sine.ni.com/nips/cds/view/p/lang/en/nid/201986 I am not interested in the digital input/output and analog output at this point. My main concern is the ability to read the analog input. ---------------------------------------------------- Apr 29 14:56:43 prashant kernel: [ 1503.900700] usb 2-1.2: new full speed USB device using ehci_hcd and address 6 Apr 29 14:56:43 prashant kernel: [ 1504.172214] comedi: version 0.7.76 - http://www.comedi.org Apr 29 14:56:43 prashant kernel: [ 1504.174688] comedi: ni_usb6008: init_ni_usb6008 Apr 29 14:56:43 prashant kernel: [ 1504.174692] ni_usb6008: v2.4:Stirling/ITL USB-DUX -- Bernd.Porr(a)f2s.com Apr 29 14:56:43 prashant kernel: [ 1504.174708] comedi: ni_usb6008: ni_usb6008_probe Apr 29 14:56:43 prashant kernel: [ 1504.174711] comedi_: ni_usb6008_: finding a free structure for the usb-device Apr 29 14:56:43 prashant kernel: [ 1504.174959] comedi0: ni_usb6008: has been successfully initialised. Apr 29 14:56:43 prashant kernel: [ 1504.174990] usbcore: registered new interface driver ni_usb6008 Apr 29 14:56:43 prashant kernel: [ 1504.176558] comedi: ni_usb6008: ni_usb6008_firmware_request_complete_handler Apr 29 14:56:43 prashant kernel: [ 1504.176592] comedi: ni_usb6008: ni_usb6008_attach Apr 29 14:56:43 prashant kernel: [ 1504.176593] comedi0: ni_usb6008 0 is attached to comedi. Apr 29 14:56:43 prashant kernel: [ 1504.176595] comedi0: ni_usb6008: attached to ni_usb6008. Apr 29 14:56:43 prashant kernel: [ 1504.176634] comedi_: ni_usb6008_: comedi_usb_auto_config: 0 Apr 29 14:56:47 prashant kernel: [ 1508.563459] comedi: ni_usb6008: ni_usb6008_ai_cmdtest Apr 29 14:56:47 prashant kernel: [ 1508.563466] comedi: ni_usb6008: ni_usb6008_ai_cmdtest Apr 29 14:56:47 prashant kernel: [ 1508.563468] comedi: ni_usb6008: ni_usb6008_ai_cmdtest Apr 29 14:56:47 prashant kernel: [ 1508.563474] comedi: ni_usb6008: ni_usb6008_ai_cmdtest Apr 29 14:56:47 prashant kernel: [ 1508.563475] comedi: ni_usb6008: ni_usb6008_ai_cmd Apr 29 14:56:47 prashant kernel: [ 1508.563477] comedi0: ni_usb6008: sending commands to the usb device: size=8 Apr 29 14:56:47 prashant kernel: [ 1508.563478] comedi: ni_usb6008: send_dux_commands Apr 29 14:56:47 prashant kernel: [ 1508.563631] comedi: ni_usb6008: ni_usb6008_submit_InURBs Apr 29 14:56:47 prashant kernel: [ 1508.563983] comedi: ni_usb6008: ni_usb6008_ai_cancel Apr 29 14:56:47 prashant kernel: [ 1508.563985] comedi: ni_usb6008: ni_usb6008_ai_stop Apr 29 14:56:47 prashant kernel: [ 1508.563986] comedi: ni_usb6008: ni_usb6008_unlink_InURBs Apr 29 14:56:47 prashant kernel: [ 1508.573486] comedi: ni_usb6008: ni_usb6008_ai_IsocIrq Apr 29 14:56:47 prashant kernel: [ 1508.573490] comedi0: ni_usb6008: unlinking. Apr 29 14:56:47 prashant kernel: [ 1508.573492] comedi: ni_usb6008: ni_usb6008_ai_stop Apr 29 14:56:47 prashant kernel: [ 1508.573514] comedi: ni_usb6008: ni_usb6008_ai_cmdtest Apr 29 14:56:47 prashant kernel: [ 1508.573517] comedi: ni_usb6008: ni_usb6008_ai_cmdtest Apr 29 14:56:47 prashant kernel: [ 1508.573520] comedi: ni_usb6008: ni_usb6008_ai_cmdtest Apr 29 14:56:47 prashant kernel: [ 1508.573524] comedi: ni_usb6008: ni_usb6008_ai_cmdtest Apr 29 14:56:47 prashant kernel: [ 1508.573526] comedi: ni_usb6008: ni_usb6008_ai_cmd Apr 29 14:56:47 prashant kernel: [ 1508.573528] comedi0: ni_usb6008: sending commands to the usb device: size=8 Apr 29 14:56:47 prashant kernel: [ 1508.573530] comedi: ni_usb6008: send_dux_commands Apr 29 14:56:47 prashant kernel: [ 1508.573750] comedi: ni_usb6008: ni_usb6008_submit_InURBs Apr 29 14:56:47 prashant kernel: [ 1508.583433] comedi: ni_usb6008: ni_usb6008_ai_IsocIrq Apr 29 14:56:47 prashant kernel: [ 1508.583435] comedi0: ni_usb6008: copying data to transfer_buffer Apr 29 14:56:47 prashant kernel: [ 1508.585428] comedi: ni_usb6008: ni_usb6008_ai_IsocIrq Apr 29 14:56:47 prashant kernel: [ 1508.585431] comedi0: ni_usb6008: copying data to transfer_buffer Apr 29 14:56:47 prashant kernel: [ 1508.587422] comedi: ni_usb6008: ni_usb6008_ai_IsocIrq Apr 29 14:56:47 prashant kernel: [ 1508.587424] comedi0: ni_usb6008: copying data to transfer_buffer Apr 29 14:56:47 prashant kernel: [ 1508.589419] comedi: ni_usb6008: ni_usb6008_ai_IsocIrq Apr 29 14:56:47 prashant kernel: [ 1508.589420] comedi0: ni_usb6008: copying data to transfer_buffer Apr 29 14:56:47 prashant kernel: [ 1508.591427] comedi: ni_usb6008: ni_usb6008_ai_IsocIrq Apr 29 14:56:47 prashant kernel: [ 1508.591430] comedi0: ni_usb6008: copying data to transfer_buffer Apr 29 14:56:47 prashant kernel: [ 1508.593412] comedi: ni_usb6008: ni_usb6008_ai_IsocIrq Apr 29 14:56:47 prashant kernel: [ 1508.593414] comedi0: ni_usb6008: copying data to transfer_buffer Apr 29 14:56:47 prashant kernel: [ 1508.595412] comedi: ni_usb6008: ni_usb6008_ai_IsocIrq .... .... .... Apr 29 14:56:51 prashant kernel: [ 1512.572562] comedi0: ni_usb6008: copying data to transfer_buffer Apr 29 14:56:51 prashant kernel: [ 1512.574550] comedi: ni_usb6008: ni_usb6008_ai_IsocIrq Apr 29 14:56:51 prashant kernel: [ 1512.574552] comedi0: ni_usb6008: copying data to transfer_buffer Apr 29 14:56:51 prashant kernel: [ 1512.576550] comedi: ni_usb6008: ni_usb6008_ai_IsocIrq Apr 29 14:56:51 prashant kernel: [ 1512.576551] comedi0: ni_usb6008: copying data to transfer_buffer Apr 29 14:56:51 prashant kernel: [ 1512.578543] comedi: ni_usb6008: ni_usb6008_ai_IsocIrq Apr 29 14:56:51 prashant kernel: [ 1512.578545] comedi0: ni_usb6008: copying data to transfer_buffer Apr 29 14:56:51 prashant kernel: [ 1512.580543] comedi: ni_usb6008: ni_usb6008_ai_IsocIrq Apr 29 14:56:51 prashant kernel: [ 1512.580545] comedi0: ni_usb6008: copying data to transfer_buffer Apr 29 14:56:51 prashant kernel: [ 1512.581218] comedi: ni_usb6008: ni_usb6008_ai_cancel Apr 29 14:56:51 prashant kernel: [ 1512.581220] comedi: ni_usb6008: ni_usb6008_ai_stop Apr 29 14:56:51 prashant kernel: [ 1512.581221] comedi: ni_usb6008: ni_usb6008_unlink_InURBs Apr 29 14:56:51 prashant kernel: [ 1512.582537] comedi: ni_usb6008: ni_usb6008_ai_IsocIrq Apr 29 14:56:51 prashant kernel: [ 1512.582539] comedi0: ni_usb6008: unlinking. Apr 29 14:56:51 prashant kernel: [ 1512.582541] comedi: ni_usb6008: ni_usb6008_ai_stop Apr 29 14:56:55 prashant kernel: [ 1515.973856] usb 2-1.2: USB disconnect, address 6 Apr 29 14:56:55 prashant kernel: [ 1515.973922] comedi: ni_usb6008: ni_usb6008_disconnect Apr 29 14:56:55 prashant kernel: [ 1515.973985] comedi_: ni_usb6008: ni_usb6008_detach Apr 29 14:56:55 prashant kernel: [ 1515.973988] comedi0: ni_usb6008: detach usb device Apr 29 14:56:55 prashant kernel: [ 1515.973991] comedi0: ni_usb6008: detach: successfully removed Apr 29 14:56:55 prashant kernel: [ 1515.974036] comedi: ni_usb6008: tidy_up Apr 29 14:56:55 prashant kernel: [ 1515.974040] comedi_: ni_usb6008: disconnected from the usb

2 3

looking for simple module/driver programming examples in source tree
by Robert P. J. Day May 3, 2011

May 3, 2011

as a followup to an earlier post, this is kind of a nebulous proposal but i want to start collecting examples out of the kernel source tree that demonstrate a lot of the basic or introductory kernel programming concepts. with some of the courseware i deal with, there's typically a perfectly reasonable explanation for numerous introductory concepts and topics, but none of that beats being accompanied by an actual example right out of the source. for example, i can explain in detail how to write a simple, read-only proc file, or i can just point at some terrific examples in the fs/proc directory, such as version.c: === snip header files === static int version_proc_show(struct seq_file *m, void *v) { seq_printf(m, linux_proc_banner, utsname()->sysname, utsname()->release, utsname()->version); return 0; } static int version_proc_open(struct inode *inode, struct file *file) { return single_open(file, version_proc_show, NULL); } static const struct file_operations version_proc_fops = { .open = version_proc_open, .read = seq_read, .llseek = seq_lseek, .release = single_release, }; static int __init proc_version_init(void) { proc_create("version", 0, NULL, &version_proc_fops); return 0; } module_init(proc_version_init); === end version.c === once you see that living, breathing example, what more would you need to know about how to have your module/driver create a simple read-only proc file? as another example, we all know that if your module init() routine runs into an error, it has an obligation to carefully (and, typically, in reverse order) undo everything it's done up to that point. sometimes, that routine is loaded with "goto" stmts. other times, the module author might create a "cleanup" routine that is callable from both the init and exit routines. i'm currently perusing the source for nice, uncluttered examples of exactly that (where the explanation isn't buried under extraneous processing to the point where it's hard to see the relevant code). and the list goes on and on -- there are assuredly all sorts of source files for drivers that can be used as respectable examples of all sorts of *introductory* concepts. i'm also interesting in collecting examples of documentation for basic kernel programming concepts. sometimes, there are excellent examples in the source Documentation/ directory, sometimes not. or there might be high-quality tutorials at places like lwn.net, developerworks, and lots of other places. i'm interested in starting a list of tutorials like that that explain, ideally, a single topic really, really well for the sake of beginners. thoughts? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

5 10

Please recommend linux network kernel books...
by J.Hwan.Kim May 3, 2011

May 3, 2011

Hi, everyone Could you please recommend books on linux network stack of 2.6 Kernel? Thanks in advance. Best Regards, J.Hwan Kim

4 3

Re: Sleep and Wake up
by Vikram Narayanan May 3, 2011

May 3, 2011

>> On Mon, May 02, 2011 at 11:32:32AM -0700, Abu Rasheda wrote: >>> I am testing my driver on much faster host processor and facing >>> following issues: >>> >>> My host is too powerful and it can fill up device buffer queue very fast. >> >> What kind of device is this? > > its a networking device > >>> I get best performance when I do busy wait, but this is not desirable >>> and is bad design. >>> >>> I need to sleep and wake up quickly and predictability. Indication >>> from device that queue has space, is coming in form of memory write >>> (device writes to a memory location of i86 processor). >>> >>> I tried using wait_event_interruptible_timeout, I am depending on 2nd >>> parameter of the function but it wake up is too slow, even tried using >>> value of 1. >> >> Why not try increasing the buffer in your driver to handle any amount of >> data needed? > > Problem come from the fact that remote end can be slow, so device / > driver cannot do much. If I increase buffer size, than running on > (even) faster host processor will bring back same issue. I am looking > for solution which will scale. AFAIK, These scaling things will be taken care by the protocol. BTW, Which protocol you are communicating with? It would be good if you try to give more information on what you are trying to achieve. Thanks, Vikram

1 0

Re: looking for decent summary of kernel debugging primitives
by Vikram Narayanan May 2, 2011

May 2, 2011

> i'm getting ready to teach a basic device drivers course in a couple >weeks with someone else's courseware and i just wanted to bring some >sections up to date. there's one section on basic debugging that >covers printk() as well as other topics from LDD3 such as >printk_ratelimit(), setting the console loglevel and so on. > > however, there's obviously more these days -- the "pr_"-prefixed >wrappers, dev_dbg() and so on. is there a single source that covers >the standard debugging routines in the kernel these days? if not, no >big deal, i'll just summarize what i know of. This may not be relevant to the question that you asked. But there are some good debugging techniques like kprobe,jprobe. There are sample programs in the kernel source under the directory samples/kprobes/. Those examples are very easy to understand and are much powerful than using printk. - Thanks, Vikram

3 2

looking for decent summary of kernel debugging primitives
by Robert P. J. Day May 2, 2011

May 2, 2011

i'm getting ready to teach a basic device drivers course in a couple weeks with someone else's courseware and i just wanted to bring some sections up to date. there's one section on basic debugging that covers printk() as well as other topics from LDD3 such as printk_ratelimit(), setting the console loglevel and so on. however, there's obviously more these days -- the "pr_"-prefixed wrappers, dev_dbg() and so on. is there a single source that covers the standard debugging routines in the kernel these days? if not, no big deal, i'll just summarize what i know of. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 2