Oh yes, i do "make tags" (for Linux kernel source) or "find . -name '*.c' -o -name '*.h' > cpp.dat" and "ctags `cat cpp.dat`" whenever possible as well. Taught to us (kernelnewbies group) by Rene Herman in the past - does anyone what has happened to him? But I do have a problem, which lxr (+search engine) managed to solve, is asking the question: where are all the points in the source tree that call the current function, or alternatively, where in entire source tree does a particular symbol occurred (which can be a string with space in between)? This cannot be done via the "tags" file, but u really need to search through all the source codes to find the caller. I used perl scripts for that. Another problem with vi is that the "tags" file must be locally created in the current directory. So if u navigate to kernel_source/fs directory and would like to navigate among source files from there, it will be necessary to create a custom "tags" file there (using "find" as above and put in all the relevant C and header files) - otherwise it is necessary to navigate back to the highest level of kernel_source to analyze the source code, which is not really easy, as kernel source sometimes is quite deep. Another reason for doing these localized "tags" file is because when u enter ":tnext" in vi, to scroll through all the declaration of a particular definition (for eg, try finding out the definition for "list_head".....tags will give u 13 of them). but if u create a localized tags file, this number is dramatically reduced. Nevertheless, I used tags very often.......thanks. On Wed, Feb 25, 2009 at 3:41 AM, Thomas Rega <mail@xxxxxxxxxx> wrote: > > hi peter > > did you ever gave a try to ctags in 'alliance' with vim? > > just a hint ... > > http://scottr.org/blog/2008/feb/24/ctags-and-vim/ > > have fun > > TR > > > Am Dienstag, den 24.02.2009, 11:44 -0500 schrieb Peter Teoh: >> On Tue, Feb 24, 2009 at 3:38 AM, Thomas Petazzoni >> <thomas.petazzoni@xxxxxxxxxxxxxxxxxx> wrote: >> > Le Tue, 24 Feb 2009 09:11:53 +0800, >> > Peter Teoh <htmldeveloper@xxxxxxxxx> a écrit : >> > >> >> But then it also puzzled me, because ioctl() in user space required a >> >> open file descriptor as the first parameter, which is derived from >> >> open() (as specified from "man ioctl"). so then how is the open() >> >> from userspace passed down to kernel? >> > >> > When userspace uses the open() system call, the kernel function >> > sys_open() gets called. This kernel function does all the job, and >> > calls the ->open() operation of the device driver if it exists. >> > Otherwise, it just doesn't call it, and it works perfectly fine. The >> > sys_open() function does all what's needed, the ->open() operation is >> > only here *if* your device driver needs to do something when the device >> > is opened. This operation is optional. >> > >> > sys_open() >> > http://lxr.free-electrons.com/source/fs/open.c#L1032 >> > >> > calls >> > >> > do_sys_open() >> > http://lxr.free-electrons.com/source/fs/open.c#L1010 >> > >> > which calls >> > >> > do_filp_open() >> > http://lxr.free-electrons.com/source/fs/namei.c#L1637 >> > >> > which calls >> > >> > nameidata_to_filp() >> > http://lxr.free-electrons.com/source/fs/open.c#L918 >> > >> > which calls >> > >> > __dentry_open() >> > http://lxr.free-electrons.com/source/fs/open.c#L793 >> > >> > which does >> > >> > 823 if (!open && f->f_op) >> > 824 open = f->f_op->open; >> > 825 if (open) { >> > 826 error = open(inode, f); >> > 827 if (error) >> > 828 goto cleanup_all; >> > 829 } >> > >> > (ouf) >> > >> > Sincerly, >> > >> > Thomas >> >> Thank you Thomas, I think the lxr source code navigator is really >> useful, as compared with "vi" :-). Thank you for the contribution >> :-). >> > > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
