| HoraPe | se necesitan voluntarios para traducir a castellano, en #redes |
|---|
| HoraPe | Hello |
|---|
| HoraPe | This is the closing conference of umeet |
|---|
| HoraPe | Arnaldo Carvalho de Melo, from Conectiva |
|---|
| HoraPe | Dave Jones (from Suse) |
|---|
| HoraPe | and Jeff Garzik (from Mandrakesoft) |
|---|
| HoraPe | will talk about the Linux Kernel Janitor project |
|---|
| * acme wonders why people thing that there are distro wars ;) :) |
| HoraPe | Questions can be asked on #qc |
|---|
| HoraPe | If some people volunters for translating, the talk will be in spanish in #redes. |
|---|
| davej | Jeff still hasn't made it, so we'll begin without him, hopefully he'll turn up later. |
|---|
| HoraPe | Si alguien se ofrece a traducir, tendremos la charla en castellano en #redes. |
|---|
| HoraPe | acme, go on |
|---|
| acme | thanks |
|---|
| acme | Well, we're here to talk about the Kernel Janitor Project |
|---|
| acme | that grew out of our search for things to help in the linux kernel development |
|---|
| acme | and as some of us were still newbies |
|---|
| acme | we searched the mailing lists for simple things to fix |
|---|
| acme | so I started collecting things that needed fixes in a TODO and started submitting small patches |
|---|
| acme | later on I made my TODO list public at http://bazar.conectiva.com.br/~acme/TODO |
|---|
| acme | and noticed that _lots_ of people started looking at it |
|---|
| acme | so me and davej created the Kernel Janitor Project - http://kerneljanitor.org |
|---|
| acme | on sourceforge |
|---|
| acme | with a mailing list for the janitors |
|---|
| acme | most of the entries in the TODO list are very simple things |
|---|
| acme | that can serve as a start for people interested in contributing to the linux kernel effort |
|---|
| davej | An interesting parallel to the kernel janitor project is what happens with the FreeBSD folks. Regularly, you'll see on their mailing list "junior kernel hacker tasks". Simple (but often tedious) cleanups. More experienced hackers will mentor newcomers to kernel hacking, often pointing them in the correct direction. |
|---|
| acme | yes, this is one of the most interesting things about the KJP: to provide simple tasks for kernel newbies |
|---|
| acme | from these simple tasks one can get confidence |
|---|
| davej | and the offer of assistance to anyone prepared to do the 'monkey work' |
|---|
| acme | yes, thats the KJP mailing list goal |
|---|
| acme | as the newbie starts getting his patches accepted he can get the confidence to work on more complex tasks |
|---|
| HoraPe | <acme> yes, thats the KJP mailing list goal |
|---|
| acme | and to learn how to send the patches, how to deal with the way developers work |
|---|
| davej | moving on to some real life examples of the sort of janitor tasks that occur.. |
|---|
| acme | ok, now davej will talk about a sample janitor task |
|---|
| davej | quite often, there are "simple" tasks, which are nothing more than search & replace operations. |
|---|
| davej | but as these need to be done sometimes for every driver in the tree, its a lot of work. |
|---|
| davej | An example of such a s&r operation can be found at http://www.codemonkey.org.uk/patches/2.5/small-bits/setcurrentstate-2.diff |
|---|
| davej | in this circumstance, manually setting current->state was deprecated in favour of using the set_current_state() function. |
|---|
| davej | this sort of thing happens quite frequently. |
|---|
| davej | The patch in that example replaces every occurance in the tree of the old way with the new way. |
|---|
| davej | Coming back to what acme mentioned earlier about dealing with developers, large scale cleanups like these should really be handled by splitting that large diff into small pieces, and then sending the individual parts to the developer responsible for that part of the tree. |
|---|
| davej | which can sometimes be more time consuming than creating the patch in the first place 8) |
|---|
| acme | and sometimes the patch clashes with current work that that particular developer is working |
|---|
| davej | An idea some people have had in the past has been to write a script that automates part of this (by taking the filename, and doing a lookup to get the respective maintainer). No-one has actually written anything like this yet unfortunatly. |
|---|
| davej | Writing such a tool would also be an interesting project for a beginner 8) |
|---|
| acme | davej: actually a french janitor did it with some interesting results |
|---|
| davej | oh, I was not aware of this. |
|---|
| acme | he sent messages to all the addresses in the particular file if there were not an entry in MAINTAINERS |
|---|
| acme | lots of bounces 8) |
|---|
| davej | Well, another janitor task would be making sure MAINTAINERS is in sync then 8) |
|---|
| acme | :) |
|---|
| acme | and another interesting result of the KJP is to find new maintainers |
|---|
| acme | I'll give another simple example, but slightly more complex than the set_current_state one |
|---|
| acme | and that serves as a good example of how new janitor tasks appear |
|---|
| acme | its related to evolution of the kernel |
|---|
| acme | some APIs are changed and just some drivers are updated to use it |
|---|
| acme | with all the other drivers/subsystems using compatibility functions/macros |
|---|
| acme | so the kernel goes on getting full of compatibility cruft that need janitors to clean |
|---|
| acme | so the example: |
|---|
| acme | drivers have to request regions for the io areas they use |
|---|
| acme | in the past it was done by first checking if the region was not being used, using the check_region function |
|---|
| acme | then, if it was not used, the driver had to use request_region to register its usage and avoid other drivers to use the same area |
|---|
| acme | when the drivers were serially initialized, this was ok |
|---|
| acme | but now some subsystems allows concurrent initialization of drivers |
|---|
| acme | and with this the check_region first, request_region if it was free becomes a race condition |
|---|
| acme | because two drivers can use check_region at the same time (SMP), find it free, and both move on to call request_region |
|---|
| acme | b00m |
|---|
| acme | so now the driver has to use only request_region and check its result |
|---|
| acme | b00m |
|---|
| acme | so now the driver has to use only request_region and check its result |
|---|
| acme | that will make the check/register operation atomic |
|---|
| acme | but hey, who will make all drivers stop using check_region? oh, boring work 8) |
|---|
| acme | so now the janitors have to go to all the drivers and remove the check_region and make it check the request_region call |
|---|
| acme | I actually did it for a lot of drivers, but there are lots more to be done |
|---|
| acme | and in the sound drivers case it gets a little bit more complicated, but nothing that a good janitor couldn't do 8) |
|---|
| acme | <movement> complicated how ?? |
|---|
| davej | whilst cleaning one thing, often you'll notice something else also.. |
|---|
| riel | sorry davej ;) |
|---|
| davej | (thanks Rik) |
|---|
| acme | well, the thing is that sound drivers use functions that are in other general purpose modules |
|---|
| acme | then one have to go over several files and change those functions |
|---|
| acme | well, once you change the generic module, you have to make sure that all the other sound drivers that use it have to be changed accordingly |
|---|
| acme | you can see this by looking at the sound drivers that still use check_region and trying to figure out how to remove the check_region call 8) |
|---|
| davej | (and a quick grep in drivers/sound shows there are still quite a few users of check_region) |
|---|
| acme | davej: yup, lets see if people here fix that 8) |
|---|
| davej | grep is the kernel janitors best friend btw, if you only learn one tool fully, make it grep 8) |
|---|
| acme | Now I'll talk about a project that I'm working on that is janitor related |
|---|
| acme | and is more complex, to show how one can go from simple tasks to more complex ones |
|---|
| acme | protocol stacks use a struct sock to represent connections |
|---|
| acme | its defined in include/net/sock.h |
|---|
| acme | and by looking at it I spotted a nice comment |
|---|
| | | * This structure really needs to be cleaned up. |
|---|
| | | * Most of it is for TCP, and not used by any of |
|---|
| | | * the other protocols. |
|---|
| | | */ |
|---|
| acme | so, my janitor hat promptly jumped to my head 8) |
|---|
| acme | studying this file I also noticed that it had a data dependency problem |
|---|
| davej | (for those that don't know, acme has been cleaning up netbeui and other strange stacks before this 8) |
|---|
| acme | davej: hehe, now this is something that will bite everybody, so beware! 8) |
|---|
| acme | the problem was that when one new protocol stack was to be added the developer had to touch this core struct |
|---|
| acme | including a struct on a union for the private part of the protocol |
|---|
| acme | well, this has the problem that the struct can become larger and larger |
|---|
| acme | and it also adds yet another include file to sock.h |
|---|
| acme | which makes my poor pentium 300 Mhz machine takes longer to compile the kernel |
|---|
| acme | and also makes a big chunk of the kernel to be recompiled every time I touch one of the files included there |
|---|
| acme | the same problem btw plagues another very important data structure: struct inode, used by all the file systems and the network stacks as well |
|---|
| acme | so now I'm removing all protocol specific stuff from sock.h |
|---|
| acme | moving them to the respective protocol headers |
|---|
| acme | and making the member that stores the protocol private area a simple void pointer |
|---|
| acme | then something surfaced that proved that this janitor task would provide memory savings and performance improvements |
|---|
| acme | because now I made the most important protocols use a private slabcache |
|---|
| acme | with that the protocols will use just the memory that they need and not the size of the protocol with the biggest private area |
|---|
| acme | every connection on a machine uses a struct sock |
|---|
| acme | and with the approach used in the current mainline kernel |
|---|
| acme | <HoraPe> acme is talking about some type of inheritance-like system? |
|---|
| acme | yup |
|---|
| acme | now we have struct sock with only the things that most protocols need |
|---|
| acme | with the per protocol slabcache the protocols will allocate the size of the generic struct sock + the size of its private struct |
|---|
| acme | so now in the current kernel if you compile all the protocols, even if they're compiled as modules |
|---|
| acme | every connection will require 1280 bytes of kernel memory (non swappable) |
|---|
| acme | with the patch I'm working on it will require only what the specific protocol needs |
|---|
| acme | this makes ipv4 sockets use only 800 bytes |
|---|
| acme | unix sockets only uses about 300 bytes |
|---|
| davej | this kind of saving can be very noticable on busy boxes (think big ftp servers/web servers etc) |
|---|
| acme | so on a normal workstation with say 30 unix sockets (syslog, postfix, XFree86, KDE - all users of unix sockets) |
|---|
| acme | one will save... |
|---|
| acme | 30 * (1280 - 300) |
|---|
| acme | 29400 |
|---|
| acme | almost 30 KB of kernel memory |
|---|
| acme | on a big busy ftp server, with say 2000 ipv4 connections... |
|---|
| acme | 2000 * (1280 - 800) |
|---|
| acme | 960000 |
|---|
| acme | almost 1 MB of in kernel memory |
|---|
| acme | and this leads to performance gains, of course |
|---|
| acme | I used this example (and I could have used the IPX case as well) to show that one can start doing janitor boring tasks |
|---|
| acme | get experience |
|---|
| acme | and move on to more useful things |
|---|
| acme | I'm also the current IPX network stack maintainer, out of a janitor task |
|---|
| acme | ok, so now I think davej can talk about the tools that can help in janitoring the kernel |
|---|
| acme | <movement> and when exactly do we lose the similar union ugliness is struct |
|---|
| acme | inode ;) |
|---|
| acme | movement: next target 8) |
|---|
| acme | as soon as I finish the struct sock and DaveM is happy with it |
|---|
| acme | I'll coordinate with Al Viro and start cleaning fs.h (struct inode) |
|---|
| * acme looks at davej |
| davej | before I move on to the next part, a quick mention that reducing the size of various structs in the kernel seems to be a very popular thing to be doing for 2.5, (wli has patches that reduce struct page for eg, to save 8 bytes of every page (4kb) of memory in the system for example).. |
|---|
| acme | yup, 2.5 indeed seems to be the janitor kernel 8) |
|---|
| davej | struct page is a good example here, because on x86, if we can reduce it a little more, the whole struct will fit in an x86 cacheline. |
|---|
| davej | which should see another nice performance win as bits stop fighting for cachelines |
|---|
| davej | ok, any further questions there ? or should I move on/ |
|---|
| davej | ? |
|---|
| davej | ok, I'll move on. |
|---|
| acme | sorry for not asking for questions before :-\ |
|---|
| davej | as I mentioned earlier, tools like grep can be the best weapon in a janitors arsenal. |
|---|
| davej | sometimes, the simpler tasks can be searched for in drivers just by doing a single grep with -C showing enough context around the search item to see if its worth further investigation. |
|---|
| davej | but there are other perhaps more interesting tools at our disposal also. |
|---|
| davej | Some time ago, a group of students at Stanford university wrote some extensions to gcc that would allow a compile to show up extra common mistakes. |
|---|
| davej | a late question... |
|---|
| davej | <hrandoz> how big is an x86 cacheline? |
|---|
| davej | depends.. usually 32 bytes. though newer machines (athlon etc) are 64 bytes. |
|---|
| davej | P4 is a strange case, 128 bytes, but its really 2x64 bytes iirc |
|---|
| davej | ok, back to the tools.. |
|---|
| davej | The stanford team were posting results that their checker found to the kernel mailing list, (you can find them in archives, subjects always began with [CHCKER]) |
|---|
| davej | CHECKER even... |
|---|
| davej | Due to the fact that gcc could pick up context as it compiled, and had a picture of the coverage of each function as it compiled, it could find common problems with things like, spinlocks that were locked on entry to a function, unlocked on exit, but not unlocked on an error path in the same function |
|---|
| davej | Does that bit make sense to everyone ? |
|---|
| * acme can give an example |
| acme | say, a function that initializes a network driver |
|---|
| acme | it has to get some memory for its private struct |
|---|
| acme | register the device to the core net |
|---|
| acme | probe the cards, etc |
|---|
| acme | if it allocates the private struct |
|---|
| acme | but fails to probe a card |
|---|
| acme | it has to release the memory it allocated to the private struct |
|---|
| acme | and then return an error code |
|---|
| acme | some drivers didn't released the memory, leaking it |
|---|
| acme | ditto for spinlock grabbing |
|---|
| acme | error happens, it returns without releasing the spinlock |
|---|
| acme | ok |
|---|
| * acme passes the baton to davej :) |
| davej | thanks.. |
|---|
| davej | So, the stanford team came up with huge amounts of bug reports for janitor types to go running after.. |
|---|
| davej | lots of these got merged, some didn't, so every so often, they would repeat their scan (usually with extra tests each time) |
|---|
| acme | even in places like ext2... |
|---|
| davej | indeed, these were problems that were in pretty much every corner of the kernel |
|---|
| acme | very subtle ones that not even the more experient long time hackers had found |
|---|
| davej | So every time a new stanford run was made, there would be huge amounts of clean ups that occured shortly afterwards.. |
|---|
| davej | in more recent times, the stanford folks haven't been as active, iirc the last kernel they tested was 2.4.8 |
|---|
| davej | And one thing that was commonly asked for, was the source to their extensions. |
|---|
| davej | unfortunatly, due it being an academic project, there are complications (that I don't fully understand) that prevent them from releasing it yet. |
|---|
| davej | but! all is not lost... |
|---|
| davej | (oh, you can find more about stanford checker at http://hands.stanford.edu/linux/ btw) |
|---|
| davej | quite recently, acme and myself found out about a rival checker type program by the folks at Berkeley university. |
|---|
| davej | and this time, they provided us with the source code. Hurrah! |
|---|
| davej | unfortunatly, neither of us has found time to really experiment with it much, but from what we've seen so far, it's not as advanced as the stanford checker, but has good potential. |
|---|
| davej | This tool is under active development by the berkeley folks, so hopefully something useful will come of it.. |
|---|
| davej | next tool.. |
|---|
| davej | in the meantime, one evening I got bored, and decided to teach myself some perl. |
|---|
| davej | having no prior experience of programming in perl made this quite an effort, but what I came up turned out to be not such a bad tool.. |
|---|
| HoraPe | como que no valen? |
|---|
| HoraPe | oops, sorry |
|---|
| davej | at http://www.kerneljanitor.org/kernel-janitor/scripts/ you'll find kj.pl (no comments on bad perl structure please!) |
|---|
| davej | you'll also see kj-devel.pl which is a development not quite ready version |
|---|
| davej | these tools will take a filename as a parameter, and do some simple grepping for common mistakes, things like the check_region() usage that acme mentioned, and it'll spit out warnings suggesting to use request_region |
|---|
| davej | it has just over a dozen or so regexps so far, and adding them is simple enough.. |
|---|
| davej | this tool was not meant to get as advanced as things like the stanford checker, but to highlight some of the 'simple' janitor tasks |
|---|
| davej | ok, next tools.. |
|---|
| davej | not competly related to the janitor project, but worthy of mentioning here (as they usually end up exposing janitor type bugs) |
|---|
| davej | Something the kernel really needs is more stress-testing tools. |
|---|
| davej | By putting extreme load onto the kernel, we sometimes expose bugs for eg, in drivers.. These bugs are sometimes replicated in every driver for that type of hardware, |
|---|
| davej | this also applies to things like filesystems, where code is commonly copied from other fs's. |
|---|
| acme | everywhere 8) |
|---|
| acme | serial drivers come to mind ;) |
|---|
| davej | Some examples of the stress testing tools we have so far are Juan Quintela's memtest suite and cerberus (http://people.redhat.com/bmatthews/cerberus/) |
|---|
| davej | and today.. |
|---|
| davej | today I noticed on http://www.kerneltrap.com/article.php?sid=415&mode=nested&order=0 there was mention of a tool used to find lots of filesystem related bugs by the FreeBSD folks. |
|---|
| davej | it took me just a few minutes to get this tool compilable under Linux. |
|---|
| acme | and some more minutes to spot a bug in reiserfs ;) |
|---|
| davej | And the test results were almost instant... we have a few filesystems that seem to be showing up bugs. |
|---|
| davej | Yes, reiserfs was the first to show. |
|---|
| davej | iirc it lasted 300 or so operations.. NFS lasted some 40,000 or so... and the reports of other fs's are still coming in.. |
|---|
| acme | Hans Reiser already asked his coders to look at it and fix |
|---|
| davej | what will be interesting to see, is if this tool highlights any bugs that are duplicated in for eg.. the getblk of every network filesystem.. |
|---|
| davej | as I mentioned earlier, code is often copied from other fs's, and adjusted to fit. |
|---|
| davej | copied, along with any bug that happens to be in that code. |
|---|
| davej | So when the bug is found, auditting the same routine in other similar fs's is a (perhaps somewhat advanced) janitor tasks |
|---|
| davej | ok, that wraps up the tools section.. any questions on that part ? |
|---|
| davej | <wli> Who is developing the Berkeley automated checker? |
|---|
| * davej goes to look in inbox |
| acme | Jeff Foster <jfoster@cs.berkeley.edu> |
|---|
| davej | *nod* |
|---|
| acme | http://www.cs.berkeley.edu/~jfoster/tmp/cqual-0.95.tar.gz |
|---|
| davej | <wli> What sort of participation is there from the Linux commnuity in it, or is it BSD-specific? |
|---|
| davej | the tool itself is quite extensable, you teach it patterns, and it could be used for eg, to look for bugs in mozilla, or any other code... |
|---|
| davej | so it's not really anything specific right now |
|---|
| davej | as for participation, well.. |
|---|
| davej | they asked acme and myself to look at it, but as I mentioned earlier, we've not really done much with it yet. |
|---|
| davej | <voltemand> or from the gcc crowd, who's work it was built on? |
|---|
| acme | some more info on cqual |
|---|
| davej | to the best of my knowledge, it was created from scratch just on top of a stable release version of gcc |
|---|
| | | You can analyze a file at a time, in which case the system makes |
|---|
| | | optimistic assumptions about the rest of the code, or you can analyze a |
|---|
| | | whole module at a time, which uses a lot more memory and time but can give |
|---|
| | | you more bugs. |
|---|
| | | The tool also has an emacs-based browsing interface that tries to show you |
|---|
| | | why it decided there was an error at some point. |
|---|
| | | If you want to get an idea how the tool works, look at |
|---|
| | | http://bane.cs.berkeley.edu/cqual |
|---|
| acme | its a message from Jeff |
|---|
| acme | the URL should provide enough info on cqual |
|---|
| davej | *nod*, the url has some screenshots of the tool in action too iirc |
|---|
| davej | ok, any more before we move on (to nearly the final part) ? |
|---|
| davej | right, we'll move on.. |
|---|
| acme | well, now we come to the point of how one can get involved with the Janitor Project |
|---|
| davej | the bit of the talk titled "Whats next for the janitors?" |
|---|
| acme | ok |
|---|
| acme | oops |
|---|
| acme | so, back to that bit |
|---|
| acme | well, there's still lots of things to do in the original TODO list that is available at http://kerneljanitor.org |
|---|
| acme | and Dave also volunteered to another very important janitor work: |
|---|
| davej | As well as the existing work left to do, now that 2.5 has opened, there are quite a few things that need doing already, and the amount of work is set to increase. |
|---|
| davej | (some may say rather foolishly 8) |
|---|
| acme | to make sure that the fixes that go into 2.4 finds its way to 2.5 as well |
|---|
| acme | and there's also Pat Mochel work on struct device |
|---|
| acme | that will require all drivers to use struct device |
|---|
| acme | also the block io infrastructure will require drivers to be changed, etc |
|---|
| davej | Whilst Linus is hammering away at getting the block layer in order, lots of fixes are building up in 2.4, so I volunteered to keep these in sync with 2.5 so when Linus enters 'resync mode', we have some ready-to-apply patches to send him. |
|---|
| acme | -ac became -dj |
|---|
| acme | 8) |
|---|
| * acme ducks |
| * davej grins and throws something heavy |
| davej | well... |
|---|
| acme | new generation: marcelo and davej |
|---|
| davej | I don't want it to be on the scale of what Alan was doing.. |
|---|
| * acme ducks again, fast |
| acme | but it can easily become ;) |
|---|
| davej | Alan was taking resync patches from the various architectures etc... I'd prefer to keep away from that for now at least.. |
|---|
| davej | For now I have enough trouble tracking Marcelo 8) |
|---|
| acme | <hrandoz> linux runs on a lot of architectures, 32 and 64 bit. how is kernel |
|---|
| acme | janitoring affected by that? i.e. how do you know the fix you make |
|---|
| acme | won't break another arch? what safeguards do you use? |
|---|
| davej | Plus theres a whole bunch of stuff still sitting in the old 2.4.13-ac tree |
|---|
| davej | Resyncing stuff like this is another boring tedious janitor job. |
|---|
| acme | well, we send the patches to the maintainers... |
|---|
| acme | and you see, lots of janitoring is done on code that the janitors doesn't have access to the hardware that it deals with |
|---|
| acme | thats why it is important to send it to the respective maintainers |
|---|
| acme | that will give the final word if it is correct or no |
|---|
| acme | this process, in turn, helps the janitors to learn more about what is correct and what is not |
|---|
| acme | thats why its also important to send a CC to the kernel-janitor-discuss mailing list |
|---|
| davej | maintainers of things like ppc etc tend to spot things like endian problems quite quickly in patches, as they're so used to seeing the problems, where a regular x86 hacker frequently overlooks such things. |
|---|
| acme | <voltemand> if, say, one is working on drivers for hw one doesn't have, is a |
|---|
| acme | safe compile as much as can be expected? Or...? |
|---|
| acme | some things are obviously right (famous last words) 8) |
|---|
| davej | In most cases its the best we have though. Which is why we post calling for testers when announcing various patches. |
|---|
| acme | like the set_current_state, check_region, making sure that resources are released on error paths, etc |
|---|
| davej | for common code that runs on all devices (say for eg, vfs/fs code), its a little easier, as you can test it pretty much anywhere |
|---|
| davej | Other stuff thats pending for 2.5 |
|---|
| davej | with introduction of things like bio, NAPI, and other acronyms, there'll be quite a lot of janitor type "repeat this through every driver in the tree" work |
|---|
| davej | the bio code already has gone right through nearly every scsi driver (just a few remaining to clean up) |
|---|
| davej | napi will touch quite a few network drivers in the same way |
|---|
| acme | same thing happened in the past for softirq, etc |
|---|
| davej | but perhaps one of the biggest works for 2.5 will be Pat Mochels 'struct driver' changes. |
|---|
| davej | links to info on all the pending work for these is available at http://www.osdl.org/archive/rddunlap/linux-port-25x.html |
|---|
| davej | including some very descriptive documentation on the struct driver changes. |
|---|
| acme | and please notice that lots of janitor tasks needs to be repeated all over again |
|---|
| davej | By changing this over, not only will it end up in cleaner code (hopefully), but we'll also end up with a much more unified power management infrastructure almost for free. |
|---|
| acme | as old bugs have the bad habit of resurfacing from time to time ;) |
|---|
| davej | and through usage of driverfs, every driver will automagically show up there in a sort of 'device registry' |
|---|
| davej | <movement> ah, related actually. documentation of the api is crucial in oreder for it to be used right by random driver X. lack of docs has led to loads of bugs needing janitoring. are any of you working on the api docs much ? |
|---|
| davej | Documentation is vital to this project. |
|---|
| davej | Without knowing why we should change something, when we should change it, we'd all be completely lost. |
|---|
| acme | one guy had volunteered to do that in the kjp mailing list, but hasn't produced much, so we need volunteers for that, yes 8) |
|---|
| davej | As well as cleaning up interfaces, simple tasks like adding docbook headers to functions is always a good way to win extra points. |
|---|
| davej | we also have items on the TODO such as 'remove the warnings/errors that appear when building the autogenerated docs" |
|---|
| acme | people like Rik van Riel and wli have been doing that for the areas that they work on |
|---|
| davej | Indeed. It's even more important in areas that affect so many other parts of the kernel also (such as the vm layer) |
|---|
| acme | now we only have to convince Andrea of that ;) |
|---|
| * davej hides |
| * acme runs |
| davej | ok, I think we've covered everything on our talk plan, unless acme spots something I missed... |
|---|
| acme | oh, the janitor irc channel |
|---|
| davej | oh yes.. |
|---|
| davej | Something we've toyed with for a while, and really considered doing, but never found the time so far... |
|---|
| acme | there's already the #kernelnewbies channel, but we think that a #janitor channel would be useful as well |
|---|
| davej | At some point in the hopefully near future, we'll open a #janitor on openprojects.net, and hang out there for a weekend, giving help to anyone who wants to get started with the project. |
|---|
| acme | till then everyone is invited to the #kernelnewbies channel at irc.openprojects.net |
|---|
| davej | of course, if people want to continue it after the weekend, they are free to do so 8) |
|---|
| acme | s/free/encouraged/ 8-) |
|---|
| davej | if/when we actually do this, we'll announce it beforehand in a few places. |
|---|
| davej | and I *think* thats all... acme ? |
|---|
| acme | so, any more questions? |
|---|
| * acme is done |
| davej | Q&A time.. |
|---|
| acme | come on, was it so boring? :-) |
|---|
| davej | I think we made everyone sleep early... |
|---|
| acme | haha |
|---|
| acme | well, I think that we can move to here |
|---|
| HoraPe | clap clap clap clap clap clap clap |
|---|
| HoraPe | clap clap clap clap clap clap clap |
|---|
| HoraPe | clap clap clap clap clap clap clap |
|---|
| HoraPe | clap clap clap clap clap clap clap |
|---|
| HoraPe | clap clap clap clap clap clap clap |
|---|
| HoraPe | clap clap clap clap clap clap clap |
|---|
| HoraPe | clap clap clap clap clap clap clap |
|---|
| velco | clap clap |
|---|
| velco | clap clap |
|---|
| velco | clap clap |
|---|
| OrozZz | plas plas plas plas clasp plas plas :) |
|---|
| davej | just a second! |
|---|
| fernand0 | plas plas plas plas plas plas plas plas plas |
|---|
| davej | go wli |
|---|
| fernand0 | plas plas plas plas plas plas plas plas plas |
|---|
| fernand0 | plas plas plas plas plas plas plas plas plas |
|---|
| HoraPe | davej, acme, lots of thanks, it was a great talk |
|---|
| fernand0 | plas plas plas plas plas plas plas plas plas |
|---|
| fernand0 | plas plas plas plas plas plas plas plas plas |
|---|
| wli | I remember there was some mention of tasks that were search & replace. But I've heard that search and replace operations are not considered "good ideas". Can you mention the distinction between the good & bad search and replace? |
|---|
| HoraPe | we can continue with the q&a now... |
|---|
| peter | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas clap clap clap clap clap,clap clap clpa clap clpa clap clap clap |
|---|
| peter | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas clap clap clap clap clap,clap clap clpa clap clpa clap clap clap |
|---|
| peter | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas clap clap clap clap clap,clap clap clpa clap clpa clap clap clap |
|---|
| HoraPe | we can continue with the q&a now... |
|---|
| davej | <hrandoz> some of the documentation of code actually appears in lkml. is there any effort to grab these bits for documentation? |
|---|
| davej | Well, sometimes this ends up as inline docs. |
|---|
| davej | but sometimes explanations are a little too verbose (too verbose docs ? never!) |
|---|
| acme | 8) |
|---|
| davej | I'd like to see the autogenerated docs get a lot better personally. |
|---|
| davej | Currently, they're good for seeing arguments a function takes, but they don't tell you for eg, locks that the function takes, needs etc... |
|---|
| * acme seconds that |
| davej | <movement> dropping that awful kernel docs script should be a high priority :) |
|---|
| acme | <HoraPe> can you repeat the url of the project? |
|---|
| acme | http://kerneljanitor.org |
|---|
| acme | or http://kerneljanitors.org |
|---|
| davej | movement: I'm not fully familiar with it.. |
|---|
| wli | Is adding kernel documentation one of the goals of the janitor project? |
|---|
| davej | movement: if you have ideas on how it could be improved, we'd be happy to add it to the TODO |
|---|
| acme | wli: nope, but that would be a nice project or addition to the KJP |
|---|
| davej | wli: It's something that happens occasionally, but not something we set out to do. |
|---|
| wli | Perhaps correcting comments that no longer match the code? |
|---|
| davej | oh definitly. |
|---|
| acme | definetely |
|---|
| davej | <movement> davej, I reckon you lot should use a /real/ source doc tool (doxygen or similar) |
|---|
| acme | and turning already existing doc comments into kernel-doc style |
|---|
| davej | movement: the only problem there would be adding an extra dependancy.. (Ok, the docbook stuff we already have is a dependancy, but its an established one already... ) |
|---|
| acme | movement: that would require a sacred penguin pee approval |
|---|
| acme | 8) |
|---|
| davej | acme: tbh, I don't think Linus particularly cares too much about that, as long as whatever format is chosen isn't too intrusive in the source. |
|---|
| acme | but you're free to propose that in the linux-kernel ml, together with a proof of concept |
|---|
| davej | docbook won I think because its completley human parsable by reading a source file with vim/emacs/whatever |
|---|
| acme | i.e. changing one piece of code to doxygen style, for instance |
|---|
| * davej narrowly avoid editor holywars and goes back to the documentation-standard holywar instead |
| acme | IIRC the rpm codebase uses doxygen |
|---|
| acme | so it could be used as a proof of concept of the advantages of changing the doc-standard in the kernel |
|---|
| davej | there is also another problem.. |
|---|
| davej | drivers like acenic for eg, which compile under 2.2 / 2.4 / 2.5 |
|---|
| davej | if we change the docbook to whatever... do we have two different sets of comments in the code ? :-) |
|---|
| acme | <HoraPe> davej avoid editor holywars and acme enters into packaging holywar |
|---|
| acme | instead :-) |
|---|
| acme | hey, nope |
|---|
| acme | I just said that the rpm _codebase_ uses doxygen, not that rpm is better (which it is, btw ;) ) |
|---|
| * acme runs |
| * davej takes this opportunity to run to the fridge, brb.. |
| davej | <movement> you can't even do xrefs with kernel-doc :( |
|---|
| davej | reminds me... tools like ctags are also extremely useful in janitor work.. |
|---|
| davej | (This almost has become a kernel hackers toolbox talk 8) |
|---|
| acme | yes, cscope as well |
|---|
| davej | indeed. |
|---|
| * acme uses only ctags, tho |
| acme | make tags |
|---|
| acme | vi -t kfree_skb |
|---|
| acme | just that :) |
|---|
| acme | <HoraPe> what is cscope? |
|---|
| acme | its a ctags lookalike on steroids |
|---|
| davej | http://cscope.sourceforge.net/ |
|---|
| davej | It's a really old tool that SCO opened some time ago. |
|---|
| acme | but never the less very useful and more powerful than ctags |
|---|
| davej | the webpage there shows some of the features it has, and you can probably guess from reading how they are useful to janitor work 8) |
|---|
| davej | <HoraPe> what's the procedure a kernel janitor must follow when submitting patches? send them to the maintainers and cc:ing kj-discuss mailing list? |
|---|
| acme | yes |
|---|
| davej | a good question that a lot of people overlook. |
|---|
| davej | but you hit the nail on the head 8) |
|---|
| acme | when Alan was very active I sent the patches to the maintainers, Alan and the kernel-janitor-discuss |
|---|
| acme | i.e. very active on his -ac series of patches |
|---|
| davej | another piece of advice.. if you are going to do a large scale clean up (through lots of drivers).. do one, get feedback to make sure you're doing it right, then go to do the others. |
|---|
| davej | This can save you a lot of wasted time. |
|---|
| * acme remembers of the janitor wars with Hans Grobler 8) |
| acme | wars as in coopetition, whatever :) |
|---|
| acme | Alan said once "Hey, Hans Grobler beated you in this one" |
|---|
| acme | because the same janitor patch I had send he had already received from Hans :-) |
|---|
| davej | ah, another thing worth noting.. |
|---|
| acme | South African guy, has been quiet for quite a while... :( |
|---|
| davej | before embarking on a large scale clean up, let the janitor discuss list know that you are going to do so.. |
|---|
| acme | yes |
|---|
| davej | otherwise we can have two people doing the same thing 8) |
|---|
| davej | (we tend to be more tolerant toward newbies than the kernel list too, so if you're not sure you're doing the right thing, it's always a good idea to send there first..) |
|---|
| davej | well I think I'm all done.. I hope to see janitor patches from some of you sometime 8) |
|---|
| davej | Thanks for listening.. |
|---|
| HoraPe | ok, i'll add to the list of things to do when bored of working :-) |
|---|
| davej | s/listening/reading/ 8) |
|---|
| HoraPe | Thanks you for coming here. |
|---|
| HoraPe | And thanks for your work cleaning our kernel. |
|---|
| acme | Thanks to the Uninet folks to organise umeet! |
|---|
| davej | yes! thanks ! |
|---|
| HoraPe | We hope seeing you here next year. |
|---|
| acme | and we _really_ expect new janitors! 8) |
|---|
| riel | acme,davej: I promise to clean up the vmscan.c in my VM ;)) |
|---|
| davej | oh one very final thing.. if anyone has any further questions later.. either see acme or myself on irc, or send to janitor-discuss@lists-sourceforge.net |
|---|
| * riel hopes other people will also clean up their code |
| acme | riel: wohoo, you'll get extra brownie^Wjanitor bonus for that! |
|---|
| acme | s/bonus/points/ |
|---|
| fernand0 | thank you to all for comming |
|---|
| riel | davej: what irc channel ? |
|---|
| riel | davej: #janitor on irc.openprojects.net ? |
|---|
| davej | #kernelnewbies of course 8-) |
|---|
| davej | or there when we open it.. |
|---|
| fernand0 | i suppose this closes this year's umeet |
|---|
| riel | ok, #kernelnewbies it is |
|---|
| acme | davej: kernel-janitor-discuss@lists-sourceforge.net |
|---|
| cronos | guess i'll clean my own pelr code, since i'm not a kernel hacker : ) |
|---|
| davej | acme: oops, yes... corrected email address.. |
|---|
| acme | :) |
|---|
| riel | cronos: clean code is good |
|---|
| fernand0 | we hope to see all of you (and some new people) next year |
|---|
| cronos | : ) |
|---|
| davej | cronos: feel free to clean the janitor perl script I did 8) |
|---|
| fernand0 | until then... |
|---|
| riel | cronos: laziness in writing clean code, only leads to _more_ work |
|---|
| acme | instructions are in http://kerneljanitor.org to subscribe the list |
|---|
| fernand0 | if you think you can organize something here |
|---|
| fernand0 | give a lecture, have a meeting |
|---|
| fernand0 | or something like this |
|---|
| cronos | riel -wT and also strict help with that in perl |
|---|
| fernand0 | feel free to conctact us |
|---|
| acme | fernand0: thanks in advance |
|---|
| * cronos likes C, but thinks perl is more fun : ) |
| fernand0 | thank you to all: participants, lecturers, and people who helped to organize this |
|---|
| cronos | not, for kernels, do |
|---|
| riel | fernand0: you organised a wonderful Umeet this year, thank you |
|---|
| cronos | i second that |
|---|
| fernand0 | all of us organized it |
|---|
| riel | yes, but some of us organised it more than others ;) |
|---|
| cronos | he, yes |
|---|
| zuez | yes |
|---|
| E-D-W-I-N | Hello fernando it´s ending the UMEET 2001 |
|---|
| fernand0 | every hand is welcome |
|---|
| zuez | thanks a lot |
|---|
| fernand0 | even clapping hands ;) |
|---|
| fernand0 | yes edwin |
|---|
| zuez | word |
|---|
| * acme praises the umeet folks |
| E-D-W-I-N | Clap Clap Clap Clap Clap Clap Clap Clap Clap Clap Clap Clap!!! |
|---|
| E-D-W-I-N | Clap Clap Clap Clap Clap Clap Clap Clap Clap Clap Clap Clap!!! |
|---|
| acme | clap clap clap clap clap clap clap clap clap clap clap clap |
|---|
| E-D-W-I-N | Clap Clap Clap Clap Clap Clap Clap Clap Clap Clap Clap Clap!!! |
|---|
| acme | clap clap clap clap clap clap clap clap clap clap clap clap |
|---|
| acme | clap clap clap clap clap clap clap clap clap clap clap clap |
|---|
| acme | clap clap clap clap clap clap clap clap clap clap clap clap |
|---|
| acme | clap clap clap clap clap clap clap clap clap clap clap clap |
|---|
| E-D-W-I-N | Clap Clap Clap Clap Clap Clap Clap Clap Clap Clap Clap Clap!!! |
|---|
| HoraPe | plas plas plas plas plas plas |
|---|
| HoraPe | plas plas plas plas plas plas |
|---|
| HoraPe | plas plas plas plas plas plas |
|---|
| HoraPe | plas plas plas plas plas plas |
|---|
| riel | WOOOOOHOOOOOOO |
|---|
| acme | and, of course |
|---|
| riel | clap clap clap clap clap clap |
|---|
| riel | clap clap clap clap clap clap |
|---|
| * HoraPe claps in spanish :-) |
| * cronos goes back to his cave , later all |
| riel | clap clap clap clap clap clap |
|---|
| riel | clap clap clap clap clap clap |
|---|
| acme | plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|
| acme | plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|
| acme | plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|
| acme | plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|
| acme | plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|
| fernand0 | plas plaspl plas plasp las plas plas plas |
|---|
| fernand0 | plas plas plas plas plas plas plas |
|---|
| fernand0 | plas plas plas plas plas plas plas |
|---|
| acme | plas must be the translation of the portuguese "Clap" :) |
|---|
| zuez | crono, in your grave theres no pain! |
|---|
| E-D-W-I-N | plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|
| E-D-W-I-N | plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|
| E-D-W-I-N | plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|
| E-D-W-I-N | plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|
| E-D-W-I-N | plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|
| fernand0 | and spanish also ;) |
|---|
| cr0ut | zuez no pain no gain ; ) |
|---|
| peter | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plass |
|---|
| peter | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plass |
|---|
| peter | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plass |
|---|
| zuez | the more you think.. the more you sink.. |
|---|
| zuez | ;) |
|---|
| peter | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plass |
|---|
| peter | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plass |
|---|
| peter | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plass |
|---|
| cr0ut | zuez the more i sink the more i see |
|---|
| zuez | bbl, rolling to spectrum |
|---|
| cr0ut | opps, stink : ) |
|---|
| E-D-W-I-N | And what about the next year... |
|---|
| HoraPe | E-D-W-I-N: you'll be spammed when next year umeet's date gets set |
|---|
| E-D-W-I-N | fernando so many people asked me, if have the oportunities to give help to finance some proyects in limux |
|---|
| fernand0 | who is supposed to finance people ? |
|---|
| HoraPe | E-D-W-I-N: dilo en castellano, que no se te entiende |
|---|
| E-D-W-I-N | ok |
|---|
| E-D-W-I-N | me preguntaban si existen organizaciones que financien proyectos de linux |
|---|
| fernand0 | supongo que si |
|---|
| HoraPe | sí |
|---|
| fernand0 | dependerá del tipo de proyectos |
|---|
| E-D-W-I-N | especialmente en universidades |
|---|
| HoraPe | si consigues "venderle" a algun organismo/empresa algún proyecto de linux te lo financiarán |
|---|
| tapselj0 | hello |
|---|
| fernand0 | nunca he visto una universidad con dinero ;) |
|---|
| HoraPe | (en la argentina el ministerio de economia tiene un grupo de gente trabajando en linux, |
|---|
| fernand0 | salvo algunas norteamericanas, claro |
|---|
| HoraPe | en algunas universidades puedes conseguir beca de investigacion si tu proyecto |
|---|
| E-D-W-I-N | es mas que todo para los alumnos, para que puedan desarrolarse mas de lo aspiran |
|---|
| HoraPe | les interesa, etc) |
|---|
| HoraPe | E-D-W-I-N: pues, que busquen becas :-) |
|---|
| acme | out of curiosity, what are the countries people here are living? |
|---|
| acme | Brazil |
|---|
| fernand0 | palabra mágica |
|---|
| HoraPe | acme: AR |
|---|
| JohnFlux | Has anyone attempted to write a program that detects (most) divide by zero's, infinite loops, etc? |
|---|
| JohnFlux | (I'm fully aware of the halting problem - but has someone tried it anyway?) |
|---|
| fernand0 | spain |
|---|
| fernand0 | well |
|---|
| fernand0 | is a bit later here |
|---|
| fernand0 | hope to hear from you |
|---|
| fernand0 | _before__ next umeet ;) |
|---|
| fernand0 | bye |
|---|
| HoraPe | i've seen people from FR, HR, DO, CU and CO today... |
|---|
| Oroz | hr? |
|---|
| HoraPe | croacia |
|---|
| E-D-W-I-N | and PE too |
|---|
| riel | hr = hungary |
|---|
| acme | nope |
|---|
| acme | hu == hungary |
|---|
| riel | mmm indeed |
|---|
| riel | weird |
|---|
| acme | hr = Hvratska |
|---|
| bodhi | res |
|---|
| riel | duh ;) |
|---|
| acme | Croacia in their simple language ;) |
|---|
| HoraPe | :-)))) |
|---|
| tony | hi people |
|---|
| acme | well, time to go guy some beers, essential need |
|---|
| tony | when i just arrived |
|---|
| acme_bbl | s/guy/buy/ |
|---|
