@sarnold	i'd like to welcome everyone to the final event of this year's uninet UMeet conference
@sarnold	our final event is a 2.5 linux kernel round table summit
@sarnold	and we have been lucky enough to borrow some time from dave jones, robert love, andrew morton, and possibly cameo appearances by rik van riel, greg kroah-hartman, chris wright, pat mochel, and others :)
@andre	sheesh every geek and freak is hear, glad I woke up in time to be one here
@zwane	hehe
@sarnold	i'd like to mention we have translations in #taee to dutch (thanks garoeda) and to spanish in #redes (thanks arador and others!)
@davej	(Lets see them try and keep up with 4-5 speakers 8-)
@sarnold	please direct your questions to #qc; I'll cut and paste them into #linux for discussion by our esteemed team :)
@sarnold	with that, lets open to some generic questions:
@sarnold	what do you guys feel repesents the biggest improvements for users in the 2.5 series of kernels?
* davej waits for rml to shout 'preempt'
@rml	haha
@sarnold	:)
@rml	no no... its the VM :)
@akpm	1) improved device managemability (when it gets finished)
@akpm	2) less latency when there's heavy writeout
@akpm	the device manageability is important for "large" users.  The latency issue for desktops.
@rml	in general, better coupling of the VM and block I/O
@sarnold	rml: i recall reading one of marshall kirk mckusick's goals is seeing VM and the file system "finally merged" .. what do you think this means for an OS designer?
@gregkh	the device managebility is also useful for "small users" who want to tell which USB drive is which.
@andre	This is a fair question, and an issue most of us forget to address: <mulix> what do you guys feel represents the biggest change for out-of-tree developers to cope with?
@rml	it means they are entirely integrated. and in reality, they are much the same thing. everything goes through the VM, so they need to be tightly coupled
@gregkh	mulix: The many API changes that have happened.  there are a lot of them for drivers.
@sarnold	how does the integration of VM and block IO mean for applications such as databases?
@davej	I've been meaning to a hackers-eye-view version of my post-halloween doc, but haven't managed to find the time to cobble something together yet
@davej	I'll try and get some bare-bones done soon, post that, and let everyone else flesh it out like what happened with the other doc. 8)
@akpm	andre: the removal of cli()/sti() and changed locking rules would affect out-of-tree kernel code a lot.
@sarnold	< imbezol:#qc> would it be possible to have a quick introduction of the speakers.. what role they play in the kernel devlopment/community?
@sarnold	imbezol: ah, yes, introductions :)
@sarnold	andre is the IDE master ..
@sarnold	bacchus is master of MIPS
@sarnold	cdub and gregkh do LSM
@sarnold	gregkh does USB
@sarnold	mochel does device management
@sarnold	rml does pre-empt
@mochel	rml is the pretty boy ;)
@sarnold	and dave jones, i'm not entirely sure :) I seem to recall x86-64 video drivers .. davej? :)
@rml	no no mochel is
@davej	whatever takes my fancy at the time 8)
@sarnold	(and just a side note, both mochel and rml are pretty boys :)
@rml	don't forget akpm, who is well known for doing everything at one time or another
@davej	in the last year I've covered quite a few areas from porting 2.4 bits forward just after the split, some x86-64 bits, and right now I'm knee deep in agpgart.
@sarnold	devlopment/community?
@davej	rml: indeed. I still reckon akpm is an alias for a room full of hackers 8)
@rml	haha... he learned to fork() himself like Alan
@sarnold	rml, something you missed while reconnecting..
@rml	OK, enough about ourselves - aside from mochel and his war stories from 'nam we are not interesting... next question?
@akpm	my secret is to avoid drivers ;)
@rml	akpm: didn't you use to maintain the network drivers? :)
@sarnold	you mentioned unifications of VM and block IO ..
@sarnold	how would this work with database vendors, who typically want to just run the entire machine as if they were the OS itself?
@andre	One of the questions I have for the folks here I work with is the issue of making or cleanup the grey zone of derived and pristine work so more poeple could uses Linux in Business and not have to hire lots of legal teams because of the greyness
* gregkh runs away from andre's question
* andre expects to killed now
@akpm	rml: yes, that is still somewhat the case, but I spend almost zero time on net drivers now.
@rml	sarnold: O_DIRECT or raw I/O and be happy, I guess... they can avoid a lot of the kernel if they want
@gregkh	andre: we are developers, not lawyers, please, not here.
@andre	okay
@rml	only technical questions
@davej	<ShawnWerk> (*cough* PnP)
@akpm	sarnold: big databases tend to take over the machine.  They try to avoid using or being dependent upon VM or even filesystems.
@davej	pnp stuff has pretty much been overhauled a lot.
@sarnold	one thing I've noticed is that people such as rml (robert love) work primarily on desktop responsiveness issues, such as pre-emptable kernel (to lower latency) ...
@akpm	sarnold: for databases, direct-io is critical.  And things like hugetlb pages, pagetable sharing.
@rml	.. and the scheduler
@davej	shawn: I don't think there's any specific documentation as to what has changed.
@sarnold	and other people, such as wli (william lee irwin) are mostly interested in huge systems, where throughput tends to be the dominate goal..
@sarnold	is there a happy medium between responsiveness and the throughput forseen in the 2.5 kernel? How does it comapre with 2.4?
@davej	gregkh: you pushed the pnp bits, any insight?
@rml	Eh, good question. It is a trade-off
@andre	one of the strongest block changes lately came from Oracle, superbh
@akpm	sarnold: 2.5 is very much tuned for responsiveness.  Often this also means improved throughput.  But sometimes not.
@gregkh	ShawnWerk: yeah, the pnp layer has changed a lot, but sorry, no docs that I know of.
@sarnold	andre: care to elaborate on superbh?
@andre	it is a way to do direcut 10%t io submissions in a batch, and drops the bh overhead bloat in 2.4 by ab
@andre	instead of dealing with single sector/wait-for issues, you can effectively batch a list of iovecs to block and let it rock
@davej	ShawnWerk: porting the pm bits from 2.4 has been on my TODO for a while. I intentionally left it out when I was bringing bits forward a few months back, as it still had some problems
@sarnold	andre: is there any relationship between superbh and benjamin's asynchronous IO?
@andre	not that I can tell, one is a submission process and the latter is an execution process
@davej	ShawnWerk: not sure, I'd have to play with it to say for sure.
@sarnold	one issue I see particularly frustrating the needs of both high-throughput and high-responsiveness users is the new O(1) scheduler from ingo..
@davej	ShawnWerk: is it using the pci_driver api ?
@sarnold	what problems does the O(1) scheduler have for interactive users, what problems does it have for high-throughput users, and what do you think can be done to help it?
@akpm	sarnold: I don't think they're necessarily related.  Not on uniprocessor anyway.
@akpm	sarnold: the scheduler has scalability enhancements, and it has "interactivity" enhancements.
@akpm	sarnold: it is the interactivity enhancements which aren't fully worked out yet
@rml	Unix traditionally always favors interactivity over throughput in the scheduler
@zwane	akpm: i take it you're not a fan of something like a kautotuned which would adjust various kernel parameters depending on sampled system stats, any reason why the aversion to such a method?
@sarnold	akpm: i recall reading that realtime-scheduled processes (SCHED_RR, SCHED_FIFO) are seeing huge latency with the O(1) scheduler; are those problems related to the interactivity enhancements?
@rml	sarnold: no, the real-time tasks are not affected by the interactivity estimator. the are "static priority" classes
@rml	further, no non-real-time task can have its priority boosted to that of real-time by the interactivity estimator
@rml	the only real-time regression wrt the scheduler that I am aware of is on SMP.  since we have per-CPU runqueues, it is possible for a real-time task to be starved on one processor when another is capable of running it
@akpm	zwane: the concern I have with anything which tunes the kernel based on observed load patterns is that it will get it wrong when the load suddenly changes.
@sarnold	rml: are there regressions in the rest of the 2.5 series of kernels? is there anything that performed better on 2.4?
@rml	sarnold: akpm was just looking at some of that...
@zwane	akpm: hmm, indeed this wouldn't work for realtime tuning and therefore more adaptive, but we still make wrong decisions now anyway
@Bacchus	sarnold: Such preformance regressions are typical during development.
@rml	most things are an improvement (however slight), although we purprosely may of compromised throughput for fairness in some cases
@andre	<mas> Hi, I wanted to know panel's idea about the MSFT's trusted computing environment that basically means (to me as a programmer): hardware won't run the software not signed by a trusted party of MSFT? In what ways it'll affect Linux communitiy and development efforts for it?
@rml	but akpm perhaps can talk about his recent discoveries on 2.5 regression?
@zwane	rml: is it not possible to do a migration? or would it be too expensive?
@Bacchus	sarnold: There is alot of fine tuning going toward the end of the 2.5 phase and early 2.6 phase to fine tune performance.
@andre	This is similar to our "tainting process", we use it as a means to determine if it is a true kernel issues or a bad binary closed source monster
@rml	zwane: it probably is... we could do something to at least ensure the rt-tasks were evenly distributed.  the only 'perfect' solution is a global runqueue for real-time tasks, like the O(1) scheduler originally had
@sarnold	akpm: is there anything in 2.5 that users will be dissapointed about compared to 2.4?
@andre	both gregkh and manfred can better answer the question
@akpm	sarnold: not really.  There are slowdowns, but they are small.  The worst ones are due to the rmap additions to the vm.
@akpm	sarnold: for some workloads which do a *lot* of forking (eg shell scripts) it can be up to 10% slower
@sarnold	akpm: i recall daniel philips talking about copy-on-write pagetables; has any effort been expended to help this problem?
@akpm	I think we may be able to get that back via the pagetable-sharing code.  Still thinking about that.
@akpm	sarnold: yes, that's all working now.  But for the shell-script case, all the pagetables get written to and copied anyway :(
@sarnold	akpm: heh :)
@akpm	so I'm wondering if we can change binutils to lay userspace virtual addresses out in a different way, to prevent that
@sarnold	akpm: that would involve an amountv of randomization or analysis of the libc and program mappings, no? would that cause too many TLB flushes?
@gregkh	regarding the msft trusted computing stuff, I can't say anything except that people are looking at how it will affect linux, and how linux will run on such hardware.
@akpm	sarnold: it could require an additional tlb entry.  Probably that's not very significant...
@davej	*cough* Linuxbios *cough*
@sarnold	davej: one problem i've imagined linuxbios to have is reliance on a specific motherboard model; is hardware design such that linuxbios, or other opensource bios projects, could be more general?
@davej	sarnold: from what I can see its dependant on knowing lots of board specific layout (like how the dram banks are wired for eg)
@cdub_	mas: there are some scary implications of TCPA and opensource code.  also allegations that it is enforceable DRM by another name.  but this will take a while to flush it all out.
@sarnold	<Phantom> Why isn't IPSec included in the Linux kernel yet (or is it inthe latest 2.5)?
@rml	Phantom: it is in the newest 2.5
@rml	there were some initial issues with cryptography in the kernel, which have long sense been solved.
@davej	http://lartc.org/howto/lartc.ipsec.html is a mini-howto on making that stuff work...
@sarnold	rml: do you know if it works with the FreeS/WAN userland utilities, such as the key negotiation daemons?
@rml	then the network maintainers had some quality of code/taste issues, and they wanted to do a lot in a different way... so we have a fairly new implementation in 2.5
@davej	sarnold: uses a fork of the KAME utilities afaik
@rml	in fact, we have a whole crypto layer in the kernel now
* davej notes Alexey moved the location of the utilties, and goes to update the post-halloween doc
@sarnold	(in fact, james morris, one of the authors of the crypto layer, did a presentation on it a few days ago for umeet :)
@andre	rml: since everything is is going modular even me, ipsec should be also to decide if we do it soft or hook and redirect to offload on the nics
@sarnold	how about end-user friendlyness issues; someone had asked if supermount would be included in the mainline kernel eventually; another asked if Oopses on mounting CD roms would be made less likely..
@rml	I do not think we will see supermount
@rml	I think oopses on mounting devices will get better as the drivers get better... hopefully we have made some progress. oopses are never good
@rml	arashi asked: how's async i/o going? i noticed it's in "before 2.6" status on Guillaume's list ...
@rml	AIO is in now
@sarnold	rml, but supermount and devfs appear to be popular among at least some users; what is the criteria used for deciding which features are merged in?
@rml	sarnold: I think supermount is "not popular enough" for something that is not entirely elegant
@davej	Juan Quintela spent a lot of time in the last year cleaning up supermount, and it'd still need a lot of work by the sounds of it before it got past viro and the likes.
@rml	Yes, I think a large obstacle is Al Viro is the maintainer for that subsystem and his standards are very very high
@davej	Alan has a work-alike hack using NFS over loopback or something equally as twisted.
@rml	I would not want to be the fellow who submitted supermount to viro
@davej	ISTR thats all userspace too, which is nice 8)
@sarnold	<mulix> what do you guys think about the variety of kernel trees we have lately? too many, not enough? ... are they infact not helping the World Domination Plans?
* davej goes to the fridge whilst waiting for translaters 8)
@sarnold	(i'd like to add, "is World Domination even a plan worth persuing?")
@sarnold	davej: good idea! :)
@akpm	sarnold: I beleive that the UL and RH trees have diverged too far from mainline.  We should work harder to get changes fed back.
@rml	I think external kernel trees are very important and useful when the tree is maintained by a developer and he is using the tree has a testbed and holding ground for patches to feed to mainstream
@akpm	sarnold: but I don't think it has caused any serious problems.
@zwane	mulix: most of the trees right now are for merging purposes and not mainly forks
@rml	i.e., trees like 2.5-mm and 2.5-dj are very important
@sarnold	akpm: do you think RH's and UL's kernel maintainers have an obligation to feed changes back to mainstream? marcelo can only merge so quickly and still call 2.4 a stable kernel..
@akpm	sarnold: well bugfixes should come back to marcelo quickly.  Features are less important.
@akpm	sarnold: although it could be the case that there aren't many unmerged bugfixes.  Not sure.
@akpm	sarnold: but the size of the diffs is a little distressing.
@rml	I read UL has nearly 800 patches.  that needs to be brought done
@akpm	and I must attend a meeting, sorry..
@sarnold	akpm: thank you for your time :) have a good weekend.
@davej	rml: *nod*, though a lot of the bits in UL will either never see mainline, or is backports of 2.5 features 8)
@sarnold	a similar question, <Lovechild> is there's any plans to merge Reiser4 soon ?
@rml	Lovechild: that is really Linus's decision entirely
@davej	reiser4 is a lot of code. (around 2MB iirc)
@rml	I think if it has zero or minimal impact to non-reiser4 specific code, it will be merged
@davej	thats a lot of code for a filesystem.
@rml	but I have a feeling it may be intrusive... as davej said, 2MB is a lot for a filesystem
@rml	its much too late to merge anything instrusive, and I hope Linus does not if it is.
@davej	there were only iirc 3 parts that touched outside fs/reiser4, and viro, hch etc didn't have any objections that I recall
@davej	so its a maybe.
@rml	Hm, good.
@rml	fscked asked: do you think the kind of improvements made within the kernel in this last development cycle will add too much complexity as to scare newbie kernel hackers off? Or on the other hand the new APIs make it simpler and more accessible?
@rml	this is a good question
@rml	some stuff got _really_ complicated.  I hope it does not scare off newbies
@rml	Linux has always been so simple in design, it was astonishing.
@davej	this was brought up by Larry McVoy at OLS/Kernel Summit.  These days things are a *lot* more complex than they were when a lot of us were starting out.
@rml	yep, the barrier to entry is a lot higher
@rml	to specifically answer the question, it is higher - no doubt. but hopefully not enough to scare off newbies
@cdub_	at the same time, other stuff had been formalized and consildated into nicer API's
@davej	ShawnWerk: development -> feature freeze -> code freeze -> stable.
@davej	ShawnWerk: between feature & code freeze APIs could change if it was absolutely needed
@sarnold	davej: does linus have plans for a code freeze soon? are they realistic?
@rml	no one should think kernel development/os design is easy, but the complexity should not be needlessly high
@davej	sarnold: I don't recall hearing him set a date.
@rml	I think good programmers with a sane understanding of OS theory can still jump in with zero issue
@rml	davej: I think he said January 1st on that cruise he took :)
@davej	rml: *shrug* I didn't get to go 8-)
@rml	davej: me neither :> but I read he said Jan 1 for freeze and "summer of 2003" for release
@rml	which I think are doable
@sarnold	would a code freeze work in the linux development model?
@rml	it depends on much he sticks to his guns
@rml	sarnold: we have always had a code freeze at the end of the development series
@davej	sarnold: depends. Theres  "code freeze" and "torvalds code freeze"
@rml	for varying degrees of freezing, of course :)
@davej	which is more a slush than a freeze 8)
@sarnold	hehe :) My main concern, is if developers are generally working in their own trees, would they notice problems in a "frozen" kernel?
@rml	Linus has said he is "very content" with 2.5, so if no evil corner cases or regressions come out, I think Linus will be able to say "no" OK
@andre	rml: well to be fair Viro is a nice guy who does not take crap
@davej	right now the biggest thing holding back 2.6, is a lot of drivers are still badly broken.
* sarnold eyes gregkh
@cdub_	heh
@rml	andre: nothing I said was meant to be negative toward viro.  he is an amazing programmer with very strong taste.  I just said he was very hard to get patches by
@rml	which is a good thing, really
@sarnold	davej: would driver code be exempt from any code freezes?
@andre	in order for me to have gotten back into the maintainer list I had to submit code to Viro and that was the test to see if I could make the high water mark again
@davej	sarnold: some of it is so badly broken, that it would have to be.
@gregkh	sarnold: the usb drivers aren't broken, it's scsi and block layer stuff.
@andre	rml: and for a darn good reason, if we all had his intolerance for cruft, well ...
@davej	and wierd shit like hamradio junk and the like.
@rml	andre: indeed.
@andre	scsi need a true recore also
@cdub_	< will-h:#qc> What are the changes with md and LVM in 2.5? Does anyone want to summarise?
@cdub_	i think this question got lost.  gregkh care to mention dm changes?
@andre	it need to try and model the effective state machines fuzzy of the bus-phase operations
@gregkh	dm has replaced the lvm code.
@gregkh	lvm2 and evms will mainly be userspace code that uses the dm code in the kernel.
@andre	this would push all the wierdness back into the HBA drivers and expose finally who and how the ugliness of the SCSI T10 groups "ends justify the means" model of hardware design
@gregkh	will-h: does that help?
@Bacchus	davej: As for the weired hamradio junk - I protest :)  I've taken over maintenance but repairing the damage of several years of non-maintenance takes a while ...
@sarnold	andre: i've always wondered why SCSI and IDE are handled in different subsystems.. don't they do the same things?
@davej	Bacchus: you're a brave man 8)
@andre	do yes, how they do it is far stranger than you ever want to know
@sarnold	andre: agreed :)
@sarnold	on the subject of code freezes, stability, etc; is 2.5 ready for newbies to test 2.5 out for themselves? what would be the best way to test or try 2.5 for new users?
@rml	I think 2.5 is stable enough for casual testers, yes
@andre	one requirs lots of hand holding (ATA/ATAPI) and the other requires lots of frustration (SCSI/et al) to get it into proper phases.
@davej	ugh, modules
@gregkh	2.5 works good enough for me to use it on my desktop all day long.
@rml	oh, yah, modules may unfortunately be an issue
@davej	I spent most of today chasing module related bugs in agp. though to be fair to rusty,they were all my fault.
@rml	but if you can survive that (or just statically compile the kernel like real hackers <g>) then you are fine
@davej	the new modules stuff does some extra things that the old stuff didnt do (like freeing __init sections)
@rml	ShawnWerk asked: but module changes came so late
@rml	yah, they did.  perhaps too late
@davej	indeed. very late 8)
@gregkh	davej: it does?  I didn't know that, nice.
@davej	gregkh: I found out the hard way 8)
* andre has to goto RedCross as he has funky blood that is used on newborns in emergency, and he has gotten a call, bbl
@rml	but I think any issues in the new module code will be worked out soon
@davej	I've been meaning to add poisoning to the freeing of __init for a while
@rml	well that is random, andre :)
@sarnold	andre: thanks for your time :) have a good weekend
@sarnold	zadeh and mave are asking about the intel C compiler and gcc 3.2..
@rml	Mave: will gcc 3.2 "officailly" supported soon ?
@rml	I think it is already
@davej	I think if people start reporting bugs and they used the Intel compiler, they'll liekyl be asked to use gcc to try and repeat the bug.
@davej	ugh, knotted fingers... s/liekyl/likely/
@rml	only old farts like akpm who refuse to leave egcs are not using gcc 2.96 or newer :)
@rml	I am having no issues with gcc 3.2
@davej	radical: before freeing the memory, memset it with illegal instructions. If we then get an oops, that pattern shows up.
@Bacchus	rml: the compiler itself has gotten continuously slower since egcs 1.1 which is why I alsos stick to it.
@sarnold	davej: are there any concerns with the linux kernel being so closely tied to gcc?
@davej	sarnold: not from me 8)
@rml	Bacchus: yah it is awful slow, now. that is why akpm does not switch
@davej	radical: it would oops when something else tried to jump to that memory.
@davej	radical: right now we get away with jumping to __init sections after freeing mostly, as that ram hasn't been allocated so it still contains the old code.
@zwane	davej: there are a lot of device id tables marked as __init ;)
@sarnold	does anyone have plans to update the kernel documentation during any code freezes that may or may not happen on jan 1? :)
@davej	zwane: sounds like a cue for Greg and hotplug...
@davej	RaiST: TuX has been on Ingo's back burner whilst he got the threading stuff done afaik.
@cdub_	< radical:#qc> cdub_: im working on the networking doc of lkdp(linux kernel doc-n project) and using 2.4.18/19 for it. has the networking code undergone major changes in 2.5.x?
@davej	RaiST: rumour has it that he had intended to try and push it for 2.5, but the feature freeze happened first...
@sarnold	<ShawnWerk> davej: is the new threading in 2.5 or in a secondary tree?
@cdub_	well, there is some new stuff in there.  like the ipsec pieces.  also the stackable routes work
@davej	ShawnWerk: its all in mainline. you need newer glibc/nptl to really take advantage of it though
@rml	ShawnWerk: all the new threading code is in 2.5 now
@rml	and the glibc bits as NPTL is in glibc 2.3
@rml	although not compiled by default
@rml	radical asked: what exactly is the O(1) scheduler?
@davej	some of the improvements made also benefit the existing userspace threading stuff we have too.
@rml	radical: its a process scheduler, which means it has the job of deciding what process to run next
@davej	Ingo wrote a neat summary of those bits for http://www.codemonkey.org.uk/post-halloween-2.5.txt
@rml	radical: the "O(1)" part means it operates in constant-time, so it takes the same amount of time to decide which process to run regardless of how many processes there are (figure out that!)
@cdub_	< radical:#qc> cdub_: but no design/other major changes? normal code cleanups/optimisations.. etc?
@cdub_	radical: that's what i recall from the top of my head.  some say networking is a bit ahead of other parts of kernel ;-)
@rml	radical: it does this by implementing a bitmap of priorities, so it knows what the highest priority runnable process is simply by looking at the first set bit in the bitmap
@davej	cdub: NAPI ?
@cdub_	davej: well, it's in 2.4 now as well isn't it?
@rml	radical: so it does not need to loop over all processes to find the most worthy
@davej	cdub: I lost track. it was in , then it was pulled, then someone said it went back..
@rml	radical: that is the core, but there are a lot of other algorithms, and they are all O(1) too... a lot to discuss
@cdub_	heh, ok.
@cdub_	radical: it's possible you'd want to mark NAPI as another update.
@davej	ShawnWerk: the agp mess in mainline was my fault.. Should be ok when Linus does a pull next time.
@sarnold	NPTL thread support is to help support POSIX threads; is the linux kernel converging towards full support of POSIX or Single Unix Specification, or any other set of specifications?
@davej	ShawnWerk: shouldnt have caused lockups though, thats likely a DRM specific problem rather than agpgart
@cdub_	i think ebtables went in as well
@sarnold	ebtables?
@cdub_	netfilter for bridging
@rml	sarnold: only where we think the standard is sane
@rml	sarnold: NPTL is more about performance than compliance, although it does tighten up compliance in a few areas
@sarnold	radical: well, driver testing may be better done on vmware; but attaching debuggers to uml is easier.
@sarnold	unless there are other 'technology' issues to discuss, i think i'd like to move to more philisophical questions at this point...
@davej	philosophical ? Should I fetch some beer ?
@cdub_	if a kernel oopses in a dusty corner of datacenter where know you can see it, did it really oops?
@sarnold	davej mentioned earlier that some of the IPSec code is taken from the KAME projects..
@sarnold	how much sharing is there between Linux and the BSD camps, and should there be more of it?
@davej	I personally take a peek at what they're up to every few months in the areas that interest me.
@davej	sometimes they're ahead, sometimes we're ahead, but it's always interesting.
@davej	The AGP reworking I've done in 2.5 is similar to what freebsd has had for many moons for eg.
@davej	ie, per chipset drivers instead of one monolithic lump
@rml	I talked to the FreeBSD guys about their preemptive kernel (which is or was supposed to be a feature in 5.0)
@Bacchus	In general even when license incompatibilities or other issues prevent code sharing we and the BSD people are talking to each other.
@rml	I follow their scheduler work, although they are deviating a bit from things I agree with or things the community will embrace (e.g. KSE which are the classic "scheduler activations")
@rml	but I follow the BSD stuff... I think we learned a little from their VM
@cdub_	yes, i think its useful.  i like to follow trustedbsd
@sarnold	how about Plan9? EROS? Windows?
@davej	I've not really spent much time looking at the other BSD's though, just FreeBSD.
@davej	sarnold: -ENOTIME 8)
@rml	I have not really looked at Plan9 or EROS.  Plan9 has some interesting design choices
@rml	I have read some tests on the design of Windows
@rml	even the NT kernel leaves a lot to be desired, to be honest
@cdub_	< c0nan:#qc> hmm any plans on role based access control mechanisms?
@rml	they do some gross things to prevent process starvation and priority inversion
@sarnold	rml: linux's spinlocks and semaphores seem designed to be simple.. does linux suffer horrible problems as a result, or is the simplicity also a performance win?
@cdub_	c0nan: yes.  the lsm project is working on a generica access control framework.
@rml	sarnold: especially for spinlocks, it is very much so a performance win
@rml	sarnold: I do not like bloated locking (i.e. Solaris-style locks) at all
@cdub_	c0nan: it can be used to to role based access control
* cdub_ hands rml some turnstyles
@rml	cdub: that is the best feature of their locks :)
@cdub_	;-)
@cdub_	< c0nan:#qc> What is the roadmap on that generic access control mech.?
@sarnold	last weekend, alan cox gave a presentation stressing the importance of code size and cache issues; are there any efforts to try to optimize the layout of kernel structures to fit within cache lines? any systematic testing of different compiler optimization flags?
@cdub_	the primary focus is continuing the merge with mainline.
@cdub_	this includes consolidation and cleanups.  then pushing in some more modules.
@rml	sarnold: I think a lot, yah. maybe too much use of cache-line-aligning
@rml	we need to look at cache footprint in 2.5, because it certainly got bigger
@cdub_	sarnold: i think that you have to be careful of too much micro optimizations.  may not help on all arch's, etc.
@sarnold	lets pause for a bit to give our poor translators some time to catch up..
@davej	rml: that's all those preempt_enable()
@davej	's
* davej ducks
@cdub_	sarnold: but dcache locking changes is nice example of algorithmic change to improve cache trashing.
* rml throws an old sparcstation at davej
@sarnold	(i'm afraid our translators may never catch up... we've been going at it pretty quickly.. :)
@davej	we need preemptable translators.
@sarnold	davej: heh, in dutch, akpm just took off...
@davej	heh
@davej	a man of many talents//
@sarnold	:)
@sarnold	something mulix asked, and I'd love to know: what books do you recommend reading? :)
@rml	for programming or fun? :)
@cdub_	heh
@sarnold	rml, well, mulix asked specically about technical books, but both might be fun :)
@davej	I like the mindshare books.
@rml	for fun, I know mochel likes those raunchy romance books
@davej	rofl
@cdub_	lol
@rml	I think "UNIX Systems for Modern Architectures" by Curt Schimmel is an excellent book
@sarnold	(even though curt works for SGI? :)
@rml	sure, its a really good book
@davej	Despite the fact its a microsoft book,I've been reading "Writing solid code" again recently. It's another favorite of mine, and it's surprisingly well written.
@Bacchus	Curt describes also other architectures like i386.
@cdub_	mulix: anything from Stevens is always full of good stuff (albeit, not necessarily directly about kernel programming).
@rml	"UNIX Internals: The New Frontiers" by Vahalia is excellent, too
@davej	The ia64 kernel book is another good one I've started reading, but not yet finished.
@rml	talks about things like reverse mapping VMs, kernel preemption, SMP optimizations, etc... its a collection of "advanced" UNIX stuff
@sarnold	<RaiST> For a newbie, is it good for starting to work with latest kernel or starting with historical ones?
@davej	I started with what was current devel snapshot, and never turned back 8)
@cdub_	i think working on current (either 2.4 or 2.5) is good.
@rml	be determined and _read_ and _write_ code
@Bacchus	I ususlly recommend kernels that are already well covered by available literature for learning.
@davej	whilst a lot of the kernel books out there concentrate on older branches, its the concepts that you really have to understand more thanthe code.
@davej	understanding the code also helps too though sometimes 8)
@sarnold	davej: do you think bach's 1984 (or 1986?) book is still a good introduction? :)
@davej	title ?
@rml	sarnold: I am reading that book now, actually
@akpm	rml is right.  You can read code all day and not learn a thing.  It's when you actually need to *change* it that you start to learn.  Because you *have* to.
* davej is hopeless with names
@sarnold	davej: ... Design of the UNix Operating System, I think..
@davej	sarnold: not read it.
@rml	davej: the old SvR2 book
@davej	there are lots of ye olde manuals I've never found time to read. Perhaps I should dedicate a reading day or two each month 8)
@sarnold	davej: good idea! ;)
@sarnold	we've now gone on for about two hours... so I'm inclined to ask one more question and then open the floor for an outright free-for-all for those who still have the time for it ;)
@sarnold	my last question: Is working with Linux still fun? With the newer huge corporate surpport for working on linux, is it fun as a job as well as fun as a hobby?
@gregkh	it's both my job and my hobby, and if it wasn't my job it would still be my hobby.
@rml	its still fun.  I think all of us here who get paid to do it realize how lucky we are
@davej	I always said I'd do something else the day it stopped being fun. Getting paid to do it full time was just a bonus.
@sarnold	one last comment before I unmoderate #linux..
@sarnold	I'd like to plug the kernelnewbies project, as a good way to help people learn how to program the linux kernel
@sarnold	check out http://www.kernelnewbies.org for more information :)
@sarnold	and with that, i'd like to thank akpm, andre, rml, davej, mochel, gregkh, cdub, bacchus, for taking time out of their days to talk with us :)
@sarnold	thanks also to our translators :)
@davej	thanks for inviting me 8)
@rml	thanks much :>
c0nan	thank you all for this beautiful session! :)
mulix	clap clap clap clap clap lcap clap clap clap clap clap clap clap
mulix	clap clap clap clap clap lcap clap clap clap clap clap clap clap
mulix	clap clap clap clap clap lcap clap clap clap clap clap clap clap
* c0nan claps too
@sarnold	(ah, yes, zwane too; someone kick his ISP for being so lousy though :)
fernand0	plas plas plas plas plas plas plas plas plas plas plas
fernand0	plas plas plas plas plas plas plas plas plas plas plas
fernand0	plas plas plas plas plas plas plas plas plas plas plas
fernand0	plas plas plas plas plas plas plas plas plas plas plas
fscked	this is why kernel development is so appealing, not only cuz it's technically challenging but cuz it has great team of core developers who can share a laugh and actually TALK to people
fscked	thanks guys
radical	clap clap clap clap clap lcap clap clap clap clap clap clap clap
radical	clap clap clap clap clap lcap clap clap clap clap clap clap clap
radical	clap clap clap clap clap lcap clap clap clap clap clap clap clap
radical	clap clap clap clap clap lcap clap clap clap clap clap clap clap
c0nan	cdub do you have any specific dat or anything on the horizon for the axx control mechanism that you were talking about?
c0nan	like one year two months or anything?
cdub_	c0nan: LSM is partway merged.  the rest of the merge is up to linus and davem primarily (as it's mostly network related)
MJesus	clap clap clap clap clap clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
@gregkh	thanks for inviting me too.
c0nan	ok I c
c0nan	thx :)
mj	plasplasplas plas plas plas
mj	plasplasplas plas plas plas
mj	plasplasplas plas plas plas
cdub_	c0nan: you can always get the out of tree version from lsm.bkbits.net (or patches from lsm.immunix.org)
mj	plasplasplas plas plas plas
mj	plasplasplas plas plas plas
MJesus	clap clap clap clap clap clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
* cdub_ remembers to update website
@rml	I would like to encourage everyone to test 2.5, and report results
* Arador claps claps those kernel hackers
@rml	especially SMP users who can use the preemptive kernel to do "atomicity debugging"
@rml	great way to track down SMP bugs
RaiST	last question:
RaiST	this one talked very much in kml.
RaiST	but what do you think of using bitkeeper:)
will-h	heh, that old question again
fscked	RaiST: oh dear, Alan just got killfiled cuz of that
fscked	haha
RaiST	:)
* c0nan spreads holywater on RaiST
@gregkh	RaiST: bk works wonderfully for me, I don't care who else uses it.
mulix	c0nan, ITYM penguin pee :-)
@rml	my take: to each there own. I don't use it, but if those who do use it like it, then great.  a more productive Linus is a better Linus.  the open source holy wars are supposed
mulix	oh, one more question, what do you think about unexporting sys_call_table?
@davej	I'm starting to use it more, but most of the stuff I send Linus is still normal GNU patches.
@rml	s/supposed/stupid/
fscked	mulix: did you get 100% around that for your syscalltrack project? Is it still fully functional?
fernand0	http://blo.gs/
cdub_	mulix: it was the right thing to do.  updating syscall table is not a safe operation anyway
fernand0	ops
Arador	rml: what's that "atomicity debbuging"? check for bad locking,  "process exited with preempt count X" and such?
mulix	cdub_, it's safe for *some* archs under *some* conditions
mulix	fscked, I'm still thinking what to do about that one
fscked	mulix: gosh, did it completely break?
@rml	Arador: its a much better form of the "process exited..." checks.  it checks if code sleeps while holding a spin lock, and a bunch of similar things
mulix	fscked, my current plan is to write and propose a real system call hijacking mechanism and propose that for inclusion
cdub_	heh, ok.  it would need to go one way or the other.  expose a proper api, or unexport it (imho).
@rml	Arador: there is a debug setting for it in the "debug" category
mulix	and if that doesn't work (likely), to just require users to patch their kernel.
fscked	mulix: thumbs up for that, sounds like the right way to go, will you push that forward?
cdub_	and given gpl worries, etc, i think unexporting was the right thing to do
mulix	fscked, I will, once I've written it :-_
Arador	rml: ok, i use 2.5 every day (and it doesn't oops ;), from now i'll enable it (p3 2x800);)
fscked	mulix: i'd love to help, i find your project really nice, but I kinda lack the technical background to be of enough help
mulix	I don't supopse it will go in, but it will give me what I need in a technically acceptible way.
mulix	fscked, thanks for the kind words. Bug reports and your experiences (good/negative) with it are always appreciated.
@rml	Arador: great.  you will get messages like "schedule() called while atomic" and an associated back trace... send those to lkml
@rml	also, all testers: turn on CONFIG_KALLSYMS - it is a great asset
mulix	rml, agreed... why isn't it on by default?
fscked	mulix: if I find the time, which is sadly unlikely as of right now, I will try my best to pick up some of the project concepts and actually give a hand, it does interest me a lot, no doubt about it
Arador	rml: i'll do, some interesting option under debug that could help?
@rml	mulix: bloats the kernel.. its not very elegant to put a symbol table in the kernel
@rml	Arador: all of them :)
@rml	Arador: slab debugging (due to recent changes) will slow things down a bit.  otherwise the rest will not hurt much
mulix	rml, what do you plan to work on next?
@rml	mulix: not sure, see what interests me...
mulix	rml, how about ... a theorem solver in kernel space?
@rml	don't think so :)
RaiST	hýmm if i say some unrelated funny thing is it will be problem? i think you the kern. hackers are ring carriers, and others(you know them) are the sauron's army. :P
fernand0	lag?
RaiST	uhhm everyone escaped. sorry :P
fernand0	hehe
fernand0	Well.
fernand0	So far, so good.
mulix	lots of people still here... everyone idling.
* mulix compiling 2.5
fernand0	I think is time to say thanks again.
fernand0	hanks to all the speakers, and thanks
fernand0	to the people who came here.
fernand0	Also thanks to the people that helped us to
fernand0	succeed: webmaster, loggers, translators; that is,  people who helped in
fernand0	one or another way.
fernand0	All the work developed during these days will remain in our web:
fernand0	http://umeet.uninet.edu/
fernand0	(http://umeet.uninet.edu/umeet2002/english/des.eng.html).
mulix	when is next year's umeet going to be?
mulix	and where will the CFP be published?
fernand0	There is some work that starts just now:
@sarnold	mulix: december sometime :)
fernand0	obviously, to start to prepare the
fernand0	next umeet, but also to fix things with this that today concludes:
cdub_	great work to all those that put on this year's umeet!  well done
fernand0	if you
fernand0	feel that you could help with the logs (fixing translations, cleaning them
fernand0	in some way,...) let us know.
mulix	sarnold, publish the CFP on kernelnewbies or soemthing, so that I'll see it :-)
@rml	yes, good job everyone.  thank you for allowing me to participate
fernand0	We will be more than happy to have all the
fernand0	talks in a more readable form.
mulix	great job this year, every lecture I could listen to was great.
fernand0	i think sarnold and jmgv have something to say....
@sarnold	mulix: we did slashdot, linux weekly news, and others.. :) iirc, rik posted a mail to kernelnewbies mail list too :)
mulix	sarnold, in other words, my fault. Oh well :-)
fernand0	if you register at the conference's site
@sarnold	mulix: yeah; stuff gets lost in the noise :)
@jmgv	Buenos dias/tardes/noches a todos
fernand0	next year you will get an email about next umeet ;)
Mave	uhm i'd like to be informed umeeting before. untill debianplanet.org article i didn't notice it :/
@sarnold	(uninet also presents an INFOSEC conference probably in april as well)
fernand0	we only will use that list for umeet or uninet related conferences
viZard	hooray!
@jmgv	bueno señores me gustaria decir unas palabras de agradecimiento
@jmgv	a todos los participantes tanto conferenciantes como asistentes a las innumerables conferencias que este año se han realizado en umeet2002
@jmgv	es un honor y un privilegio para todos los organizadores de este evento
viZard	:-)
@jmgv	el ver como otra vez como todos los componentes de la comunidad de linux
@jmgv	se vuelcan una vez mas para impulsar todo el mundo relacionado con linux/unix
@jmgv	sin mas me gustaria reiterar en nombre de los organizadores de este evento vuestra participacion y vuestro comportamiento ejemplar
@jmgv	en todas y cada unas de las charlas que se han realizado este año
@jmgv	gracias a todos por habernos dado las fuerzas y la ilusion necesaria a todos los que creemos en este proyecto
@jmgv	para que el año que vienes nos forzemos mas si cabe, para mejorar todavia más este tipo de encuentros
@jmgv	Gracias a todos.
@viZard	plas plas plas plas pls plas plas plas
@viZard	plas plas plas plas pls plas plas plas
@viZard	plas plas plas plas pls plas plas plas
@viZard	plas plas plas plas pls plas plas plas
@viZard	hooray!
MJesus	clap clap clap clap clap clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
fernand0	plas plas plas plas pls plas plas plas
fernand0	plas plas plas plas pls plas plas plas
fernand0	plas plas plas plas pls plas plas plas
MJesus	clap clap clap clap clap clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
@viZard	hooray! de nuevo !
MJesus	bravo sarnold !!!!
MJesus	bravo sarnold !!!!
MJesus	bravo sarnold !!!!
@sarnold	thanks again everyone :) I hope to see you all at INFOSEC or the next UMeet :)
MJesus	bravo sarnold !!!!
@viZard	ahhh, un merecido descanso para todos. lo ordeno
RaiST	thankx for everyone
@jmgv	let's listen to sarnold please!
@sarnold	jmgv: nah, i'm done, really :)
MJesus	clap clap clap clap clap clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
Arador	davej: you there?
MJesus	thank, all you...
@jmgv	:-)
@jmgv	okey
@jmgv	we can go to upstairs in which all of you can find canpes and some drinks :-)
* sarnold runs upstairs
@jmgv	:-))
@jmgv	i go on holiday really happy
MJesus	andre morton, dave jones, bacchus,... all you and specially thanks riel, .. who is absent with a headeache, but hi is always presnet,, and hi war worked hard, for this umeet !
fernand0	hehe
fernand0	and some christmas sweets
* Bacchus bows to Maria :)
MJesus	Bacchus, thank also you !!
fernand0	well guys
fernand0	have a nice week-end
MJesus	this was a hard umeet... every day 3 conferences! and two round tables !
@sarnold	MJesus: yeah, i think i'll want to keep infosec to one week :)
fernand0	hehe
Arador	and live translations! :)
MJesus	garoeda was traslate all to Ducht . Thanks garoeda
fernand0	then don't let mjesus search for speakers
cha0z	;P
MJesus	and some peoples as vizard, arador, jacobo, ricardo, raul, chaos, horacio, raul .... will traslate to Spanish-Englishh
Arador	runlevel0, horacio....
runlevel0	;)
MJesus	yes... with your we made every time, as difficult it could be !
MJesus	ismak was been the man for mass media. Thanks ismak !
fernand0	see you
fernand0	have nice days
fernand0	and good entry in the new year
MJesus	and jmgv, try the best conferencist, as Alan Cox, and most of yours !
runlevel0	same 2 you ;)
MJesus	Fernand0, was the head all this !
fernand0	don't lie
MJesus	without him nobody work in UMeet
MJesus	the spanish traslator, still are busy ..
MJesus	this round table, have more fast than 5 traslator and a pivot
MJesus	tipyst as fast as possible
MJesus	----------- THANK ALL YOU! -----------

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net!