*** [29-Jun:13:26] Joined #kernelsummit: dd2 (dima@blitzkrieg.blackened.com)
*** Users on #kernelsummit: dd2 eivind awfulhak tmm bright cmc bsdimp jlemon rwatson uplift BigFork @wca @Keltia @phk 
*** Channel #kernelsummit created on Thu Jun 28 22:44:36 2001 MST
[29-Jun:13:26 awfulhak] Warner stands down
[29-Jun:13:26 awfulhak] John baldwin has a question....
[29-Jun:13:27 bright] *** Value of LOG set to ON
[29-Jun:13:27 awfulhak] should devd handle all device events rather than just dynamic ones
[29-Jun:13:27 awfulhak] warner agrees
[29-Jun:13:27 awfulhak] rwatson agrees
[29-Jun:13:27 rwatson] note: remember not to talk at once so they can sign it.
[29-Jun:13:27 BigFork] like buildtin ether
[29-Jun:13:27 BigFork] not just usb ether, etc.
[29-Jun:13:28] * bright raises his hand
[29-Jun:13:28 awfulhak] Should kqueue generate events and pass to devd ?
[29-Jun:13:28 bright] ethernet devices don't have device nodes (yet)
[29-Jun:13:28 awfulhak] jlemon isn't clear if kevents are that compatible
[29-Jun:13:28 awfulhak] Not on a generic level anyway....
[29-Jun:13:29 BigFork] bright: yet  :), but the discussion is that this may become a more general kernel event daemon than a devd perhaps
[29-Jun:13:29 awfulhak] rwatson says that /dev events are different from more general events
[29-Jun:13:29 awfulhak] But may be more generic....
[29-Jun:13:30 rwatson] that is to say, the /dev file system events are distinct from the hardware events
[29-Jun:13:31 rwatson]  /dev file system events reflect the creation of device nodes to reflect hardware devices/etc, vs. the device event itself, which might be notified by /dev/dev
[29-Jun:13:31 awfulhak] We need a devinfo replacement (says warner / jhb)
[29-Jun:13:31 BigFork] perhpas, they are similar tasks
[29-Jun:13:31 jlemon] brighty: yes they do, with my patches.
[29-Jun:13:31] * BigFork pat pat jlemon
[29-Jun:13:32 bright] (i was going to nudge you about that)
[29-Jun:13:32 bright] jlemon: i've been envisioning a way to register kqueue intrest in a filesystem
[29-Jun:13:32 awfulhak] The devinfo replacement may need to handle pseudo device events too
[29-Jun:13:33 awfulhak] jhb argues that pseudos appear due to events from above, not from below
[29-Jun:13:33 bright] that's one way of doing it, but since this is a device, we might as well have a special device node that devd opens and all device events can be sent to that device's kqueue
*** [29-Jun:13:33] Joined #kernelsummit: groggy (~grog@tserver.conference.usenix.org)
*** [29-Jun:13:33] Joined #kernelsummit: DrZiplok (msmith@ziplok.dis.org)
*** [29-Jun:13:33] Joined #kernelsummit: dwhite- (dwhite@cust-P5-R7-64.POOL.ESR.SJO.wwc.com)
[29-Jun:13:33 DrZiplok] Fnord
[29-Jun:13:33] * groggy looks at DrZiplok.
[29-Jun:13:33 jlemon] bright: yes, but remember that kqueue doesn't pass back a whole lot of information.
[29-Jun:13:34] * DrZiplok looks like DrZiplok
[29-Jun:13:34 rwatson] it seems like there might be some benefit to reporting newbus topology/events via /dev/dev also
[29-Jun:13:34 awfulhak] Maybe psuedo event handling is more useful when there's a hierarchy involved
[29-Jun:13:34 jlemon] so you have to do a name -> dev_t somewhere.
[29-Jun:13:34 rwatson] Also: should pseudo-device events be reported and managed?
[29-Jun:13:34 bsdimp] dev/dev would have a kqueue that tells devd that intersting events can be read/ioctl'd etc.
[29-Jun:13:34 bright] jlemon: the user pointer can specify the location to dump events, or the kevent can just signal that it's time to perform an ioctl() on the master device node
[29-Jun:13:34 bsdimp] click click click
[29-Jun:13:34 BigFork] for those at usenix, we are in the new hampshire room
[29-Jun:13:34 BigFork] 5th floor
[29-Jun:13:34 jlemon] bright: true.
[29-Jun:13:34 bright] bsdimp: heh, is there an echo in here? :)
[29-Jun:13:34] * groggy thinks DrZiplok looks very different.
[29-Jun:13:34 eivind] jlemon/bright: might be possible that a generic userland filesystem stacking interface would be a place to put this.   I worry a bit about the perfomance, though.
[29-Jun:13:35] * groggy doesn't see any bright.
[29-Jun:13:35 bright] eivind: the generic stacking interface wouldn't be useful for devd, but useful for tools like cvsup
[29-Jun:13:35 bsdimp] Can we have an approval mechanism in devd? (jlemon)
[29-Jun:13:36 eivind] bright: could be done for devd, too, I think.  would need some thinking, though.
[29-Jun:13:36 awfulhak] Should devices appear with 0 permissions and be retrospectively fixed by devd (jlemon)
[29-Jun:13:36 awfulhak] rwatson: No - sometimes they're necessary immediately
[29-Jun:13:36 bright] thinking bad, hurts head
[29-Jun:13:36 BigFork] need to handle case where devd is not present (bsdim)
[29-Jun:13:37 awfulhak] jlemon asks should we feed policies into the kenrel
[29-Jun:13:37 bright] i think that giving devFS a umask wouldn't be a bad idea
*** [29-Jun:13:37] Left #kernelsummit: groggy (~grog@tserver.conference.usenix.org)
[29-Jun:13:37 bright] (not devd)
[29-Jun:13:37 eivind] jlemon: preferably not - having it in userland allow more freedom for hacking
[29-Jun:13:38 eivind] jlemon: or at least not non-overridable policy
[29-Jun:13:38 awfulhak] paul suggests that devd's death should be handled (BigFork is mentioned too)
[29-Jun:13:38 bsdimp] jlemon: We could have a /dev kernel loadable module that does policy rather than put it in devd
[29-Jun:13:38 jlemon] eivind: I was thinking along the lines that the kernel checks the policy database in the kernel to determine what to do on device appearance.
[29-Jun:13:39 jlemon] the policy database is loaded by the user,  
[29-Jun:13:39 eivind] it makes it hard to do dynamic adjustments in policy depending on external factors
*** [29-Jun:13:39] Joined #kernelsummit: tmm2 (lziroe@pD900C6B5.dip.t-dialin.net)
[29-Jun:13:39 awfulhak] rwatson says that /dev management could be different from devd - devd manages policies, but the kenrel does things
[29-Jun:13:40 eivind] you'd need to do a demon that constantly polled all external input that could make it change its policy, and pushed the results into the kernel, instead of just doing checks when it needed it
*** [29-Jun:13:40] Joined #kernelsummit: Evil-Bill (wpaul@brak.osd.bsdi.com)
[29-Jun:13:41 eivind] WRT devd death: if this turns out to be drastic, it may be possible to use descriptor passing to allow seamless transition from one devd to another
*** [29-Jun:13:41] Joined #kernelsummit: nephrozym (fakeuser@vilnya.demon.co.uk)
[29-Jun:13:41 bsdimp] WE could put devd in /etc/ttys to solve that probelm.
[29-Jun:13:42 eivind] that would just force a restart, not handle the death per se - but blocking in the kernel until devd is available may be an option once the system is up
[29-Jun:13:44 rwatson] sounds like we have concensus that devd doesn't manage /dev
[29-Jun:13:44 awfulhak] people agree that devfs management should be driven by policies pushed into the kenrel
[29-Jun:13:44 BigFork] it just handles device events
[29-Jun:13:44 BigFork] a generalized unification of pccard + usbd
[29-Jun:13:44 awfulhak] BigFork: yes
[29-Jun:13:45 awfulhak] yes
[29-Jun:13:45 eivind] awfulhak: nobody can think of a realistic case where device creation policy is dependent on external events?  (I can't think of one, so if nobody else can either, it should probably be ignored)
[29-Jun:13:46 awfulhak] eivind: the big deal is that pushing such things into userland creates race conditions
[29-Jun:13:46 eivind] awfulhak: only during startup, if you let the kernel block creation until getting a reply from devd
[29-Jun:13:47 phk] I wonder if it's too late for me to chime in here ?
[29-Jun:13:47 eivind] awfulhak: you'd need a different solution during startup, involving at least some static static policies to get filesystem mounted, I think
[29-Jun:13:47 bsdimp] phk: it is never too late :-)
[29-Jun:13:48 awfulhak] People are now talking about event association
[29-Jun:13:48] * eivind would have liked softweyr, julian, or archie here to give opionions on the advanced embedded market
[29-Jun:13:48 awfulhak] rwatson says that should be up to devd
[29-Jun:13:48 phk] basically, I wanted to create an dynamic set of "classes" or "types" of devices, "disks" for instance, and have make_dev() refer to such a thing instead of giving m+o+g triplets
[29-Jun:13:48 BigFork] note that we can revisit this tomorrow as well
*** [29-Jun:13:48] Joined #kernelsummit: aDe (ident@hub.lovett.com)
[29-Jun:13:49] * eivind won't be here tomorrow - weeding
[29-Jun:13:49 BigFork] (just a side note)
[29-Jun:13:49 eivind] wedding, even
[29-Jun:13:49 BigFork] eivind: oops
[29-Jun:13:49 BigFork] :)
[29-Jun:13:49 phk] that way we could set some sensible defaults, which could be overidden on compiletime and set by sysctl at runtime.
[29-Jun:13:49 BigFork] phk: classes of devices would be a good thing
[29-Jun:13:49 bsdimp] We're mostly talking informally now.
[29-Jun:13:49 phk] I agree about the "ask devd at create time" is too race-starvation-timeout prone.
[29-Jun:13:50 phk] BigFork: I have part of this in a tree already, but I need to unpack the machine before I can get to it, it's already packed for moving.
[29-Jun:13:50 rwatson] phk: yeah, we ran into this problem with coda -- don't let the daemon generate upcalls for itself
[29-Jun:13:50 eivind] phk: I think we should leave the design open for implementing optional "ask devd at create time", but making it mandatory is probably too much
[29-Jun:13:51 phk] the hard time is that if people clone a device, do we want to stall them while we wait for devd, and what if devd clones a device (by nature of some "start script" it runs ?)
[29-Jun:13:51 bright] devices are hard, let's go shopping.
[29-Jun:13:51 phk] I agree with the "lets push a policy into the kernel", I'm not sure of the format or structure of that policy.
[29-Jun:13:51 phk] but one policy could be "ask devd" of course.
[29-Jun:13:52] * BigFork kicks bright
[29-Jun:13:52 bright] will devd have a webUI for configuration?
[29-Jun:13:52 phk] I used to be in favour of a mandatory devd, but I'm not anymore (think jails...)
*** [29-Jun:13:52] bright kicked from #kernelsummit by phk (D00D!)
*** [29-Jun:13:52] Joined #kernelsummit: bright (bright@sneakerz.org)
*** [29-Jun:13:53] Mode on #kernelsummit by phk: +ooo awfulhak bsdimp BigFork
*** [29-Jun:13:53] Mode on #kernelsummit by phk: +ooo DrZiplok eivind Evil-Bill
*** [29-Jun:13:53] Mode on #kernelsummit by phk: +ooo jlemon nephrozym rwatson
*** [29-Jun:13:53] Mode on #kernelsummit by phk: +ooo dwhite- cmc uplift
[29-Jun:13:53 eivind] phk: when thinking jails: they mean we need the possibility of a separate policy per mount - but probably want to be able to share those policies for efficiency when mounting large amount of dev spaces (ie, many jails)
[29-Jun:13:54 phk] eivind: Right, I'm slowly starting to hate jails as you can imagine :-)
[29-Jun:13:54 phk] eivind: feeling a bit like Oppenheimer here...
[29-Jun:13:54 bsdimp] "we have become death"
[29-Jun:13:55 eivind] phk: with null mounts and union mounts, I see a lot of use for jails in "normal" configurations
[29-Jun:13:56 phk] eivind: yes, indeed.  But that's why I think pushing policies into the kernel is better.  I think devd supports more dynamic stuff than we need.
[29-Jun:13:56 phk] As long as we can say "ask devd" we have the escape, I just don't want it to be the default.
[29-Jun:13:57 eivind] phk: right.   I agree.
[29-Jun:13:57 phk] Also, if we can have policies saying "chown to uid+gid of opening process" and such, we're covered for floppies and similar.
[29-Jun:13:57 eivind] right.   very nice.
[29-Jun:13:58 awfulhak] people tend to agree that events should be forced through devd, but devd can in turn feed other programs that register themselves with ded
[29-Jun:13:58 awfulhak] s/ded/devd/
[29-Jun:13:58 phk] awfulhak: can "people" cite two useful examples ?
[29-Jun:13:58 BigFork] enforcing order
[29-Jun:13:59 awfulhak] phk: enforcing order is the main reason (thanks bigfork)
[29-Jun:13:59 phk] BigFork: explain ?
[29-Jun:13:59 awfulhak] phk: we're wondering if there's a good reason.....
[29-Jun:13:59 BigFork] a detach event and a reattach event need to be sent out in that order, or perhaps we want to ensure we get a chacne to clean up before we forward a detach event for example
[29-Jun:14:00 jlemon] phk: rwatson's arguing that perhaps arrival of a crypto board (for example) should not be visible to  random snooping processes.
[29-Jun:14:00 phk] jlemon: but then the policy for that card would be uid=0,gid=0,mode=0 or maybe even "let_devd_decide=1"
[29-Jun:14:00 awfulhak] phk: Also it makes it easier for applications - "I just want events of these classes"
[29-Jun:14:01 phk] the issue of arrival and departure would probably best be handled by queuing the events and not releasing until devd ack's the one it got.
[29-Jun:14:01 phk] awfulhak: I'm still not sure such generality is actually useful.
[29-Jun:14:01] * awfulhak thinks me neither
[29-Jun:14:02 phk] if devd will basically allow root to execute a given cmdline for "arrival" and "departure" we should be covered. (optional sideorder of suspend, revive)
[29-Jun:14:03 phk] who are "people" btw ?
[29-Jun:14:03 bsdimp] phk: The issue with devd routing the devices is to keep the kernel peice simple.
[29-Jun:14:03 BigFork] rwatson, bsdimp, jlemon, paul, jhb, brian somers (well, that's who is present atm.. I'm making imp read his irc window:)
[29-Jun:14:03 bright] i think it would make sense to classify devices
[29-Jun:14:03 bsdimp] It is hard to have meany readers.
[29-Jun:14:04 bright] it wouldn't make that much of a difference, but by having disk device root:operator 640
[29-Jun:14:04 bright] s/device/devices would make it easier to implement default policy
[29-Jun:14:04] * eivind thinks it might be of advantage if phk was dialled into devd discussions through a speaker phone
[29-Jun:14:04] * bright read that as:
[29-Jun:14:05 bright] * eivind thinks it might be of advantage if phk was dialled into each instance of devd to make sure it DTRT
[29-Jun:14:05 bsdimp] Does anybody have a speaker phone attachment for their cell phone
[29-Jun:14:05] * phk would probably need a whiteboard..
[29-Jun:14:05 bsdimp] hmmmm acpi hmmmm
[29-Jun:14:06 awfulhak] We think we'll stop talking about devd 'till tomorrow now....
[29-Jun:14:06 Evil-Bill] Ok, where is everyone?
*** [29-Jun:14:06] Topic by awfulhak on #kernelsummit: change of topic....
[29-Jun:14:06 BigFork] I want to talk about networking locking
[29-Jun:14:06 phk] question: we agree that it is the device driver author who decides which "device class" the driver belongs to, or should it be possible to dynamically say "ad2 is actually a ``tape``" ?
[29-Jun:14:06 BigFork] since jlemon is here
*** [29-Jun:14:07] Topic by bsdimp on #kernelsummit: kernel threading of network stack
[29-Jun:14:07] * bsdimp notes jlemon gets nervious
[29-Jun:14:07 BigFork] dfr arrived
[29-Jun:14:07 awfulhak] dfr arrives
[29-Jun:14:07 bsdimp] Hi Doug!
[29-Jun:14:07 bright] phk: no, ad2 only _feels_ like a tape
[29-Jun:14:07 bright] :)
[29-Jun:14:08 bright] anyone not getting any freebsd.org mail today? or is it just me?
[29-Jun:14:08 Evil-Bill] BigFork: where are you guys?
[29-Jun:14:09 bright] mail seems to be dead since 11:30am PST
[29-Jun:14:09 phk] what time is the session tomorrow ?
[29-Jun:14:09 rwatson] Evil-Bill: New Hampshire
[29-Jun:14:09 cmc] bright: Still getting commit mail.
[29-Jun:14:09] * Evil-Bill takes away rwatson's commit bit.
[29-Jun:14:09 rwatson] Evil-Bill: that's the room name, 5th floor
[29-Jun:14:09 Evil-Bill] Ah.
[29-Jun:14:10] * rwatson smacks Evil-Bill
[29-Jun:14:10] * Evil-Bill gives rwatson back his commit bit.
[29-Jun:14:10 bright] cmc: when was the last mail you got?
[29-Jun:14:10 rwatson] 11:am EST
[29-Jun:14:10 bsdimp] 11pm EST
[29-Jun:14:10 rwatson] amamama
[29-Jun:14:10 bsdimp] s/pm/am
[29-Jun:14:10 rwatson] networking is starting
[29-Jun:14:10 eivind] bright: dd          2001/06/29 14:09:10 PDT
[29-Jun:14:10 cmc] From: Dima Dorfman <dd@FreeBSD.org>
[29-Jun:14:10 cmc] Date: Fri, 29 Jun 2001 14:09:10 -0700 (PDT)
[29-Jun:14:10 bright] ok, i'm screwed
[29-Jun:14:11 bsdimp] hi ade
*** [29-Jun:14:11] Joined #kernelsummit: micky85 (~paul@199.103.159.3)
*** [29-Jun:14:11] Signoff: awfulhak (Client Exiting)
*** [29-Jun:14:11] Joined #kernelsummit: awfulhak (~brian@199.103.159.3)
*** [29-Jun:14:12] micky85 is now known as originat
*** [29-Jun:14:12] Left #kernelsummit: originat (~paul@199.103.159.3)
*** [29-Jun:14:12] Joined #kernelsummit: originat (~paul@199.103.159.3)
[29-Jun:14:12 phk] what time is the session tomorrow ?
[29-Jun:14:13 rwatson] phk: 11am
[29-Jun:14:13 rwatson] EST
[29-Jun:14:13 bsdimp] phk: 11am EDT
[29-Jun:14:13 phk] anyone has UTC for me ?
[29-Jun:14:13 bsdimp] 0400 UTC.
[29-Jun:14:13 bsdimp] I mean 1600 UTC
[29-Jun:14:13 bsdimp] 11 + 5 is 16 not 4
[29-Jun:14:14 phk] ok, I'll not be online there :-(
[29-Jun:14:14 bsdimp] but we're going to do ports for 1 hour, then lunch, then resume with devd at 1pm (1800utc)
[29-Jun:14:15 bsdimp] Notes:
[29-Jun:14:15 bsdimp] Apple does one big Net funnel lock.
[29-Jun:14:15 phk] I'll be at my in-laws from 13:00Z to approx 22:00Z :-(
[29-Jun:14:15 bright] <bsdimp> Notes:
[29-Jun:14:15 bright] <bsdimp> Apple does one big Net funnel lock.
[29-Jun:14:15 bright] so basically apple has a splimp() across all processors?
[29-Jun:14:16 bsdimp] yes.
[29-Jun:14:16 bright] are the drivers mpsafe?
[29-Jun:14:16 bright] or do the drivers live under net funnel?
[29-Jun:14:16 bsdimp] locking the ifa is probelmatic.
[29-Jun:14:16 bsdimp] everything touches it.
[29-Jun:14:16 bsdimp] bright: not sure.
[29-Jun:14:17 bsdimp] ifnet pointer in mbuf
[29-Jun:14:17 bsdimp] This is scary.
[29-Jun:14:17 bsdimp] Do we just need to bit the bullet and do reference counting in net structures?
[29-Jun:14:18 bsdimp] jlemon: netgraph is a scary area.
[29-Jun:14:18 rwatson] keichii and jake arrive
[29-Jun:14:18 bsdimp] Might want to push off unload issue for now.
[29-Jun:14:19 bsdimp] jlemon: "ifnet going away won't be a huge issue due to the centralized add/remove"
[29-Jun:14:19 bright] deadifnet
[29-Jun:14:20 bsdimp] bigknife says http://www.freebsd.org/~cp/network.html
[29-Jun:14:21] * bsdimp notes that we need a better scribe.
[29-Jun:14:21] * bsdimp notes that this is a harder topic to do this with than devd
[29-Jun:14:22 bsdimp] note: need more power and more tables/chairs for tomorrow
[29-Jun:14:23 rwatson] KAME folk are arriving
[29-Jun:14:23 rwatson] I recognize itojun, but I'm afraid not the rest?
*** [29-Jun:14:23] Joined #kernelsummit: EvilDES (des@des.no)
[29-Jun:14:23 bsdimp] bright, where's your log?
[29-Jun:14:24 EvilDES] log! log! I want a log!
[29-Jun:14:25] * EvilDES is the log monster
[29-Jun:14:25 rwatson] s/log//
[29-Jun:14:25 rwatson] :-)
*** [29-Jun:14:25] Mode on #kernelsummit by rwatson: +ooo aDe awfulhak bright
*** [29-Jun:14:25] Mode on #kernelsummit by rwatson: +ooo dd2 EvilDES originat
*** [29-Jun:14:25] Mode on #kernelsummit by rwatson: +oo tmm tmm2
[29-Jun:14:25 bsdimp] log file
[29-Jun:14:25 dd2] http://blitzkrieg.blackened.com/~dima/IrcLog <-- if someone wants it.
[29-Jun:14:25 rwatson] So we're still looking at the BSD/OS document; jlemon and jhb are attempting to generate a list of structures
*** [29-Jun:14:25] Joined #kernelsummit: keichii_ (~keichii@199.103.159.3)
*** [29-Jun:14:26] Topic by rwatson on #kernelsummit: <dd2> http://blitzkrieg.blackened.com/~dima/IrcLog
*** [29-Jun:14:26] Joined #kernelsummit: itojun (~itojun@199.103.159.3)
*** [29-Jun:14:26] Mode on #kernelsummit by rwatson: +oo itojun keichii_
[29-Jun:14:27 rwatson] For itojun, et al, this url is useful: http://people.freebsd.org/~cp/network.html
[29-Jun:14:28 rwatson] This is the locking stuff currently used in BSD/OS for their SMPng.
[29-Jun:14:28 bsdimp] note: the log file has a bunch of #army stuff that can be ignored.
[29-Jun:14:29 bsdimp] jlemon and big* agree on fewer locks.
[29-Jun:14:29 bsdimp] dux did one lock per layer.
[29-Jun:14:30 uplift] does jhb mean "macro"?
[29-Jun:14:30 bsdimp] jhb notes that we can hide a lot in macros.
[29-Jun:14:30 bsdimp] we're talking about doing loocking per layer or clumps of layers
*** [29-Jun:14:31] Joined #kernelsummit: Roamer` (roam@diskworld.nanolink.com)
[29-Jun:14:31 bsdimp] jlemon points out that we need to redesign datastructures for locking
[29-Jun:14:31 bsdimp] 3 or 4 lock scheme.
[29-Jun:14:31 EvilDES] just a background question - is this meeting going on IRL as well, or just on the net?
[29-Jun:14:31 bsdimp] one for "nic and ethernet" one for "ip tcp" and one for socket.
[29-Jun:14:31 bsdimp] one for ifnet and ifa
[29-Jun:14:31 eivind] DES: live
[29-Jun:14:31 bsdimp] r/w locks are very expensive.  mutex are cheap
*** [29-Jun:14:32] Joined #kernelsummit: hosokawa (~hosokawa@199.103.159.3)
[29-Jun:14:32 bsdimp] mutex are best when you hold it for a short period of time.
[29-Jun:14:32 rwatson] EvilDES: there are about 13 if ys
[29-Jun:14:32 rwatson] er, us.
*** [29-Jun:14:32] Joined #kernelsummit: Debolaz (~debolaz@c224s39h16.upc.chello.no)
[29-Jun:14:32 bsdimp] matt dillian arrive.
[29-Jun:14:33 EvilDES] imp: dillon you mean?
[29-Jun:14:33 bright] actually if you look at how van jacobson was going to do tcp/ip, the socket contains the in/tcp control blocks, having a lock shared between sockets and the associated control blocks will simplify locking and be less expensive
[29-Jun:14:33 EvilDES] ack, I sound like Yoda
[29-Jun:14:33 bsdimp] EvilDES: Yes.  can't sell.
[29-Jun:14:33 bright] jlemon should know what i'm talking about where in Linux the control blocks are actually inside the sockets
[29-Jun:14:34] * bright still not getting mail
[29-Jun:14:34] * bright agitates
[29-Jun:14:34 bsdimp] or spell
[29-Jun:14:35 bsdimp] jlemon: proposal: all route under 1 lock.
[29-Jun:14:35 rwatson] One of the questions just raised was what happens when the interupt comes in.
[29-Jun:14:35 rwatson] Likewise, terminology question on sleeping vs. blocking, for those less familiar with mutexes.vs.locks/etc.
[29-Jun:14:35 bsdimp] jlemon doesn't think a mutex is good.
[29-Jun:14:36 bsdimp] first cut: use a  code lock around the 
[29-Jun:14:36 bsdimp] then move the ifa lock out from under taht code lock
[29-Jun:14:36 itojun] stupid question in background: could bsdi show you guys their current status on fine-grain lock branch?
[29-Jun:14:36 keichii_] itojun : i think they do
[29-Jun:14:36 itojun] or is it impossible?
[29-Jun:14:36 keichii_] it is on builder
[29-Jun:14:36 keichii_] .freebsd.org
[29-Jun:14:36] * DrZiplok digs himself out of the sofa
*** [29-Jun:14:36] Signoff: DrZiplok (ircII/tkirc)
[29-Jun:14:36 bright] simple, driver lock -> (possible mbuf lock) -> driver unlock -> protocol input routine -> socket+control-block lock -----> return
[29-Jun:14:37 rwatson] jlemon notes that we can't implement data locks on current code.
[29-Jun:14:37 bright] itojun: we have thier code as reference 
[29-Jun:14:37 bsdimp] code lock as an approach to get the net out from under giant
[29-Jun:14:37 bright] at least a snapshot of it
[29-Jun:14:37 itojun] i see
[29-Jun:14:38 bsdimp] main problem is that everyone reads ifnet/ifa and makes a decision.
[29-Jun:14:38 EvilDES] rwatson: a) is there a reason why we can't implement data locks (other than the usual worries about aliasing, and about code that ignores the locks)
[29-Jun:14:39 bsdimp] jlemon doesn't think it would be cost effective to lock ifnet and ifa
*** [29-Jun:14:39] Signoff: Debolaz (Ping timeout: 180 seconds)
[29-Jun:14:39 bsdimp] EvilDES: First pass is code.  Second pass data.
[29-Jun:14:39 EvilDES] rwatson: b) can jlemon think of an example situation where data locks would be significantly better than code locks?
[29-Jun:14:39 rwatson] EvilDES: everything is linked to everything else, we're worried about the development cost (jlemon has been working on this for a while)
[29-Jun:14:39 EvilDES] rwatson: or did I c) misunderstand his statement?
[29-Jun:14:40 bsdimp] Summmary "This is a mess. we're working on it"
[29-Jun:14:40 itojun] then my question is, what is the fundamental problem in following bsdi practice?
[29-Jun:14:40 EvilDES] rwatson: ah, OK, so it's "it's too much work", not "it can't be done with our current infrastructure"
*** [29-Jun:14:40] Joined #kernelsummit: Debolaz (~debolaz@c224s39h16.upc.chello.no)
[29-Jun:14:40 bright] itojun: BSD/os practice is ok, but icky in several places
[29-Jun:14:40 EvilDES] rwatson: no further questions then
[29-Jun:14:40 bsdimp] "data structures don't lend themselves to datalocking.  so we're looking at locking the code based on layers"
[29-Jun:14:40 bright] one really icky situation occurs in socketpair() type sockets
[29-Jun:14:41 bsdimp] "the knee bone is connected to the leg bone"
[29-Jun:14:41 bsdimp] data structures have cycles
[29-Jun:14:41 rwatson] EvilDES: he thinks we have to reimplement the stack structures
[29-Jun:14:41 rwatson] julian says he faced the problem with netgraph, and that scheme was probably be too complicated
[29-Jun:14:41] * bright notes that linux has it a lot easier
[29-Jun:14:41 bsdimp] julian talksabout netgraph
[29-Jun:14:41 bright] in linux they have the control blocks inside the socket
[29-Jun:14:41 bsdimp] normally he'd pass data through the nodes.
[29-Jun:14:42 bsdimp] but on locked collisions he queued the data.
*** [29-Jun:14:42] Joined #kernelsummit: chuckie (a08a6d034a@zealot.progeny.com)
[29-Jun:14:42 bsdimp] whoever held the lock would then flush the queue
[29-Jun:14:42 rwatson] julian notes that he implemented the following scheme: lock collisions are frequent, so events are queued until the lock holder decides to deal with them on collision.
[29-Jun:14:42 keichii_] that would actually be a big problem in high speed networks
[29-Jun:14:42 keichii_] e.g. gigE performance goes to shit
[29-Jun:14:43 rwatson] Right now, jlemon and julian are comparing the situations and models between netgraph and the normal stack
[29-Jun:14:43 rwatson] julian also used reader/writer locks
[29-Jun:14:43 bsdimp] jlemon: problems using that in this case is that network stack is one monolithic strucutre.
[29-Jun:14:43 bsdimp] most of the time you are accessing not changing.
[29-Jun:14:44 bsdimp] looking at sx locks on ifnet.  used everywhere.  only changed in ifconfig.
[29-Jun:14:44 keichii_] are we allowed discussion in the channel?
[29-Jun:14:44 bsdimp] if the operation is short, the sx locks too high overhead.
[29-Jun:14:44 bsdimp] mutex are faster.
[29-Jun:14:44 bsdimp] keichii_: yes.
[29-Jun:14:44 rwatson] julian thinks his sxlocks are better
[29-Jun:14:45 rwatson] jlemon doesn't care if it's slow, he just wants it to work :-)
[29-Jun:14:45 bsdimp] 98% of the time, we have a short case.
[29-Jun:14:45 bsdimp] the other 2% are what kills us.
[29-Jun:14:46 bsdimp] walking the lists can use one lock (long) and the rest use a mutex (short)
[29-Jun:14:46 bsdimp] (jhb suggested that)
[29-Jun:14:46 rwatson] they're discussing using multiple lock types on a structure, so as to optimize common case.
[29-Jun:14:46 keichii_] can we implement both
[29-Jun:14:46 bsdimp] keichii_: that's what they are talking abotu.
[29-Jun:14:46 keichii_] upon the long case, use sxlock, on the short case, use mutex
[29-Jun:14:47 keichii_] bsdimp : having difficulty understanding their speech
[29-Jun:14:48 itojun] i'm okay with the speed of the speech, but i should have gone through 5-current sys/net* tree...
[29-Jun:14:48 bsdimp] no sleep on inbound packets.
[29-Jun:14:48 bsdimp] mostly no sleeps on outbound packets because routes are cached (mdillon)
[29-Jun:14:49 bsdimp] incoming no blocking situations (julian)
[29-Jun:14:50 bsdimp] "that's nice dear"
[29-Jun:14:51 itojun] pls define "incoming" - if you mean up until ip layer, forwarding case and icmp response case could get tricky?
[29-Jun:14:51 rwatson] incoming refers to packets arriving off an interface via an interrupt
[29-Jun:14:51 itojun] fine, thanks
[29-Jun:14:51 rwatson] I believe it stops incoming once it enters the network layer
[29-Jun:14:51 rwatson] I'll ask however
[29-Jun:14:52 itojun] then why are people talking about routing code?
*** [29-Jun:14:53] Joined #kernelsummit: ppl- (crow@pix142166194095.nbtel.net)
[29-Jun:14:53 rwatson] sounds like that belief is correct
[29-Jun:14:53 itojun] we won't hit routing table until after we switch to soft interrupt thread
[29-Jun:14:53 bsdimp] itojun that sounds right.
[29-Jun:14:53 rwatson] julian asks if there are any multi-threaded stacks known of
[29-Jun:14:54 dwhite-] solaris?
[29-Jun:14:54 bsdimp] bsdi
[29-Jun:14:54 rwatson] bsdi apparently sold one to digital for 7million
[29-Jun:14:54 bsdimp] Can we get solaris srource still?
[29-Jun:14:54 dwhite-] until tomorrow
[29-Jun:14:55 bsdimp] can someone grab it quit?
[29-Jun:14:55 rwatson] john is going to ask the irix guy
[29-Jun:14:55 bsdimp] Ask the irix guys
[29-Jun:14:55 rwatson] in tru64 they use locking at layers
[29-Jun:14:55 bsdimp] we have it.
[29-Jun:14:55 rwatson] john makes unofficial noises about the code
[29-Jun:14:55 rwatson] bsdimp -- vms stack d under smp resulted in a paper, might still be available
[29-Jun:14:56 rwatson] bsdimp indicates paper should at least have strategies, if not locks
[29-Jun:14:56 bright] solaris, irix, linux, NT
[29-Jun:14:56 rwatson] matt dillon thinks wes should think about critical path
[29-Jun:14:56 bsdimp] jhb suggests that it isn't a big deal.
[29-Jun:14:57 bsdimp] jhb actually suggests that papers might not help much.
[29-Jun:14:57 bright] critical path is already handled by van jacobson
[29-Jun:14:57 rwatson] jhb cautions dillon not to do fast paths early, ended up hurting performance
[29-Jun:14:57 bsdimp] irix guys tried to create a lot of fast paths.  fast paths made things run slower.
[29-Jun:14:57 bright] irix is slow period
[29-Jun:14:57 rwatson] matt dillon indicates that what that refers to doesn't apply
[29-Jun:14:57 rwatson] bright: irix is fast, just not on n<16 processors :-)
[29-Jun:14:58 keichii_] rwatson : irix has about a thousand locks....
[29-Jun:14:58 bright] it's actually fast, i'm just being mean
[29-Jun:14:58 rwatson] keichii_: I like 1024p IRIX boxes
[29-Jun:14:58 bright] anything that doesn't ship with snprintf in 1999 sucks
[29-Jun:14:58 keichii_] rwatson : buy me one
[29-Jun:14:58 rwatson] keichii_: hahaha :-).  I'll get you a free marriott pen
[29-Jun:14:59 rwatson] debate on the topic of what to lock
[29-Jun:14:59 rwatson] (dillon, jlemon)
[29-Jun:14:59 rwatson] dillon points out that existing caching was done as performance optimizations, we can leverage that
[29-Jun:14:59] * bright _really_ thinks that inpcb/tcpcb/socket should share a common lock
[29-Jun:14:59 bright] (on each structure)
[29-Jun:15:00 rwatson] bright: lock ordering there could indeed be the main motivation to do that
[29-Jun:15:00 bright] not a global lock for each
[29-Jun:15:00 bsdimp] bright: We're talking about a code lock for the three, or were earlier
[29-Jun:15:00 keichii_] i implemented a load balancer for freebsd a year ago
*** [29-Jun:15:00] Joined #kernelsummit: greid (fakeuser@vilnya.demon.co.uk)
[29-Jun:15:00 keichii_] i ended up making several processes that share a database for the routes
[29-Jun:15:01 keichii_] database access time is actually negligible in this case
[29-Jun:15:01 keichii_] since it's all in memory anyway
[29-Jun:15:01 rwatson] bsdimp: the opinion has been expressed that the complexity of current structures is high, and that optimization would be premature.
[29-Jun:15:01 rwatson] bsdimp: likewise, using macros will let us change the lock model later
[29-Jun:15:01 itojun] is the channel announced to committers?  do you mind if other JP committers listen on? (it's 6AM so it is very unlikely though)
[29-Jun:15:02 rwatson] dillon wants an sx lock protecting the various ifnet/ifp/ifa structures
[29-Jun:15:02 rwatson] feel free
[29-Jun:15:02 keichii_] itojun : go ahead and announce
[29-Jun:15:02 bsdimp] itojun: announced  go for it.
[29-Jun:15:02 itojun] done
[29-Jun:15:02 bsdimp] itojun: thanks.
[29-Jun:15:02 rwatson] jlemon--code lock defines him to define the boundary of the code, which is the first step towards elminating
[29-Jun:15:02] * bsdimp announces it on developers
[29-Jun:15:02 rwatson] dillon--problem with doing that is it makes it hard to move the code out, similar to giant lock
[29-Jun:15:03 rwatson] dillon--not helpful to do at code lock
[29-Jun:15:03] * bright agree with dillon
[29-Jun:15:03 bright] big locks suck
[29-Jun:15:03 bright] especially since we can't sleep with mutexes
[29-Jun:15:03 rwatson] bright: yeah, we had a long discussion of reasons to sleep in the stack
[29-Jun:15:03 bright] it'd be nice if we could decalare certain mutexes to be like Giant
*** [29-Jun:15:03] Joined #kernelsummit: DrZiplok (msmith@ziplok.dis.org)
[29-Jun:15:03 bsdimp] minigiant
[29-Jun:15:03 bright] so that they get unwound automagically on sleep
[29-Jun:15:04 bright] if i had that, the vm lock may have worked
[29-Jun:15:04 rwatson] comments that will not be repeated are made
[29-Jun:15:04 bright] we really can't do large code locks without that ability
*** [29-Jun:15:04] Left #kernelsummit: chuckie (a08a6d034a@zealot.progeny.com)
[29-Jun:15:04 rwatson] dillon compares vm system with proposed solution
[29-Jun:15:04 itojun] are there any emprical result available?  if i were responsible about this, i would put some large read locks and measure performance/cpu usage/whatever on test traffic...
*** [29-Jun:15:04] Signoff: tmm2 (ircII EPIC4-1.0.1 -- Are we there yet?)
[29-Jun:15:05 rwatson] dillon indicates alfred's initial locking scheme for vm may be easier than the code locking path
[29-Jun:15:05 itojun] tuning can't be done without any measured results.
[29-Jun:15:05 keichii_] itojun : i think we agree that we at least need more locks than just Giant
[29-Jun:15:05 rwatson] itojun: you mean wrt locks themselves, or rather the impact on the stack?
[29-Jun:15:05 keichii_] after that, we can use empiricial methods to decide
[29-Jun:15:05 rwatson] i.e., you're suggesting experimenting by dropping some locks in to measure concurrency?
[29-Jun:15:06 itojun] i said "large" to mean "less than giant" :-)
*** [29-Jun:15:06] Mode on #kernelsummit by bsdimp: +ooo Debolaz DrZiplok greid
*** [29-Jun:15:06] Mode on #kernelsummit by bsdimp: +oo hosokawa ppl-
*** [29-Jun:15:06] Mode on #kernelsummit by bsdimp: +o Roamer`
*** [29-Jun:15:06] Mode on #kernelsummit by awfulhak: -o bsdimp
[29-Jun:15:06 rwatson] :-)
*** [29-Jun:15:06] Mode on #kernelsummit by awfulhak: +o bsdimp
[ Whois ppl-!crow@pix142166194095.nbtel.net ]
: ircname  : User Crow admin
: channels : @#kernelsummit +#andromeda_complex #linuxquebec #BSDpro 
: server   : irc.emory.edu ([tiger.sph.emory.edu] Emory University - Atlanta)
[29-Jun:15:07 bsdimp] itojun: I don't think that we've done any measurement.
[29-Jun:15:07 rwatson] mike smith agrees that moving beyond a few locks might be premature
[29-Jun:15:08 rwatson] dillon thinks measuring won't help
[29-Jun:15:08 awfulhak] imp thinks size doesn't matter
[29-Jun:15:08 itojun] bsdimp: see, thanks.  i was afraid i was asking too stupid questions...
[29-Jun:15:08 itojun] you dont' need to commit, to measure performance.  you can do #ifdef MEASURE if you really need to commit
*** [29-Jun:15:09] Joined #kernelsummit: DrZiplok_ (msmith@ziplok.dis.org)
*** [29-Jun:15:11] Mode on #kernelsummit by awfulhak: +o DrZiplok_
[29-Jun:15:11 rwatson] The main point of contention right now is how fine-grained to do in the first step--dillon thinks we need to be more agressive
[29-Jun:15:11 rwatson] There seems to be broad agreement that over-optimizing is bad, now we juust have to define that
*** [29-Jun:15:11] Signoff: Debolaz (Read error: 54 (Connection reset by peer))
*** [29-Jun:15:11] Signoff: DrZiplok (irc.exodus.net ircd.east.gblx.net)
*** [29-Jun:15:11] Signoff: Evil-Bill (irc.exodus.net ircd.east.gblx.net)
*** [29-Jun:15:11] Signoff: uplift (irc.exodus.net ircd.east.gblx.net)
*** [29-Jun:15:11] Signoff: BigFork (irc.exodus.net ircd.east.gblx.net)
*** [29-Jun:15:11] Signoff: jlemon (irc.exodus.net ircd.east.gblx.net)
*** [29-Jun:15:11] Signoff: dwhite- (irc.exodus.net ircd.east.gblx.net)
*** [29-Jun:15:11] Signoff: aDe (irc.exodus.net ircd.east.gblx.net)
*** [29-Jun:15:11] Signoff: ppl- (irc.exodus.net ircd.east.gblx.net)
*** [29-Jun:15:12] Signoff: bright (irc.exodus.net ircd.east.gblx.net)
*** [29-Jun:15:12] Signoff: wca (irc.exodus.net ircd.east.gblx.net)
[29-Jun:15:12 bsdimp] nfs and network stack
[29-Jun:15:12 itojun] rwatson: (very old response) i was wondering as it may not really help when you put too many locks.  measurement is really important, and comple of strategies should be tried in test environment
[29-Jun:15:12 rwatson] for a bit, there was discussion of stability and instability--dfr pointed out that introducing greater instability than the last couple months
[29-Jun:15:12 rwatson] itojun: I think we all agree, it's just a question of how not to have too many locks :-)
*** [29-Jun:15:13] Joined #kernelsummit: ume ([hfmGGA1io@piano.calm.imasy.or.jp)
[29-Jun:15:13 rwatson] julian asks about lock order reversals moving to other subsystems, such as nfs
[29-Jun:15:13 rwatson] I point out that mbuf's are fairly self-contained, so it's possible to release layer locks meaning lock order reversals are unlikely with the layered approach, including nfs.
[29-Jun:15:13 DrZiplok_] keichii sinks the entire plan by mentioning that Linux locks in a similar fashion.
*** [29-Jun:15:13] Joined #kernelsummit: Debolaz (~debolaz@213.46.204.224)
[29-Jun:15:14 itojun] rwatson: yup.  and my another question in myself is, for what case do you tune.  the comment about pcb cache sounded like tuning for end nodes, not for routers.
[29-Jun:15:14] * keichii_ kicks DrZiplok_ 
[29-Jun:15:14 rwatson] dfr points out using the tru64/...everyone else... strategy might be a good way to do things.
[29-Jun:15:14 DrZiplok_] However, general agreement that this path has been travelled many times before and that it's a good way to start.
[29-Jun:15:16 rwatson] itojun: I think that you're right that the current concentration has been on end-nodes
[29-Jun:15:17 bsdimp] evil-bill rolls in
*** [29-Jun:15:18] Joined #kernelsummit: tmm2 (ibrzev@pD900C6B5.dip.t-dialin.net)
[29-Jun:15:18 rwatson] ok, looks like we're finishing up.
[29-Jun:15:18 rwatson] concensus seems to be:
[29-Jun:15:18 bsdimp] just in time to break up for the night.
[29-Jun:15:18 rwatson] 1) The layered lock path seems not to be worse than everything else
[29-Jun:15:19 rwatson] 2) really concerned about possibility of optimizing too agressively too early
[29-Jun:15:19 rwatson] 3) minor point: we should do more research into what other platforms do
[29-Jun:15:19 DrZiplok_] 3b) we should measure how those systems' approaches work for us
[29-Jun:15:20 rwatson] (dillon is talking about the cache bashing relating to preemption and interupt threads)
[29-Jun:15:22] * DrZiplok_ thinks that Dillon is off in the weeds already
[29-Jun:15:22 rwatson] can someone else log this?  it's not an area where I know much
[29-Jun:15:22 DrZiplok_] Dillon's concern is that preemption can result in thread ping-ponging 
[29-Jun:15:23 DrZiplok_] thus moving its data from one CPU to another, causing cache thrash
[29-Jun:15:23 DrZiplok_] Jake contradicts Dillon
[29-Jun:15:23 rwatson] jake challanges dillon's understanding of the bsdi code
[29-Jun:15:23 DrZiplok_] wrt. to what BSD/OS does.
[29-Jun:15:24 rwatson] dillon asserts they have the same problem, jake asserts they have the same design
[29-Jun:15:25 rwatson] mike forces dillon to clarify: he is worried about uncontrolled thread migration, not preemption
*** [29-Jun:15:25] Joined #kernelsummit: BigFork (john@server.baldwin.cx)
*** [29-Jun:15:25] Joined #kernelsummit: wca (will@casimir.physics.purdue.edu)
*** [29-Jun:15:25] Mode on #kernelsummit by ircd.east.gblx.net: +o BigFork
[29-Jun:15:26 rwatson] discussion of per-cpu accesses -- dillon is worried about PCPU in context of migration
[29-Jun:15:26 rwatson] dfr suggests cpu locking a thread in kernel mode
[29-Jun:15:26 rwatson] dillon notes he likes this, doesn't require a mutex, use a flag to influence scheduler
[29-Jun:15:26 rwatson] dfr points out a thread-property, not a cpu property
[29-Jun:15:27 DrZiplok_] dillon's concern is that if we want to do things that assume that threads won't migrate from CPU to CPU, our current behaviour (aggressively trying to run threads whenever possible) will defeat this.
*** [29-Jun:15:27] Joined #kernelsummit: jlemon (~jlemon@freefall.freebsd.org)
*** [29-Jun:15:27] Joined #kernelsummit: kjc (~kjc@199.103.159.3)
[29-Jun:15:27 itojun] dillon is talking about outgoing path only, right?
[29-Jun:15:27 rwatson] itojun: at this point, it's largely about generic preemption by an interupt, rather than specifically in the network stack
*** [29-Jun:15:27] Joined #kernelsummit: dmlb (~dmlb@pc1-camb6-0-cust228.cam.cable.ntl.com)
*** [29-Jun:15:28] Signoff: dmlb (Leaving)
[29-Jun:15:29 itojun] can you route interrupt to your favorite CPU?
*** [29-Jun:15:29] Signoff: ume (irchat exiting...)
[29-Jun:15:29 itojun] like CPU that is holding mbuf on the top of fxp0 queue...
*** [29-Jun:15:29] Joined #kernelsummit: ume ([WCVDzMIGg@piano.calm.imasy.or.jp)
[29-Jun:15:29 itojun] i guess the discussion is going way too far.
[29-Jun:15:30 rwatson] itojun: I believe the idea of beinding interfaces to a particular cpu is an implicit benefit people may be keeping in mind.
*** [29-Jun:15:30] Signoff: jlemon (ircII EPIC4-2000 -- Accept no limitations)
[29-Jun:15:30 rwatson] itojun: they've also been talking about per-cpu mbuf pools
[29-Jun:15:30 keichii_] i think implementing general processor affinity would be better
*** [29-Jun:15:30] Joined #kernelsummit: dmlb (~dmlb@pc1-camb6-0-cust228.cam.cable.ntl.com)
*** [29-Jun:15:30] Joined #kernelsummit: jlemon (~jlemon@199.103.159.3)
[29-Jun:15:31 itojun] but you have been talking about optimization for client, which would have single interface in most cases...  binding interface to particular CPU looks nice for outbound + 802.3AD, but for inbound it sucks bad
[29-Jun:15:32 itojun] (if i take CPU switch due to per-CPU alloc'ed mbuf seriously)
[29-Jun:15:32 Roamer`] keichii, all: there has been a post to -hackers an hour or so ago, talking about possible implementations of processor affinity.  It raises some interesting points.
*** [29-Jun:15:33] Joined #kernelsummit: goofy6 (~dmlb@pc1-camb6-0-cust228.cam.cable.ntl.com)
*** [29-Jun:15:33] Joined #kernelsummit: josefk (~joe@genesis.tao.org.uk)
[29-Jun:15:33 rwatson] itojun: I think the primary focus here is not on network right now--just general interupt thread concerns
[29-Jun:15:33 itojun] see, sorry for the noise
[29-Jun:15:33 Roamer`] (though the -hackers post is mainly process-related, not kthread/ithread related)
[29-Jun:15:34 rwatson] itojun: no problem
[29-Jun:15:34 rwatson] can someone scribe the current conversation?
[29-Jun:15:36 DrZiplok_] keichii_: the problem with "general affinity" is that it's not a guarantee, which is Dillon's issue
[29-Jun:15:37] * rwatson hopes it is dinner time soon.
[29-Jun:15:37 DrZiplok_] dillon wargames an interrupt
[29-Jun:15:37 keichii_] is it worth all this effort to do so much for exceptions?
[29-Jun:15:37 DrZiplok_] that depends on interrupt load
[29-Jun:15:37 itojun] keiichi: i guess i agree, it makes sense only after measurement... (again)
[29-Jun:15:37 DrZiplok_] see above inre: measurement
*** [29-Jun:15:38] Mode on #kernelsummit by awfulhak: +ooo dmlb jlemon josefk
*** [29-Jun:15:39] Signoff: goofy6 (ircII/tkirc)
[29-Jun:15:39 rwatson] dillon challenges current incorrect focus of SMPng.
[29-Jun:15:40 rwatson] lots of discussion of preemption, priority inversion, thread migration, interrupts, etc, etc, etc...
[29-Jun:15:40 itojun] dillon is going back to giant lock concept???
*** [29-Jun:15:40] Joined #kernelsummit: bright (bright@sneakerz.org)
*** [29-Jun:15:40] Joined #kernelsummit: aDe (ident@hub.lovett.com)
*** [29-Jun:15:40] Mode on #kernelsummit by ircd.lightning.net: +oo bright aDe
[29-Jun:15:40 jlemon] from what I seem to follow is that dillon doesn't like interrupt threads.
[29-Jun:15:40 rwatson] itojun: this I believe has mostly to do with what preempts what--more to do with policies for migrating, and light-weight threads
[29-Jun:15:40 rwatson] itojun: this is mostly an argument about thread scheduling
[29-Jun:15:41 itojun] do you switch process thread (or process) every time you get interrupt?
[29-Jun:15:41 rwatson] it's an edge case
*** [29-Jun:15:41] Signoff: josefk (Killed (irc.exodus.net (irc.isdnet.fr <- ircd.lightning.net[207.45.69.70])))
*** [29-Jun:15:41] Joined #kernelsummit: josefk_ (~joe@genesis.tao.org.uk)
[29-Jun:15:41 rwatson] jlemon, inspired, suggests drawing a picture
[29-Jun:15:41 itojun] i don't understand.  how frequently bsdi trick (proper kernel thread invocation on interrupt) happen?
[29-Jun:15:43 rwatson] jake: ``It's about correctness''   dillon: ``No it's not''
[29-Jun:15:44 DrZiplok_] I think that people should start throwing candy.
[29-Jun:15:44 rwatson] I think we should go to dinner
[29-Jun:15:44] * jlemon seconds rwatson.
[29-Jun:15:44 bsdimp] food
[29-Jun:15:44 bsdimp] food
[29-Jun:15:44 bsdimp] food
[29-Jun:15:44 bsdimp] food
[29-Jun:15:44 bsdimp] food
[29-Jun:15:44 jlemon] beer
[29-Jun:15:45 jlemon] beer
[29-Jun:15:45 jlemon] beer
[29-Jun:15:45 jlemon] beer
[29-Jun:15:45 rwatson] jhb wants coke
[29-Jun:15:45 BigFork] jhb is nisane
[29-Jun:15:45 rwatson] nisane?
[29-Jun:15:45 rwatson] perhaps insane?
[29-Jun:15:45] * rwatson runs.
[29-Jun:15:45 BigFork] jhb is not going to say anything else
[29-Jun:15:45 BigFork] at the risk of losing my temper
[29-Jun:15:45 rwatson] jhb is a bit like caesar, he refers to himself in the third person.
[29-Jun:15:45 rwatson] jhb goes, sees, and conquers.
[29-Jun:15:46 jlemon] I wish dillon would shut up and give jake a turn at the board.
[29-Jun:15:46 rwatson] hey, peter's back.
[29-Jun:15:46 keichii_] he's been here since dillon started
[29-Jun:15:46 BigFork] s/and.*$//
[29-Jun:15:47] * bsdimp heads starts to spin.
[29-Jun:15:47] * jlemon hears "optimize" and tunes out everything after that.
[29-Jun:15:48] * rwatson enjoys the use of the word ``bust'' in the same sentence as ``cache''.
[29-Jun:15:48] * rwatson types ``cash'' and ponders dinner.
[29-Jun:15:48 BigFork] 10 minutes
[29-Jun:15:49] * rwatson watches dillon mow over itojun.
[29-Jun:15:49 ume] have a good dinner.  I'm too sleepy.  I'll go to bed.
[29-Jun:15:50 rwatson] ume: sounds wise
*** [29-Jun:15:50] Signoff: awfulhak (Client Exiting)
[29-Jun:15:50 keichii_] rwatson : i think that's the general jargon :Q
[29-Jun:15:50 itojun] aha, you are still awake... i assumed that you woke up early
[29-Jun:15:50] * keichii_ needs food
[29-Jun:15:50 keichii_] we need to leave for dinner?
*** [29-Jun:15:51] Signoff: keichii_ (BitchX: the new hardcore, psycho, nitro client -- in a can)
*** [29-Jun:15:51] Signoff: jlemon (following keichii...)
*** [29-Jun:15:51] Signoff: BigFork (food now)
*** [29-Jun:15:51] Signoff: itojun (Leaving)
*** [29-Jun:15:51] Signoff: rwatson (doof)
*** [29-Jun:15:51] Signoff: hosokawa (Remote closed the connection)
*** [29-Jun:15:51] Signoff: bsdimp (food is near)
*** [29-Jun:15:51] Signoff: ume (irchat exiting...)
*** [29-Jun:15:52] Signoff: kjc (Leaving)
[30-Jun:08:11] * bsdimp notes that usenix' network goes down at 2pm today.  It is now 11:10
[30-Jun:08:11] * awfulhak notes that the topic should be changed to http://people.freebsd.org/~jhb/summit/schedule.txt
[30-Jun:08:13 tmm3] Hmm, if that schedule is about right, we'll miss most :(
[30-Jun:08:15 bsdimp] How we count "1 2 3 10"
[30-Jun:08:15 BigSpoon] ok
[30-Jun:08:15 rwatson] keichii demonstrates "new math"
[30-Jun:08:15 BigSpoon] next time
[30-Jun:08:15 BigSpoon] I will tell everyone to be here at 9am
[30-Jun:08:15 BigSpoon] maybe then they will be here by 11
[30-Jun:08:15 freebie] you're an optimist.. 
*** [30-Jun:08:16] Joined #kernelsummit: jkh_ (~JordanHub@tserver.conference.usenix.org)
[30-Jun:08:18 BigSpoon] bah
[30-Jun:08:18 jkh_] ba
[30-Jun:08:18 bsdimp] holocane
[30-Jun:08:18 rwatson] bah
[30-Jun:08:18 jkh_] sound off!
[30-Jun:08:19 bsdimp] imp!
[30-Jun:08:20 bsdimp] Warner Losh
*** [30-Jun:08:21] Joined #kernelsummit: dfr (~dfr@tserver.conference.usenix.org)
[30-Jun:08:22 dfr] Hi
[30-Jun:08:22 tmm3] hmm, is someone videotaping this as it was planned?
[30-Jun:08:22 dfr] not yet
*** [30-Jun:08:22] Joined #kernelsummit: sos (~sos@212.242.86.115)
[30-Jun:08:22 BigSpoon] powerpc: openfirmware progress in the kernel..
[30-Jun:08:23 BigSpoon] powerpc: looking to do ddb over ethernet for lack of a serial console (keichii)
[30-Jun:08:23 BigSpoon] powerpc: locore 1/2 done, pmap close to done
[30-Jun:08:23 bsdimp] G4 only for powerpc.
[30-Jun:08:23 EvilPete] after the network goes down, irc server: 10.0.1.171:6667.  remember to switch to adhoc first.
[30-Jun:08:23 BigSpoon] power: hopefully single user by 5.0
[30-Jun:08:23 bsdimp] Single user by 5.0
[30-Jun:08:24 bsdimp] powerbook
[30-Jun:08:24 bsdimp] titanium
[30-Jun:08:24 bsdimp] ibook
[30-Jun:08:24 bsdimp] 7410
[30-Jun:08:24 bsdimp] robert asks about the ABI?
[30-Jun:08:24 bsdimp] embedded or other?
[30-Jun:08:25 bsdimp] no abi has been been pciked
[30-Jun:08:25 BigSpoon] embedded being used now
[30-Jun:08:25 BigSpoon] linux uses svr4
[30-Jun:08:25 bsdimp] embedded in use now.  SVR4 maybe in the future
*** [30-Jun:08:26] Joined #kernelsummit: micky60 (~paul@tserver.conference.usenix.org)
[30-Jun:08:26 bsdimp] bill paul arrives
[30-Jun:08:26 bsdimp] endian indendent ffs
*** [30-Jun:08:26] Left #kernelsummit: micky60 (~paul@tserver.conference.usenix.org)
[30-Jun:08:26 BigSpoon] linear independent file system
[30-Jun:08:26 BigSpoon] like ffs
[30-Jun:08:27 BigSpoon] maybe we need to beat up on kirk for this
*** [30-Jun:08:27] Joined #kernelsummit: originat (~paul@tserver.conference.usenix.org)
[30-Jun:08:27 BigSpoon] s/linear/endian/
[30-Jun:08:27 bsdimp] netbsd is endian independent.
[30-Jun:08:27 BigSpoon] netbsd has an endian independent file system
[30-Jun:08:28 BigSpoon] either specify (possibly indirectly by the magic number) specify the endianness of the file system
[30-Jun:08:29 bsdimp] peter wants them to be compile time option
[30-Jun:08:29 bsdimp] "bisexual ffs option"
[30-Jun:08:31 BigSpoon] dfr thinks we should use a fixed endian file system
*** [30-Jun:08:31] Signoff: originat (Ping timeout: 240 seconds)
[30-Jun:08:32 bsdimp] jake wants newfs to pick
[30-Jun:08:33 BigSpoon] booting probably requires the native boot order
[30-Jun:08:33 BigSpoon] (imp)
[30-Jun:08:33 bsdimp] g4 and g3 powerbook support.
[30-Jun:08:34 bsdimp] then embedded platforms.
[30-Jun:08:34 EvilPete] another option is to be able to compile an alternate filesystem.. eg: "ffs" = native, "beffs" = big endian, "leffs" = little endian
[30-Jun:08:34 EvilPete] eg: on i386: mount -t beffs /dev/sparcdisk0
[30-Jun:08:35 bsdimp] ia64 (doug) status
[30-Jun:08:35 EvilPete] and that encapsulates the byte swapping into a seperate code module
[30-Jun:08:35 BigSpoon] single user in emulation mode
[30-Jun:08:35 bsdimp] in simulator, singleuser mode and we gets a signal
[30-Jun:08:35 BigSpoon] signals seem to work
[30-Jun:08:35 bsdimp] two stacks
[30-Jun:08:35 bsdimp] need to cope
[30-Jun:08:36 bsdimp] stacks grow downards, but register stack grows up.
[30-Jun:08:36 bsdimp] auto on regular stack.
[30-Jun:08:37 bsdimp] a bit sparc register windows.
[30-Jun:08:37 BigSpoon] explanation of the ia64 register stack engine and spilling ot memory
[30-Jun:08:37 bsdimp] "how much is that in bytes"
*** [30-Jun:08:37] Joined #kernelsummit: Storm- (~veers@24.101.36.233.on.wave.home.com)
[30-Jun:08:38 bsdimp] pete says mozilla goes up to 1200 frames deep.
[30-Jun:08:38 bsdimp] guard page
[30-Jun:08:39 bsdimp] threads library
[30-Jun:08:39 BigSpoon] rwaton suggests looking at linux's ia64 stuff
[30-Jun:08:39 bsdimp] seconds tack near end of maxstack
[30-Jun:08:40 BigSpoon] woot, a tripod!
*** [30-Jun:08:40] Joined #kernelsummit: GlockaDe (ident@hub.lovett.com)
[30-Jun:08:41 awfulhak] grog found a tripod -- the meeting pauses while we bikeshed about where it goes
[30-Jun:08:43] * jkh_ sighs in relief at not having to hold the camera anymore
[30-Jun:08:43 bsdimp] loader
[30-Jun:08:43 BigSpoon] jkh_: heh
[30-Jun:08:43 bsdimp] runs on hardware
[30-Jun:08:43 bsdimp] trying to get ficl work
[30-Jun:08:43 BigSpoon] needing to debug setjmp/longjmp
[30-Jun:08:43 bsdimp] debugging setjmp/longjmp
[30-Jun:08:44 bsdimp] once loading, then bring it up on a real machine
[30-Jun:08:44 BigSpoon] next step is booting a kernel on a real machine
[30-Jun:08:44 bsdimp] dfr has a real machine
[30-Jun:08:44 BigSpoon] dfr has access to a real machine
[30-Jun:08:44 bsdimp] toolchain issue
[30-Jun:08:44 BigSpoon] toolchain issues with gcc 3.0
[30-Jun:08:44 bsdimp] c++has big issues
[30-Jun:08:45 bsdimp] toolchain
[30-Jun:08:45 BigSpoon] crossbuilding a real userland
[30-Jun:08:45 groggy] awfulhak: I didn't "find" a tripod, I brought it half way round the world.
[30-Jun:08:45 BigSpoon] single user on real hardware by 5.0
[30-Jun:08:45 bsdimp] single user before 5.0
[30-Jun:08:45 bsdimp] smt
[30-Jun:08:45 bsdimp] (4 cpus sorta on one die)
[30-Jun:08:46 bsdimp] asks about scalability
[30-Jun:08:46 bsdimp] plan ahead
[30-Jun:08:48 bsdimp] ibm interested in 96cpu.
[30-Jun:08:48 bsdimp] powerpc
[30-Jun:08:48 bsdimp] at least 32 cpus
[30-Jun:08:48 BigSpoon] not sure that should be public info possibly :)
[30-Jun:08:48 bsdimp] coffie
[30-Jun:08:48 BigSpoon] coffe is here
[30-Jun:08:48 bsdimp] coffee
[30-Jun:08:49 dfr] coffee arrives...
[30-Jun:08:49 awfulhak] coffee's important !
[30-Jun:08:49] * BigSpoon notes we are slipping on the schedule
[30-Jun:08:49 bsdimp] talk schedule or 5.0 release schedule
[30-Jun:08:49 BigSpoon] talk schedule
[30-Jun:08:49 bsdimp] signature!
[30-Jun:08:49 BigSpoon] I think I'll delegate questions to the end of each section from now on
[30-Jun:08:49 bsdimp] BigSpoon: we may need a talking stick.
[30-Jun:08:50 bsdimp] powerpc
[30-Jun:08:50 bsdimp] beeno
*** [30-Jun:08:50] Joined #kernelsummit: originat (~paul@tserver.conference.usenix.org)
[30-Jun:08:50 bsdimp] working his way through the probe
[30-Jun:08:50 bsdimp] ppc32
[30-Jun:08:50] * BigSpoon notes 5 minutes to the break for the end of the first session
[30-Jun:08:50 bsdimp] little endian?
[30-Jun:08:50] * BigSpoon hopes jake's sparc64 update isn't long :)
[30-Jun:08:51 bsdimp] nether netbsd nor freebsd works on ppc64
[30-Jun:08:51 dfr] american coffee :-(
[30-Jun:08:51 bsdimp] groggy will doing it on his occasional basis
[30-Jun:08:51 bsdimp] limited number of trusted people can be given access
[30-Jun:08:52] * nik notes that mail coming from freebsd.org appears to have stalled.
[30-Jun:08:52 BigSpoon] to a dual ppc64 machine
[30-Jun:08:52 bsdimp] brothel valley wineries
[30-Jun:08:53 bsdimp] ultra5
[30-Jun:08:53 BigSpoon] sparc65 port from jake
[30-Jun:08:53 BigSpoon] remote access to an ultra5, no local box yet
[30-Jun:08:53 bsdimp] jake into file system issues.
[30-Jun:08:53 groggy] bsdimp: Barossa.
[30-Jun:08:53 BigSpoon] definitely single user by 5.0
[30-Jun:08:53 bsdimp] single user by 5.0
[30-Jun:08:53 groggy] bsdimp: But McLaren Vale is closer.
[30-Jun:08:53 bsdimp] stack is the same
[30-Jun:08:53 bsdimp] window register don't change things too much.
[30-Jun:08:54 BigSpoon] aiming for sparc64 pci based machines
[30-Jun:08:54 BigSpoon] obrien doens't want sbus support :)
[30-Jun:08:54 BigSpoon] most sparc64's are pci
[30-Jun:08:54 bsdimp] obrien can cope :-)
[30-Jun:08:54 BigSpoon] Ade Lovett will provide access to an e4500
[30-Jun:08:55 BigSpoon] 8 cpu's and 16 gigs of ram (*envy*: bk)
[30-Jun:08:55 BigSpoon] lots of native devices might be sbus
[30-Jun:08:55 BigSpoon] ethernet and video cards
[30-Jun:08:56 jkh_] sam leffler raises the point that we may need sbus whether we want it or not
[30-Jun:08:56 bsdimp] need sbus for video
[30-Jun:08:56 awfulhak] need sbus for built-in NICs etc
[30-Jun:08:57 jkh_] greg lehey goes to a talk but leaves his laptop behind
[30-Jun:08:57 jkh_] attendees immediately set upon it and dissassemble it for spare parts
[30-Jun:08:57 missnglnk] yikes
*** [30-Jun:09:00] Joined #kernelsummit: julian (~julian@tserver.conference.usenix.org)
[30-Jun:09:00 nik] obrien arrives
[30-Jun:09:00 jkh_] obrien appears hung-over
[30-Jun:09:00 awfulhak] the room goes quiet - nothing to speak about now !!!
[30-Jun:09:00 bsdimp] ka-64
[30-Jun:09:01 jkh_] obrien is put on the spot
[30-Jun:09:01 jkh_] msobrien squi
[30-Jun:09:01 jkh_] whoops
[30-Jun:09:01 bsdimp] november
[30-Jun:09:01 bsdimp] gcc 3.0 into tree needed for ka-64
[30-Jun:09:01 bsdimp] maybe not in 5.0
[30-Jun:09:02 julian] but b=may need 3.0+ for ka-64 so that may not be in the tree.
[30-Jun:09:02 jkh_] to summarize, sparc and ppc will be single user mode by 5.0
[30-Jun:09:02 jkh_] obrien isn't sure about x86-64 though
[30-Jun:09:03 dfr] ia64 is already single-user (woohoo!)
[30-Jun:09:03 jkh_] bigspoon raises strongarm
[30-Jun:09:04 jkh_] michael raises the issue that netbsd doesn't support the SA1110
[30-Jun:09:04 jkh_] which is what he has hardware access to
[30-Jun:09:04] * wca yawns
[30-Jun:09:06 julian] http://people.freebsd.org/~jhb/summit/schedule.txt for those not here..
[30-Jun:09:06 wca] ...and silence falls over the crowd?
[30-Jun:09:06 wca] =P
[30-Jun:09:06 julian] jhk talking  (not intersting)
[30-Jun:09:06] * jkh_ kicks julian under the table
[30-Jun:09:07 julian] imp discusses which ARM machines might be good targets
[30-Jun:09:07 BigSpoon] the most likely arm target may be the ipaq
[30-Jun:09:08 BigSpoon] dfr suggests that we don't do arm unless someone wants to pay for it
[30-Jun:09:08 rwatson] BigSpoon: s/pay/use/
[30-Jun:09:09 dfr] money is always welcome
[30-Jun:09:09 BigSpoon] david talks about gcc 3.0
[30-Jun:09:09 julian] discussion movess to tool-chain
[30-Jun:09:09 BigSpoon] he wants it in 5.0 so we don't rip up C++ abi changes in 5.x-stable
[30-Jun:09:09 bsdimp] thank you osf
[30-Jun:09:09 wca] you guys sound like a bunch of baseball game announcers
[30-Jun:09:09 bsdimp] s/osf/fsf
[30-Jun:09:09 julian] David says that the C++ ABI has changed....
[30-Jun:09:09 julian] for gcc 3
[30-Jun:09:09 bsdimp] david compains about wrs
[30-Jun:09:09 BigSpoon] newer binutils imported now
[30-Jun:09:10 julian] reports that we have been running a new binutils
[30-Jun:09:10 BigSpoon] new binutils will support ia64
[30-Jun:09:10 julian] more commits coming
[30-Jun:09:10 BigSpoon] jkh asks about java support
[30-Jun:09:10 julian] jkh asks about gcc java suppport
[30-Jun:09:11 bsdimp] libjava
[30-Jun:09:11] * BigSpoon notes majoe schedule slippage
[30-Jun:09:11 bsdimp] kinda sorta works, but sucks.
[30-Jun:09:11 keichii_] BigSpoon : i think it is ok
[30-Jun:09:11 bsdimp] java support in 3.0 sucks, so says obrien
[30-Jun:09:12 jkh_] conclusion: raise this issue on the java mailing list and see how much interest there is in the current state of 3.0's java support
[30-Jun:09:12 julian] jkh and others point out that this is not kernel
[30-Jun:09:12 jkh_] we begin discussion of devd
[30-Jun:09:13 BigSpoon] imp will lead this discussino
[30-Jun:09:13 BigSpoon] lunch from 1 to 2 btw
[30-Jun:09:13] * jkh_ thwaps julian and notes that it was tangental to the gcc 3.0 import question
[30-Jun:09:13 BigSpoon] what is devd's scope?
[30-Jun:09:13 BigSpoon] should it manage devfs
[30-Jun:09:13 BigSpoon] should it be a policy manager
[30-Jun:09:14 BigSpoon] yesterday the consensus was that it should simply be a unified and genericied pccard + usbd
[30-Jun:09:14 BigSpoon] phk wants devd to require permissions to the kernel
[30-Jun:09:15 groggy] obrien notes hung over from bad jkh supplied pizza, not good beer.
[30-Jun:09:15 BigSpoon] h
[30-Jun:09:15 BigSpoon] groggy = obrien now
[30-Jun:09:15 BigSpoon] julian speaks from the devfs point of view
[30-Jun:09:16 groggy] obrien notes that bsdimp was alomost right, gcc 3._1_ is first gcc with basic ka64 support, not 3.0
*** [30-Jun:09:19] Joined #kernelsummit: jedgar (jedgar@peitho.fxp.org)
[30-Jun:09:20 wca] hallo jedgar
[30-Jun:09:21 BigSpoon] newcard sucks
[30-Jun:09:22 BigSpoon] as imp admits
[30-Jun:09:22 BigSpoon] and he has funding for devd
[30-Jun:09:22 julian] Summary: devd,though originally an idea from the devfs world, will eventually do a lot more than devfs stuff,
[30-Jun:09:23 BigSpoon] actually
[30-Jun:09:23 BigSpoon] it isnt' really related to devfs.. it's orthogonal
[30-Jun:09:23 julian] in fact most
[30-Jun:09:23 BigSpoon] it will work exactly the same without devfs
[30-Jun:09:23 julian] of the actions will be devfs indepentent..
[30-Jun:09:24 julian] it will be an 'event handler and translater'
*** [30-Jun:09:24] Joined #kernelsummit: deo (~obrien@tserver.conference.usenix.org)
[30-Jun:09:25 BigSpoon] it's actually mroe of a new-bus eventhandler
[30-Jun:09:25 BigSpoon] ether devices don't have /dev entries right now for example
[30-Jun:09:26 originat] more generic than just new-bus events, I'd like to be able to support events like overheat warnings etc
[30-Jun:09:26 julian] discussin on h what systems have hot-swap capability
[30-Jun:09:27 BigSpoon] originat: that's acpi stuff and will probably be part of a healthd
[30-Jun:09:28 BigSpoon] i'll raise that issue in a bit though
[30-Jun:09:30 BigSpoon] discussion mentions a devfsd
[30-Jun:09:30 BigSpoon] which would handle the devfs management things like phk are worried about
[30-Jun:09:30 BigSpoon] obrien gets preempted from grog's laptop
[30-Jun:09:30 dfr] groggy arrives..
[30-Jun:09:30 wca] hrmm, i thought you were on the 5th floor?
[30-Jun:09:30 wca] i just saw groggy here
[30-Jun:09:30 wca] on the 4th floor
[30-Jun:09:31 BigSpoon] jordan switches tapes
[30-Jun:09:31 julian] After a quick experiment, I confirm that DEVFS mounts can have independent ownerships and permissions for a device
[30-Jun:09:31 BigSpoon] groggy takes pictures
[30-Jun:09:32] * deo snuck awayfrom grogg's laptop when he closed xchat accidently and could not figure out the window manager...
[30-Jun:09:32] * deo whistles innocently.
[30-Jun:09:32 wca] 10.0.1.171:6667 after 2pm right?
[30-Jun:09:32 BigSpoon] wca: yes
[30-Jun:09:32 wca] forget it, i don't have my own wireless card anyways
[30-Jun:09:33 wca] and i have other plans anyways
[30-Jun:09:33] * BigSpoon notes the conversation wanders off to devfs in jails
[30-Jun:09:34 dfr] grog takes pictures for evidence..
[30-Jun:09:34 keichii_] Evil BSD Conspiracy
*** [30-Jun:09:34] Signoff: deo (bye)
[30-Jun:09:34] * wca notes wireless cards are due at 1pm for those who rented them
[30-Jun:09:34 wca] :(
[30-Jun:09:35 BigSpoon] wca: doh
*** [30-Jun:09:35] Joined #kernelsummit: kaworu (~ems@tserver.conference.usenix.org)
[30-Jun:09:35 wca] yeah
[30-Jun:09:35 wca] fuck that crap
*** [30-Jun:09:35] kaworu is now known as ems_
[30-Jun:09:35 ems_] hey
[30-Jun:09:36 wca] bigspoon: hope you don't have a rented one ;\
[30-Jun:09:36 wca] bigspoon: doubt you would buy a wavelan gold though ;p
[30-Jun:09:36] * jkh_ pats his integral wireless
[30-Jun:09:36 wca] yeah yeah your new titanium
[30-Jun:09:36 wca] how's the new job?
[30-Jun:09:36 jkh_] great so far
[30-Jun:09:36 wca] comfy? ;)
[30-Jun:09:37 jkh_] but then, I've only worked there 2 days before taking off. :)
[30-Jun:09:37 groggy] wca: I have a spare wireless card if you want to borrow it.
[30-Jun:09:37 jkh_] actually, I have a spare wireless card also
[30-Jun:09:37 wca] groggy: i think other people could use it more than me
[30-Jun:09:37 jkh_] but the network shuts down at 2pm
[30-Jun:09:37 jkh_] so it's not like you'll get much use
[30-Jun:09:37] * groggy smacks the notwork.
[30-Jun:09:37 julian] I discuss the 'device symlnk' method of avoiding having a devfs for every jail
*** [30-Jun:09:37] Joined #kernelsummit: fenestro (fenner@electricrain.com)
[30-Jun:09:37 wca] jkh: yeah, you can use ad-hoc
[30-Jun:09:37 wca] w/ 10.0.1.171 port 6667
[30-Jun:09:37 wca] not that there's much point
[30-Jun:09:38 jkh_] julian paints the bikeshed green
[30-Jun:09:38] * groggy wants external connectivity.
[30-Jun:09:38 wca] since most of the interested ppl would be in (what room are you in again?)
[30-Jun:09:38] * groggy sends out for yellow paint.
[30-Jun:09:38 wca] I could provide dialup. :P
[30-Jun:09:39] * groggy smacks pccardd.
[30-Jun:09:39 fenestro] picture of groggy taking pictures of everyone at the summit: http://people.freebsd.org/~fenner/groggy.jpg
[30-Jun:09:39 groggy] Grr.  It's not seeing my flash card.
[30-Jun:09:39 wca] hi bill fenner ;)
[30-Jun:09:39 fenestro] hi will andrews
[30-Jun:09:39 wca] 8)
[30-Jun:09:39 julian] discussion moves temporarily to JAIL stuff
[30-Jun:09:39 wca] again, where are you guys ?
[30-Jun:09:39 fenestro] Maine, on the 5th floor
[30-Jun:09:39 wca] you must be on the 4th floor ?
[30-Jun:09:40 wca] oh
[30-Jun:09:40 awfulhak] 5th
[30-Jun:09:40 BigSpoon] wca: 5th floor, maine room
[30-Jun:09:40 wca] hmm, kay
[30-Jun:09:40 groggy] wca: 5th floor.
[30-Jun:09:40 groggy] wca: You need to take the lift.
[30-Jun:09:40 BigSpoon] across the hall from new hampshire room that we were originally scheduled for
[30-Jun:09:40 wca] grog: i saw you pass by the laptop room and they announced your arrival not much later
[30-Jun:09:40 groggy] wca: Turn left when you come out of the lift.
[30-Jun:09:40 wca] okay
[30-Jun:09:40 wca] i've gotta eat lunch anyways
[30-Jun:09:40 ems_] has it started already?
[30-Jun:09:40] * groggy wonders if his laptop will freeze when he ejects the flash.
[30-Jun:09:40 groggy] Anybody else planning lunch?
[30-Jun:09:40 wca] ems: the summit started at 11am boston time
[30-Jun:09:41 ems_] ok, thanks
[30-Jun:09:41] * BigSpoon waits for devfs + jail wind down
[30-Jun:09:41] * groggy ejects his card.
[30-Jun:09:41 fenestro] we're vaguely following http://people.freebsd.org/~jhb/summit/schedule.txt
[30-Jun:09:41] * groggy smacks pccardd again.
*** [30-Jun:09:41] Signoff: groggy (rebooting--grrr)
[30-Jun:09:41 wca] i've been logging #kernelsummit since early friday
[30-Jun:09:41 wca] anyone who wants the log just send me a mail
[30-Jun:09:41 jkh_] lunch is scheduled for 1pm
[30-Jun:09:41 BigSpoon] wca: good
[30-Jun:09:42 jkh_] e.g. 15 minutes
[30-Jun:09:42 BigSpoon] anyone else logging the channel?
[30-Jun:09:42 tmm3] me.
[30-Jun:09:42 BigSpoon] yes, and we will be all offline when we get back from lunch :(
[30-Jun:09:42 BigSpoon] someone local will need to log the channel when we get back from lunch
[30-Jun:09:42] * jkh_ wonders how he's going to get through 5 hours of summit with 2 hours of tape
[30-Jun:09:42 wca] jkh: tape is cheap
[30-Jun:09:42 keichii_] jkh: go buy some real quick?
[30-Jun:09:42 fenestro] stop by circuit city on the way back from lunch?
[30-Jun:09:42 BigSpoon] jkh_: can you do the trick of downloading the tape to your local disk?
[30-Jun:09:42] * jkh_ plans a visit to circuit city
[30-Jun:09:43] * BigSpoon hands jkh a receipt to give to apple's expense people
[30-Jun:09:43 jkh_] spoon: yeah, that oo
[30-Jun:09:43 wca] ooh jkh has a DV cam?
[30-Jun:09:43 jkh_] erm, too
[30-Jun:09:43 wca] you have  DV cam?? :)
[30-Jun:09:43] * keichii_ ponders how to kill jkh for hardware
[30-Jun:09:43 jkh_] yeah, a Sony
[30-Jun:09:43 wca] cuz that would rule
[30-Jun:09:43 wca] kickass
[30-Jun:09:43 fenestro] and then you can burn DVDs of the meeting
[30-Jun:09:43 jkh_] it's filming all of us now
[30-Jun:09:43 BigSpoon] oooooo
[30-Jun:09:43 jkh_] fenestro: Yep!
[30-Jun:09:43 BigSpoon] dvd
[30-Jun:09:43 wca] do you know how much it cost or was it compliments of apple?
[30-Jun:09:43 jkh_] I have a DVD burner at work
[30-Jun:09:43] * BigSpoon will pay
[30-Jun:09:44 BigSpoon] jkh_: you suck
[30-Jun:09:44 jkh_] I think I paid $899 for it
[30-Jun:09:44 wca] hah
[30-Jun:09:44 wca] damn
[30-Jun:09:44 keichii_] i have a dvd-ram on my g4 too
[30-Jun:09:44 fenestro] shit, I thought I was kidding =)
[30-Jun:09:44 keichii_] it costs more to copy a DVD movie than to buy a DVD movie
[30-Jun:09:44 jkh_] keichii: intentional. :)
[30-Jun:09:44 BigSpoon] 10 minutes left
[30-Jun:09:45 wca] yeah
[30-Jun:09:45 keichii_] jkh: *nod*
[30-Jun:09:45 julian] discussion of device symlinks..
[30-Jun:09:45 wca] i hope you guys read your wireless agreements if you made one, because the cards are due
[30-Jun:09:45 julian] dg discusses variant symlinks.
[30-Jun:09:45 BigSpoon] wca: most of us have our own I think
[30-Jun:09:45] * jkh_ hopes that the camera's mic is sensitive enough to pick up everyone from the tripod
[30-Jun:09:46 wca] bigspoon: I still think it's noteworthy for others benefit
[30-Jun:09:46 bsdimp] jkh_: we should check at lunch if possible.
[30-Jun:09:46 jkh_] next conference we need a webcast mechanism and some microphones on the table
[30-Jun:09:46 wca] since those cards cost $300 to $400 apiece
[30-Jun:09:46 jkh_] then we can dispense with IRC
[30-Jun:09:46 wca] naw
[30-Jun:09:46 wca] no webcast needed ;P
[30-Jun:09:46 ems_] Heh, those aironets aren't very good, I got a Lucent WaveLan GOLD on ebay for $100
[30-Jun:09:46 fenestro] and no laptops on the cable cuz otherwise the mics will only pick up typing
*** [30-Jun:09:46] Joined #kernelsummit: groggy (~grog@tserver.conference.usenix.org)
[30-Jun:09:47 wca] fenestro: good point
[30-Jun:09:47 jkh_] fenestro: man, I can just hear the howls now. :)
[30-Jun:09:48 fenestro] haha
[30-Jun:09:48 julian] discussion of device symlinks to avoid having millions of device filesystems mounted in millions
[30-Jun:09:49 julian] of jails
[30-Jun:09:49 julian] devd would take events from devfs to configure these if needed (as per phk doc)
[30-Jun:09:49 wca] great
[30-Jun:09:50 wca] heh
[30-Jun:09:50 wca] well my external client will remain logging as long as you guys are here
[30-Jun:09:50] * groggy points at http://www.lemis.com/grog/Photos/20010630/
[30-Jun:09:50 groggy] Things are still copying.
[30-Jun:09:51 bsdimp] forbidden!
*** [30-Jun:09:52] Left #kernelsummit: originat (~paul@tserver.conference.usenix.org)
[30-Jun:09:53 BigSpoon] grr
[30-Jun:09:53 bsdimp] chaos
[30-Jun:09:53 bsdimp] three conversations
[30-Jun:09:53 BigSpoon] lunchtime
[30-Jun:09:53] * jkh_ thinks this would be a fine fine time to break for lunch
[30-Jun:09:53 bsdimp] we won't have network after lunch
[30-Jun:09:54 bsdimp] and we're about to break.
[30-Jun:09:54 BigSpoon] yes
[30-Jun:09:54] * groggy messes with permissions on www.lemis.com.
[30-Jun:09:54 groggy] jkh_: A greed.
[30-Jun:09:54 fenestro] and don't forget http://people.freebsd.org/~fenner/groggy.jpg
[30-Jun:09:54 wca] heh
[30-Jun:09:55 wca] jkh: going to post your pics sometime?
[30-Jun:09:55 julian] suggewtion that we get back to architecture....
[30-Jun:09:56 BigSpoon] Forbidden
[30-Jun:09:56 BigSpoon] You don't have permission to access /grog/Photos/20010630/ on this server.
[30-Jun:09:56] * BigSpoon notes exodus routing is screwed up causing dns problems on hub
[30-Jun:09:56] * groggy rubs BigSpoon's nose in the transcript.
[30-Jun:09:56 wca] exodus->crap == true;
[30-Jun:09:56 groggy] BigSpoon: I think it wants an index.html.  I'm writing it.
[30-Jun:09:56 BigSpoon] I just tried it
[30-Jun:09:57 wca] bye
[30-Jun:09:57 BigSpoon] oh
[30-Jun:09:57 fenestro] just because you messed with them doesn't mean they're right =)
*** [30-Jun:09:57] Signoff: ems_ (Remote closed the connection)
[30-Jun:09:57 BigSpoon] someone logging this?
[30-Jun:09:57 BigSpoon] now that wca is leaving?
[30-Jun:09:57 groggy] BigSpoon: I've got most of it, except when I rebooted.
[30-Jun:09:57 BigSpoon] good
[30-Jun:09:57 BigSpoon] I can't get my braindead client to log
[30-Jun:09:58 BigSpoon] *sigh*
[30-Jun:09:58 nik] BigSpoon: I've got the whole thing logged.
[30-Jun:09:58 bsdimp] I can save the logs from xchat
[30-Jun:09:59 BigSpoon] cool
*** [30-Jun:09:59] Joined #kernelsummit: Holocaine (benno@CPE-61-9-137-172.vic.bigpond.net.au)
[30-Jun:09:59 groggy] Holocaine!
[30-Jun:09:59 groggy] Holocaine: Where were we when we needed you?
[30-Jun:09:59 Holocaine] Hey groggy =)
[30-Jun:09:59 Holocaine] groggy: ?
[30-Jun:09:59] * keichii_ kicks Holocaine 
[30-Jun:09:59 BigSpoon] Benno!
[30-Jun:09:59 BigSpoon] can you give a quick status report and roadmap for ppc?
[30-Jun:10:00 Holocaine] BigSpoon: sure.
[30-Jun:10:00 Holocaine] BigSpoon: now?
[30-Jun:10:00 BigSpoon] yes
[30-Jun:10:00 keichii_] NOW
[30-Jun:10:00 nik] Holocaine: Ye
[30-Jun:10:00 bsdimp] am I lagged?
[30-Jun:10:00 Holocaine] Ok.
[30-Jun:10:00 Holocaine] Current status is that I'm starting work on the device tree.
[30-Jun:10:00 keichii_] did you?
[30-Jun:10:00] * groggy points at http://www.lemis.com/grog/Photos/20010630/, now loadable.
[30-Jun:10:00 Holocaine] I've got a rudimentary nexus happening and I'm playing with PIC drivers.
[30-Jun:10:00 keichii_] you've been busy while i've been drinking eh?
[30-Jun:10:01 keichii_] do you have JTAG yet?
[30-Jun:10:01 Holocaine] I've got the OpenPIC in my iMac initialising.
[30-Jun:10:01 Holocaine] keichii_: Nope.
[30-Jun:10:01 dfr] lunch!
[30-Jun:10:01 Holocaine] I'm hoping to start groping around for PCI busses in the near future.
[30-Jun:10:01 keichii_] i just committed us to target single user mode for 5.0-C
[30-Jun:10:01 keichii_] Holocaine the groper
[30-Jun:10:01 Holocaine] keichii_: I'm hoping to meet that.
[30-Jun:10:02 Holocaine] What time is it there?
[30-Jun:10:02 keichii_] 12 noon
[30-Jun:10:02 keichii_] we are about to leave for lunch
[30-Jun:10:02 Holocaine] Ah, I was an hour out in my calculations.
[30-Jun:10:02 Holocaine] Damn.
[30-Jun:10:02] * Holocaine should've set his alarm for 2am.
[30-Jun:10:02 BigSpoon] that's ok
*** [30-Jun:10:03] Signoff: dfr (using sirc version 2.211+4KSIRC/1.1)
[30-Jun:10:03 Holocaine] BigSpoon: Anything else people want to ask about PowerPC or shall we hold off until after lunch?
[30-Jun:10:03 BigSpoon] we won't be around after lunch
[30-Jun:10:03 BigSpoon] usenix pulls the plug at 2
[30-Jun:10:04 Holocaine] BigSpoon: Ah, damn.
[30-Jun:10:04 Holocaine] BigSpoon: You mean I got up for nothing? =)
*** [30-Jun:10:05] Signoff: fenestro (au revoir)
[30-Jun:10:05 bsdimp] hoho magic
[30-Jun:10:06 keichii_] Holocaine : yes
[30-Jun:10:06 Holocaine] Damn.
[30-Jun:10:06 groggy] Holocaine: I think you were two hours out.
[30-Jun:10:07 Holocaine] groggy: Gawd.  I did really well then.
[30-Jun:10:07 Holocaine] Oh well, I'll know better next time. =P
[30-Jun:10:08 Holocaine] That's weird.  I originally calculated 1am, then decided I was wrong and thought 3am.  I was right the first time
[30-Jun:10:10 groggy] Holocaine: date(1) is your friend.
[30-Jun:10:10 Holocaine] groggy: I was using zdump.
[30-Jun:10:11 groggy] === grog@sydney (/dev/ttyp5) ~/Photos/20010630 5 -> TZ=Australia/Melbourne date
[30-Jun:10:11 groggy] Sun Jul  1 03:11:01 EST 2001
[30-Jun:10:11 groggy] === grog@sydney (/dev/ttyp5) ~/Photos/20010630 6 -> TZ=America/New_York date
[30-Jun:10:11 groggy] Sat Jun 30 13:11:03 EDT 2001
[30-Jun:10:11 groggy] keichii_: You're still on Austin time.
[30-Jun:10:11 Holocaine] groggy: Yeah, I'd done the zdump on Friday and must've got turned about.
[30-Jun:10:11 keichii_] groggy : well...
[30-Jun:10:12 Holocaine] Oh well, back to bed I guess.
*** [30-Jun:10:12] Signoff: rwatson (unch)
[30-Jun:10:12 bsdimp] Time to leave.
*** [30-Jun:10:12] Signoff: Holocaine (Client Exiting)
*** [30-Jun:10:13] Left #kernelsummit: jedgar (jedgar@peitho.fxp.org)
*** [30-Jun:10:18] Signoff: bsdimp (Client Exiting)
*** [30-Jun:10:19] Signoff: BigSpoon (lunch)
[30-Jun:10:21] * awfulhak is away: I'm busy
[30-Jun:10:21] * awfulhak is back (gone 00:00:05)
[30-Jun:10:21] * awfulhak is away: at lunch
[30-Jun:10:25 julian] Everyone goes to lunch
[30-Jun:10:25 julian] any live people still here?
[30-Jun:10:25 julian] (I'm room-watching)
[30-Jun:10:25 julian] nope?
[30-Jun:10:42 gjvc] hey julian
*** [30-Jun:10:48] Signoff: gjvc (b00m)
*** [30-Jun:10:52] Signoff: jkh_ (Ping timeout: 240 seconds)
*** [30-Jun:10:57] Signoff: julian (Ping timeout: 240 seconds)
[30-Jun:11:03 nik] obrien arrives
[30-Jun:11:04 tmm3] nik: The network is still up?
[30-Jun:11:04 nik] yes apparently..
*** [30-Jun:11:08] Joined #kernelsummit: winter_ (winter@sasami.jurai.net)
[30-Jun:11:09] * tmm3 suspects that it would be a little too much to hope for it staying up another 3 hours ;)
*** [30-Jun:11:13] Signoff: awfulhak (Ping timeout: 240 seconds)
*** [30-Jun:11:13] Signoff: keichii_ (Ping timeout: 240 seconds)
*** [30-Jun:11:15] Signoff: groggy (Ping timeout: 360 seconds)
*** [30-Jun:11:15] Signoff: nik (Ping timeout: 360 seconds)
[30-Jun:11:18 tmm3] Bah. So much for that.