[07:11] what's the kernel magic that replaces code at boot-time? like for the smp vs uniproc code? I can't find it at the moment... [09:10] Hi, could anyone help me with kernel upgrade [09:12] I am trying to upgrade the kernel from here : http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.36-maverick/ [09:13] The problem is I don't understand what the patch stands for (in terms of kernel upgrade) [09:13] and if they are of importance how do I apply it [09:14] or is the kernel already patched [09:25] hi [09:25] I am plying with ubuntuization of kernel for one of my machines (unsupported by ubuntu) and have a problem with ABI check === yofel_ is now known as yofel === oldkid_ is now known as oldkid === BenC_ is now known as BenC [22:45] Could someone please give a kernel-level project idea for ubuntu [22:46] I'd like to contribute in the kernel development [22:47] like I said earlier(about a day or two) I have kernel hacking experience in FreeBSD like implementing my own process scheduling algorithm, page replacement algorithm [22:55] blahsphemer: What sort of project are you after? [22:56] RAOF, I really can't define anything specifically cuz I. [22:56] am onl starting out now [22:56] *only [22:57] I'd like to work only on the kernel though [22:58] Well, generally the plan would be to find something that you want to work and make it work. [23:00] I'd quite like someone to play around in the input subsystem (the /dev/input/event* nodes) to change their behaviour from multicast to all open fds to unicast to one open fd + an ioctl to switch which fd gets the input :) [23:05] RAOF, sorry, I didn't see your post cuz it wasn't highlighted. [23:05] No problem :) [23:06] RAOF, quite frankly, I followed nothing after the work 'behaviour' [23:06] Heh. [23:07] So, currently, every open fd of /dev/input/event* gets all input from that device. [23:07] It would be useful if it were possible to restrict it so that exactly one open fd got the input, and there was an ioctl to switch which fd is currently getting input. [23:08] Does that make more sense? [23:08] fd? [23:08] File descriptor [23:08] aaah [23:08] now it makes sense [23:08] Jesus [23:09] Sorry, I thought that terminology would be shared with the BSD kernels. :) [23:09] I have only heard the full term being thrown around, no acronyms. My bad. [23:12] blahsphemer: I've not investigated that code at all, but it seems like it should be relatively easy to do. And quite useful :) [23:13] RAOF, Sounds great. I am googling some basic stuff about it. Could you point me to some link, just so that I get to the point directly instead of skimming through bad results [23:17] blahsphemer: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=drivers/input/evdev.c;hb=HEAD is the evdev code which would need to be modified. [23:18] Good lord, that was lightning fast considering the fact that you said you haven;t looked through the code [23:18] ;) [23:19] I knew evdev was what you were after; drivers/input/evdev.c is a pretty obvious guess after that :) [23:19] heh [23:33] RAOF, Do you think this would be of any use: http://www.opengroup.org/onlinepubs/9699939699/toc.pdf [23:34] I have no idea about fd's. So I thought I must get my basics right [23:40] blahsphemer: That's probably not going to be a whole lot of use; it's only indirectly relevant. [23:40] good morning RAOF [23:41] Good eventide bryceh [23:42] okay. But is there some sorta write up and not the 'code' itself where I can gather the fundamentals before I could land my hands upon the kernel [23:42] I hope you get what I am trying to say [23:42] Yeah, I do. [23:44] I am reading the wiki article right now. If you'd like me to read some text (book or web article) I'd be glad [23:45] blahsphemer, there's a lot of books published with kernel hacking fundamentals, which are in various states of semi-obsolescence, many of which can also be found online [23:45] www.xml.com/ldd/chapter/book/ch03.html is a somewhat out of date primer on char devices. [23:46] blahsphemer, you might also want to peruse the "kernel janitor's todo list" which has some simpler tasks if you're looking for smallish starter projects [23:47] bryceh, I wanna hit and I wanna hit hard ;) the fd thing sounds fun [23:47] RAOF, very kind of you not to hoodwink him into implementing 8xx kms support ;-) [23:48] * blahsphemer struggles to comprehend the complexity in whatever bryceh just said :) [23:48] bryceh: That's slowly coming along; if I'm reading intel-gfx right, the rewriting of AGP and gem might land in the next couple of kernels :) [23:48] RAOF, huh well I'll count chickens later [23:49] Maybe the kernel support will be there before the all silicon is broken by electron-migration ;) [23:49] Funny thing is that my OS professor specifically asked us not to involve ourselves in any sorta device driver development [23:50] cuz according to him we'd be stuck there for our entire life [23:50] my bed is they'll get it working right before we switch to wayland, and then they'll have to redo it all [23:50] hehe [23:50] blahsphemer, it's true [23:50] This isn't really device driver development, luckily. [23:50] :) [23:52] in another channel, someone said that it'd really help if I worked on Wayland cuz it's soon making its way into both fedora and ubunyu [23:52] that's not really kernel development though [23:52] This *is* working on Wayland. Just indirectly :) [23:52] RAOF, o_O [23:53] for sufficiently broad definitions of "wayland" ;-) [23:53] Specifically, this is making it possible to remove input routing priviledges from Wayland. [23:53] speaking of which... I was able to get wayland working on i945 this morning [23:53] (and gm45 the other day) [23:53] Are the flowers beautifully rendered? [23:54] :) [23:54] Also, cool. [23:54] they are [23:55] RAOF, speaking of which... I nearly have the packaging done, so at some point this week I'd appreciate it if you could block out a couple hours to do a review of my mesa packaging changes [23:55] Certainly. [23:55] RAOF, thanks, I'll let you know when I feel it ready [23:57] okay, so I am going to read this now www.xml.com/ldd/chapter/book/ch03.html and when I'm stuck at something, I'll hit the room again :)