Developing the Linux kernel with KDevelop

[Alexandre Courbot]

> 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.

This is just a thought, I'm not sure yet about what would be the best
way to do it. Project-wide settings are probably easier to implement
for a start. I will try to get a first try done with the generic
manager, as having the configuration definitions available would
greatly help me.

> 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.

Thanks. I had a look at it, that seems doable after some more study.
Second on my list. ;)

>> 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.

I was using ksysguard, but these metrics were from months ago. Now
after a fresh startup, letting the parser go through all the source
files again, and opening a set of files, ksysguard reports 255MB of
memory and 124MB of shared memory used. That is much less than, say,
Firefox. I'm sure it was much more some months ago. The current git
seems to have received quite a bit of optimization.

>> 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.

Good idea - but what do you get more compared to a run with, say, gprof?

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

Thanks guys. I don't want to take the fun away by asking too much too
fast, but I will sure come to you if I get stuck somewhere. ;)

Alex.