Developing the Linux kernel with KDevelop

[Milian Wolff]

Alexandre Courbot, 21.09.2011:
> Hey,
> 
> Thanks for the feedback - glad you found my article heartwarming.
> KDevelop is definitely a project one can be proud about. And yes, I
> think with a few patches here and there it could become a great tool
> for kernel hackers, especially beginner ones. It surely helped me a
> lot already.
> 
> I will post my reply to Milian here, where I propose we continue the
> discussion.
> 
> a) Isn't the generic project manager independant of make? Why would it
> need to run it in this case?

whops - I didn't read your article in-depth, mostly the error section only and 
assumed you used custommake manager.

> b) I thought it would make sense to have the automatically included
> files into .kdev_include_paths since it would allow to restrict the
> inclusion to some parts of a project. For the kernel project-wide
> settings are fine, but as far as the generic project manager is
> concerned we may as well try to be, well, generic. :p It seems,
> looking at the code, that these files can already hold other stuff
> (did not figure out what yet though), but if you think project wide
> settings are better, I'm fine with that too.

hm true, tracking the info in something like .kdev_defines might work as 
well... not sure whether it's fine-grained enough to have that per-directory 
though.

> c) I wonder how far could Makefiles parsing could go for guessing -D
> parameters (especially if some variables need to be expanded). If this
> works, the same thing could be done for -include too. But letting the
> user specify these manually (along with a "guess from Makefile" button
> seems safer.

well, actually if you don't use the custommake manager no wonder it's not 
working.

> d) Yep, although a C++ parser, KDevelop's parser (unsurprisingly) does
> a great job with C - even kernel C. Here I guess being liberal is ok,
> as long as it "just works". I will try to get the C99 initializations
> in after I understand the parsing/DUchain stuff.

kdeveop/language/cpp
/parser/parser.cpp -> you'll need to adapt that to parse it properly
/cppduchain/*builder* -> you'll at least need to change the usebuilder 
probably for the ".member =" part.

> I will also try to get the massif metrics you asked (I already use Git
> version). As for memory consumption, parsing the parts of the code I
> have specified in the article + a couple of drivers results in around
> 1GB of memory used, with a good dozen of files opened.

where do you get that number from? ksysguard? if not, please look at it in 
ksysguard.

> By today
> standards, this seems very acceptable and much better than e.g.
> Eclipse anyway. Of course, if you want to parse the whole kernel tree,
> this is another story. The parser would take too much time anyway to
> make this practical, but this is not a real concern. Lookup is just
> fast. Sometimes reverse lookup takes more time than I would expect,
> but this is also the case in Qt projects so nothing like a scaling
> problem.

Right, but improving the performance to get it working as it should would be 
cool imo. If you have the time (and a 2.6.x kernel machine + intel cpu), try 
to run kdev with your kernel project with vtune.

> All in all KDevelop looks pretty fun to work on. In my student days I
> did quite a lot of static code analysis/optimization/specialization,
> so maybe I could also give a hand there, if time allows (which I
> unfortunately doubt). But first I'd like to fix these few things -
> after all, KDevelop is my main work tool, so I'd better shape it right
> for me. ;)

as aleix and I said already: We'll be glad to give you a hand. Shout if you 
have questions.

bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110921/e08ab701/attachment.sig>