Kernel Summit - Usenix 2001
The first FreeBSD kernel summit meeting was held June 29-30, 2001 in Boston, MA at the Usenix 2001 Annual Technical Conference. Included below are links to various files related to this event.
Note: I (jhb) am still working on writing up a general summary of the meeting. When that is completed it will be posted here and mailed to the -hackers mailing list.
Documents:
When:
-----
Friday, June 29 from 5pm to 11pm and Saturday, June 30 from 8am to 5pm.
Where:
------
The New Hampshire Room on the 5th floor at the Marriott Copley.
What:
-----
An architectural discussion focusing primarly on the FreeBSD kernel.
New ideas for the future will be addressed, as well as plans for the
upcoming 5.0 release.
Topics:
------
o devd: a daemon for managing device events from userland
- Handling dynamic insertion/removal events
- Should it handle non-removable devices as a base case to centralize
device management?
- What events should it handle?
o 5.0: release engineering and schedule
- When should the release be?
- When should efforts change from writing new code to fixing what
we have?
- What minimum requirements do we want in the new code before we
shift to rock polishing?
o SMPng: strategies for locking major subsystems
- Networking stack
- VM
- VFS
- TTY
- BUF/BIO
- CAM
- Locking guidelines
o KSE
- What about NetBSD's work?
- What is missing from Jason's paper?
- Do we want it in 5.0 or 6.0?
o DRM
- should we import it into the tree?
o Architecture Ports
- Roadmaps and status for each port under development
- PowerPC
- IA-64
- KA-64
- Sparc v9 (aka Sparc64)
- Arm
- Toolchain issues (gcc 3.0)
Other Notes
-----------
- Should be videotaped for those who cannot be present.
- Another one should be planned for BSDCon.
- Assuming that we can get a network connection at the meeting room, the
#kernelsummit IRC channel on the EFNet network will contain a running
commentary of the meeting as well as take questions from those not
physically present.
Saturday, June 30 10:30am to 11:00 - Meet at the room. 11:00 to 11:55 - Platforms/Architectures - 5 minutes on each architecture: status and roadmap - PowerPC (Benno Rice) - IA-64 (dfr) - KA-64 (obrien) - sparc64 (jake) - arm? - 10 minutes for toolchain roadmap (obrien) - 20 minutes for questions / buffer 11:55 to 12:00 - Break 12:00pm to 12:55 - devd - devd as an event notification facility - devd as a policy enforcer ? - devd as an event filterer/forwarder 12:55 to 2:00 - Lunch 2:00 to 2:55 - 5.0 release schedule and goals - What requirements do we want in 5.0 release - devd - SMP 2:55 to 3:00 - Break 3:00 to 3:55 - KSE - Short term: continuation inverse-rfork threads (peter) - Long term: (julian) 4:00 to 4:55 - SMP - Proc locking - Networking stack - Q&A 4:55 to 5:00 - Get kicked out of the room
Saturday June 30 2001
FreeBSD Meeting @ USENIX
Matthew Dillon Transcribing in real time
Jordan/Greg Filming
10:30 - 11:00 meeting
11:00 - 12:00 devd (imp)
12:00 - 1:00 lunch (jordan)
+--------+
| COFFEE |
+--------+
(10A)(11) (12) (13) (14) (15) (16) (17) (18) (19) (20)
+-------------------------------------------------------+
+------+| | +-------+
|CAMERA|| TABLE | | WHITE |
+------+| | | BOARD |
+-------------------------------------------------------+ +-------+
(10) (9) (8) (7) (6) (5) (4) (3) (2) (1)
Role: (duplicate numbers: chair insertions)
(1) David O'Brian
(2) Nik Clayton
(3) Matt Dillon
(4) Julian Elischer
(5) D P Richards
(6) Andrew Gallatin
(6) Mike Smith
(7) David Greenman
(8) Jordan Hubbard
(9) Jake Burkelholder
(10) Bill Fenner
(10) Evan Sarmiento
(10A) Garance Drosehn
(11) Sam Leiffler
(12) Dan Eishlan
(13) Michael Wu
(14) Doug Rabson
(15) John Baldwin
(16) Brian Somers
(17) Warner Losh
(18) Peter Wemm
(19) Robert Watson
(20) Daniel Eischen
(??) Greg Lehey (floating / in and out)
WARNING WARNING WARNING! This is not an exact transcription, since it
was in real time. I only got about half of it down and couldn't always
type quickly enough to stay caught up. There are almost certainly
type-o's and mis-attributions (since editing in real time is rather,
well, impossible). See the video for the real deal. This should give
you a flavor of the meeting, though.
-Matt
-- Power PC (Mike & Benno. Benno not here)
DEVD / John. Talking about other processors. Mike: Benno said he
got open firmware and nexus working and we're having trouble in that
we don't really have a serial port... may try to implement ddb over
ethernet (netbsd already has one). It would be a simple pipe device
that pipes all the crap out the interface into the ip network. Once
we get past the boot loader I think we are home free. pmap is almost
done. locore is half done. Might make it to single user by 5.0. The
goal is to support as many platforms as possible. IMac, PowerBook, G4,
Titaniums, perhaps some of the embedded platforms (e.g. 7410?sp).
Robert Watson: what about ABI selection for power pcs? There are
several. Mike: We are using the embedded ABI at the moment. Might
switch later on... depends on the bike shed. Robert: when does the
ABI decision have to be made? Mike: When we boot into single user.
Every time I talk to Bento he's made progress.
Some talk about mounting filesystems between IA32 and PPC and NetBSD's
work. Peter: no point in running a local disk on its native platform
in anything other then its native byte order if it's never going to
move. (Peter's concern is in regards to overhead). (bikeshed?)
Mike: Knows people running UFS on DVD-RAM. Mike/Peter: Maybe a mount
option? A compile-time option? Bill Fenner: NextStep used big-endian
for all their filesystems, didn't bother with 80386 (no byte swap
instruction), but everything else...
Bill Fenner: choose at newfs time. Mike: agrees. .. lots more people
start chiming in, talking about other architectures (Solaris on Sparc,
ROM loaders, removable media, and so forth). Warner: we should table
this for now. Back to mike: Jordan asks: What are your role out plans?
Mike: PowerBook, G4 to begin with, then perhaps get into the embedded
platforms. Jordan asks how far they'll get: Mike/John: single user by
5.0.
G4 suppor for SMP. John: The way the kernel is now, support for SMP
is fairly easy. Jordan: Apple isn't charging much more for duel cpu
boxes. (Consensus: should be fairly easy).
-- IA64 (Doug Rabson)
Doug: IA64. Kernel to single user mode. Signal delivery appears to work.
There are some things we need to address in the kernel in regards to
the fact that we have two stacks. IA64 has an upward-growing register
stack in addition to the normal stack. I have a hack in exec that maps
a few pages, sets the register, etc... The register stack tends to be
smaller then the regular stack (arguments, registerized variables, etc..).
128 register set with a lazy save to memory, rolling window. DG: questions
about register allocation. Doug: register growth is open-ended. So, in
anycase, for IA64 we need a second stack that grows upwards.
Matt chimes in (oh no!): for user mode register stack, just mmap()
a large virtual area. DG agrees, that would work... have to decide how
much. Doug: userstack - 2 * maxstack. Doug: 64 bit address space broken
up into 61 bit regions, no problem in regards to available VM.
(timeout for Greg Lehey to setup Tripod for Jordan's VC).
Doug: Next goal is to run on real hardware rather then simulated
hardware. The first step of that is to get the loader working. I
have real code compiled that actually runs on real hardware.... Got to
the stage where I have to debug setjmp and longjmp, and after that it
should be fairly easy to bring up a real kernel. It's got serial ports
which should be fairly easy to use. Jordan: Do you have access to a
real machine? Doug: Yes. It even has firmware support for loading
stuff over TFTP. That's just about it.. oh, there are tool chain
issues, I'm using an old tool chain at the moment. Once we have enough
toolchain in our action tree then we will consider cross building a real
userland after bringing the kernel up single user. I expect it to get
to single user mode on real hardware by the 5.0 release date.
Mike: question. In this SMP for ISD4. When you have two processors it
really becomes an ACPU machine due to the cpu threading. Mike: thinks
it might be a good idea to plan ahead, there are going to be issues
with many more cpu's. Robert Watson: too soon. Greg Lehey: There are
some IBM systems with 64 cpus and I've been asked to look into
scaleability issues in this area. Warner: how serious are they? Are
they expecting an "oh this sucks" short report? Greg: They are a little
more series then that. They would like to bring it up on at least 32
cpus. (Additional talk). Robert: Regardless of that, I think fairly
fine-grained locking is the strategy for that. Greg: general agreement.
It will be suboptimal, but more optimal then a badly thought out
mid-level locking. Peter: break break.
Greg: Benno is still working his way to single user mode. He's got an
initial print out of the probe messages and working forwards (PPC32).
Question as to whether to port NetBSD or FreeBSD first, neither runs
on PPC64. It might be better to get NetBSD to boot first, then carry
that forwards into FreeBSD. This is not going to be my (Greg) prime
occupation. If anyone wants access to the machine after we've gotten
it basically working on the net, I can arrange limited access (due to
IBM security issues). Contact me. This is the 2-cpu PPC machine, not
the 32-cpu PPC machine.
Greg has to leave. Banter about where Greg is located now (Australia).
-- SPARC 64
Jake: Sparc64. Running into filesystem issues trying to mount a little
endian filesystem on a big endian machine. Will definitely have it
running in single user by 5.0. Architecture is very similar to IA32.
The stack works the same. The window registers do not change things that
much. Will mainly support PCI devices, will probably not try to get
SBUS working in the near term. Low end ultras are all PCI, no big
need for SBUS at the moment. I also have access to an 8 processor
box.
Video cards may be an issue... on the larger boxes they are SBUS
devices. Console may be an issue (serial ports brought up as an
alternate). Doug: NetBSD found issues with big-endian boxes. Jake/Doug:
Yes, there were alignment issues and stuff. We just have structures
for system call arguments, with appropriate padding. NetBSD has a
special syscall arg macro. Our structures should be easier to port.
Jake: The firmware has various nice things. It will load an ELF binary and
it has TFTP support. Jake: Right now I am booting over the network. I
have a little loader, not a real loader. (How far do you boot?) It gets
to the point where it mounts the root filesystem. Someone at NetBSD put
together a big-endian filesystem and it got past the magic number issue.
Jake/Jordan/Warner. Warner: I can mount a NetBSD filesystem on FreeBSD
if the endian is the same.
(David O'Brian Enters)
John: What is the current status of (Sparc, PowerPC?). O'Brian:
It will happen by november. Once we get single user I don't see
multi-user as being a big deal. It is predicated on getting GCC 3.0
in the tree and may require a newer version then the GCC going into
our tree. We might have to wait until 5.1... at the moment it requires
all sorts of external packages. (...). Note that the hardware will not
be out by 5.0, and a similuator would cost around $15K.
John: What about StrongArm? Mike: I do have the boards SA1110. David:
I'm trying to get a mailing list going. Mike: I'm booting linux on it
but I am splitting my time between PPC and StrongArm. (Jordan: Gary
Palmer was working on StrongArm. O'Brian: I think that was pre-Strong
ARM). (More talk about which particular strongarm platform we should
go for first?). Jordan: suggestion to target first... the reference board
is fine, but FreeBSD's mandate essentially says that we should be running
on commodity hardware. G4, IPAC, HPCMIPS?sp, etc etc... we need to use
commodity hardware as our reference platform. Warner: NetBSD does a good
job running on all available boards as well as commodity hardware. It
creates an issue where they have a lot of essentially similar ports.
The commercially available ARM machines are the IPAC. HP jurnatas.
(Suggestion from O'Brian: goto slashdot and look at those new StrongArm
cube things).
John: Any more talk about toolchain issues? O'Brian: What is there
to say? Jordan: How about talk about GCC 3.0. O'Brian: GCC-3.0 must
be in 5.0 in my opinion, otherwise we will have to rip C++ ABIs out from
under everyone. I thought this might be the last one but 3.1 might be
the last one. I expect to seriously start work on the integration on the
first of august, due to windriver activities slowing me down.
binutils2.11.2 was imported this morning, though there may be some issues
with it (I got a bug report on it).
Jordan: What about the java suppor for GCC-3.0? O'Brian: are you just
curious or do you want to actually import that? Jordan: A lot of people
are interested in it. O'Brian: It is a native compiler so you do not
have to bring over the byte code or the AWT. Because of that it is
rather limited right now in terms of what you can do. They are still
trying to get libjava to present a virtual machine to the java code.
The fact that you can't just take .class files around... I don't know
the usefullness of it by itself. libjava does not compile on all platforms
yet, so... Jordan: Should we hold off? Import it later? O'Brian: I
don't know if we ever should. People were talking about porting Sun
Java 2.x...
John: lunch break now or at 1:00 p.m. (it is now 12:00)
-- DEVD
John moderating. DevD.
Warner: Summary of what we talked about yesterday. What is devd.
We talked
about do we want it to be our security policy enforcement manager? Do
we want to just have it handle events? What? The scope we came up with
is that it is a replacement for pccardd and usbd. It listens for a
particular device in the kernel (device arrived, device left, etc...)
(PHK wants it to listen to dev filesystem requests too). Long discussion
about whether it should be used for permissions persistence or policy
agent. Concensus: Sounds cool, but when it comes down to it there are
races, consistency issues (what if devd dies?). Worried about the concept
of the kernel upcalling a userlevel daemon.
Additional talk about the kernel relying on userland daemons. aka vinum.
Kernel events relying on user operations sound very dangerous (from
various people). Julian: Poul was seeing the same things I was seeing.
There are a number of times where the user community is demanding that
they want to be able to taylor a filesystem in various ways. XXX.
Robert: Might want to feed things into devfs before devfs exposes things to
userland. Looking at devd more as an event manager rather then in devfs.
Appearance of the device in the filesystem has more to do with the
presentation of the device to userland and less to do with how it is
perceived by newbus. (more talk back and forth). DG: exactly what role
is devd to play when some other process does a stat or something like
that? (answer: no, no). DevD purely as an event manager to take other
actions, such as load the kernel module associated with a new device
found by the kernel.
Example in the tree. You plug a card into newcard but newcard has no way
to configure it (e.g. no pccardd around)... devd would be responsible
for that. (Now everyone is chiming in with examples).
Andrew: Stateless or statefull? Answer: Robert: Stateless.
Doug: What about automounting filesystems? Warner/Robert: Yes, devd
would do that. Robert: devd would be able to act on the class of the
device as well as the particular brand of the device. Peter: e.g.
this is an ethernet device (generic).
DG: do we have to get this thing all singing and dancing before it
would be useable? Julian: I think it can be done piecemeal, on a
class by class basis. Warner: My view is that putting a few event
types into a devdev/kernel-queue for devd would be very easy. We put
that in, write the program, and maybe initially all it does is string
lookups and such. Warner: That is what USBD does now, it just looks
things up based on regex matches. Doug: A medium term goal would be
to have DevD recognize soft eject pccard switches. Robert: A lot of
PCs have soft-eject mechanisms now. (lots more talk about soft
notification and soft eject mechanisms). Peter: example, CD ejects,
devd could detect that the user is hitting the eject button on a locked
drive and could then unmount the CD and allow the ejection.
Mike: hot swap PCI cards too. Warner: the hotswap compaq PCI spec is
a user-initiated power down, the led goes from green to red and the
user then pulls the card out. The O.S. is cooperative in this regard.
There is no standard way to do it yet, it is chipset specific. It is
the PCCard bridge situation all over again. DG: I've only seen one Intel
platform with hot swappable PCI. (others: The DELL 4400 (?sp)). Peter
chimes in. Warner chimes in.
Warner: The Strawman proposal we came up last night for devd was
basically just getting events from the kernel and doing stuff. It
would not be the gatekeeper for device permissions. Decided for
a strawman that devices always appear, and you could see the device,
but you may not be able to open it. DG: What about chroot situation?
Robert: If you mount devfs in a chrooted filesystem it will have all
the devices as in the root filesystem. (More talk, can you change
permissions on separately mounted devfs filesystems? Nobody is entirely
sure).
DG: How will devd know about all these other devfs mounts? Robert:
at the moment we think the best way to do it is in the mount options
for devfs. Robert: note that jails in 5.x are different then 4.x. The
jail info is stored in the ucred, not the process structure, and devd
can work with it. (general conversion is that jail/chroot/multiple-mounts
should be a property of devfs, not devd).
Julian: I've actually solved this problem for my device filesystem. It
is generally applicable. You implement a version of a symlink that instead
of being a normal symlink it is instead a symlink into the device space.
You basically give it the name into the prototype device filesystem space
that you want it to be a link to. The code that follows this does it
above the.. before you get down into the VFS, so you are not following
a major/minor number. Access is by name. Warner: Another way of saying
that is that jailed devfs's come up empty? Julian: No, the jails would
not have devfs mounts at all, they would contain these special symlinks.
Warner: you can create the symlinks before the devices exist? Answer: yes,
it is by name. DG: what about new devices. Julian: devd could add them.
Matt: devd shouldn't have to mess around with a random number of devfs
mounts. Warner: the symlink suggestion by Julian seems to solve the
problem (paraphrased). (More talk).
Warner: it sounds like we have a rough concensus around the varient
symlink idea. Julian (some stuff). Warner: what about setting
permissions? DG: symlink permissions do not mean anything at the
moment. Julian: It would be fixable. Robert: I just want to make
sure we can adjust device permissions within jails. (Robert generally
agrees). DG: The obvious thing to do would be to implement something
even more grand, such as implement real varient symlinks. (More talk
about devd and these symlinks and who creates and maintains them).
DG: what I was suggesting here is that I understand the goal is different
from general varient symlinks. The idea being that you have a target
symlink and want to do some sort of translation on the path, such as
an environment translation. Robert: AFS does something like this.
Matt: Didn't VMS do something like that? DG: answers (lost).
DG: the idea is to have some sort of general translation mechanism.
They are different things, I agree, but I think we could use this
mechanism to do both. Robert: We need a protection step here. DG:
I think the permissions thing is a separate issues. I don't see why
we can't enforce symlink permissions inside jails and not outside
jails (at the moment they are not imposed anywhere). Warner: I like
that idea. Bill Fenner chimes in. DG: Kirk is going to hate this.
Apparently there is some draft specification that says symlinks do not
have permissions associated with them. Julian: I ran this past Kirk
a year and a half ago and he seemed to think it was a good idea. DG:
I'm not saying we have to follow some arbitrary standard that someone
else had designed. Historically symlinks had permissions, then Kirk
took them away, then we and NetBSD added them back. Now Kirk says it
seemed like a good idea at the time but was a mistake. (Confusion over
what permissions are being enforced... just the owner/group? Or modes
too?). (more talk). Peter: 4.4-lite went back to the inode to store
symlink information.
Warner: you setup the jail once to make the nodes. Robert: This breaks
us away from the major/minor stuff. (Julian agrees and gives an example).
DG: This brings up an interesting security issue in regards to what we
allow people to create inside jails (General agreement). DG: perhaps
we should separate the varient symlink from the device node symlink
types.... (too many people talking now).
Talk moves to which physical inode device type should be used...
character device? Some other device type? What?
(pause to talk about exodus routing problems)
(more talk about how to implement the special symlink). Robert Watson:
use the major/minor -1,-1 to indicate additional content. David O'Brian:
power pc development depends on traditional NFS device exports
(paraphrased). Robert Watson: If we were to overload the block device
node and add indirect blocks to it, would the filesystem BOF on it?
DG: well, we could fix that. (Matt comment: the easiest tie-in to the
kernel is to subtype softlinks).
John: Lets go to IRC for a quick PPC update, and then break for lunch.
(More banter, getting ready for lunch, talking about the NASD failure)
(Waiting for Jordan)
LUNCH LUNCH LUNCH
LUNCH LUNCH LUNCH
(return from lunch 2:50 p.m.)
(times off from original sched)
?:?? - ?:?? ports (obrien, jake?)
?:?? - ?:?? 5.0 (jordan)
?:?? - ?:?? KSE (peter, julian)
?:?? - ?:?? SMP (jhb, jake?)
-- 5.0
The reason for setting the deadline as it is (in November), is because
December already has a 4.x release in it. We loosely said we'd do a
-current release this year, so that leaves november pretty much. For
5.0 there isn't much point adding slippage since 5.0 is not expected
to be production (paraphrased). We need to get the 5.0 release out to
a wider group of testers. Whether we like it or not, that should be
helpful.
Warner: with the pccard changes I've made, I've gotten more comments
from people running on stable then on current.
Jordan: Perception-wise a lot of dirty has been flying on -current.
Peter: we scared them away on purpose to a degree (paraphrased)
Jordan: 5.0 is a symbolic declaration. Time to get the user community
crunching on it. (more discussion).
Jordan: No branch will occur at 5.0. Well, like I say, this is the
more important question. .0 is more like a symbolic act. Once people
orient themselves around it we need to decide how much time we need to
really really make it work so we are not spending all kinds of time doing
work in two branches, because that kind of sucks we've done that before.
So my feeling is maybe as late as 5.2.
Peter: I think the real thing is I should make sure it is in a fit state
to be branched or in a fit state is able to be branch without... just
basically so we do not do it too early so we do not spend too long
catching up. Once 5.0 comes out there's going to be a massive amount
of work.
Jordan: what is fit. I would define that from an engineering perspective
that we fixed all the significant problems we know about, ... and that
things are fixed to the best of our ability. And to me that means somewhere
after 5.1... that is when people are going to really start arriving
(using -current).
Peter: my gut feeling is that 5.0 is going to break a lot of stuff. 5.1
is going to be our chance to get the really big stuff fix, which will
get a lot more people on, and then we can tune stuff and that will get
us into good shape to branch around 5.2
Warner: that sounds good. The big thing we learned about 3.0 is that
we branched a little early, because Matt (and others) wanted to push
things (VM) into 3.0 that really belonged in 4.0.
Robert: does that mean we are going to freeze active development for
a few months? Jordan: Possibly for as long as a year. If we get something
that requires really significant architecting, then perhaps we can create
a sub-branch for it. BSDOS put all their merge stuff on a branch and it
was really stable.
D P Richards: what about pushing down the locks, does that count in
the freeze. Jordan: That is 'finishing it' (i.e. does not apply to the
freeze). Peter: We will have to be doing that continuously.
(additional talking back and forth).
Jordan: you are wondering if people should track the branch or whether
they should take the releases (talking about current here). Robert:
there is a point in time after a release where we will be doing a huge
amount of work (paraphrased). Peter: (agrees). Jordan (agrees).
Jordan: cvsup will be dangerous, but we will be able to do point releases.
Peter: I personally think we should get the bulk of anticipated API
changes done by 5.0, so we do not have a lot of turmoil.
Matt: are your point releases going to be tagged, or ad-hoc? Jordan:
yes, they will be tagged.
Warner: when will we know we will be ready by 5.1. (Jordan answer
is substantially the same as in prior discussions).
(?): What about GNATS. Mike Smith: GNATS will not be very useful
considering how quickly -current is going (paraphrased). The cut
feeling reaction is that we will do 5.0, there will be some really
big fires, and by the time those fires are out people will probably
generate lots of PRs. Jordan: We should maintain a web page, I
don't think the PRs will solve the problem. Robert: GNATS has a number
of problems. Jordan: (lists a number of problems with GNATS).
Warner: Bugzilla makes it easier to manage... I have bugzilla at work
and going through the bug reports is trivial.
Jordan: (more comments about the PR system).
Matt: we need an auto-assignment thing for PR's
Warner: For Core and the security officer we need incident tracking
Jordan: Lets take this off to a corner (offline). What we should do is
migrate things from GNATS into the (undescribed future) system,
and so forth...
Mike: For the japanese people who do not speak english, can we have a
separate bug reporting system for them (that's coordinated) (sorry,
too much talking, missed the rest). Warner: Mechanical translation
is not really an option. (...)
Robert: there was a suggestion of projects.freebsd.org, a php-based
web system to track projects (e.g. like devd), but nobody appears to have
time at the moment (paraphrased). There are a lot of issues and nobody
has picked up the ball. There are a lot of logistical issues like bringing
the service online. Mike: The issue is that we need a dedicated maintainer
or it will rot.
(Jake enters the room)
Jordan: any other questions?
Nik: On 5.0 will we have a release engineering team? Jordan: The
release engineering will pretty much work the same way it has been
revolving. David O'Brien has been doing stuff, Paul has been doing stuff,
Murrey has been doing stuff, etc. (More talk re: project releases).
What the project should commit to doing is put is 5 ISO images, a small
release-only bits (200MB or so) for making miniCD's, putting it in
flash, etc. We have the four ISO images (picking 4 out of my ass)
which is the release, some packages, (interruptions for discussion,
list cutoff). Jordan: In addition to those 5 ISO images and the FTP
dist. I think we should also make a pointer (disk space constrained)
for all the disk files, all the packages, etc. etc... all on one system,
so When you have a release you have a whole chunk of data. Good
reference bits so you have a starting point. A definitive packet set.
etc.. and what the ISVs want to do after that is up to them. We
expect them to add additional value (such as package it all up on a
DVD, for example). Nik: should sysinstall be able to handle extra
components. So if a third party etc... want to put together a value-add
distribution... What should we define as the 'bare minimum' for an
ISV to be able to call the distribution FreeBSD?
Julian interrupts: what does this have to do with kernels?
(talk fest slows down, Jordan gets in a last word.. oops, no warner
gets in a last word). In the past WCCDROM has had an exclusive for the
'official' FreeBSD dist, what do we do about that? Jordan: Once we
get the official bits out there we can evaluate multiple vendors for
an 'official' release and give it the stamp (paraphrased). It may come
to pass that we might want someone else to do the official distribution
(implied: or several people). (Additional talk). Jordan: The point
I want to make as a release engineer is that this is about as clean as
it is going to get, since I do not work for anyone with a vested
interest in the official FreeBSD release, ... so we should do it (fair
share, paraphrased). (yet more talk about who should run the official
FreeBSD sites)... the FreeBSD foundation is at the point now where the
sites can officially shifted to them (my comment: though obviously
hosting will still probably be done by Yahoo???)
-- KSEs (Julian)
Julian: The basic ... the basic... we will start from the really first
thing which is system calls become asynchronous and the threads library
uses that to generate new threads. The basic idea is that you go down
into the system and when the process would block it instead saves the
basically the uarea. We want to save the kernel stack and state for
that process so it can be restarted. Now the process can keep running.
It then allocates from a cache of uareas (not the best definition) and
loads the very top of that stack with a trampoline (my term) that
returns to the same system call in user mode that originally blocked,
and that place does some kernel housekeeping and jumps back into the
userland/kernelland scheduler.
Presently we have one process structure but we end up with four
structures under this picture. We have the process structure, P.
This owns all the resources, including address space, descriptors,
any credentials, all that stuff. Then we have another small entity KSEG
that owns scheduling priority and quanta. Mike: We already have a KSEG
(kernel segment). Julian: well, whatever you want to call it. Julian:
then we have the KSE. Its sort of an empty shell in which contexts are
loaded to run. This is the scheduling vehicle.. a kernel schedulable
entity of some sort. This is what provides your parallelization within
a process. The last thing is called a KSEC. This contains the kernel
stack, all state of blocked and running code. So, umm, the way it
works is in a normal process before you do anything has one of all of
these, and one other possiblity is that the process structure always
contains (one of) all of these. Robert: note that in the linux model
the credential is bound to the thread, which is contrary to the POSIX
model. Julian: you could bind the credential to another structure
(this is not being seriously entertained).
Julian: So how do you glue all this stuff together? It's simple. You
are running in usermode and do a system call into the kernel. All the
status where you came from is saved, and is copied into the kernel. The
kernel then returns to where it came from this first time only. At
another time in the future you run a system call into the kernel and
block. At this point you allocate a new KSEC and the old one is saved
on a sleep queue somewhere. You then take the original state copied
into the kernel and return to it. (The userland scheduler is what
originally calls into the kernel whos state is saved. Later on this
state is used by the kernel to 'return' to the userland schedule
many times, as necessary when a userland thread blocks in the kernel,
allowing the userland scheduler to then handle the userland side of
thread scheduling).
(additional discussion, a suggestion to keep the conversation at a higher
level). DG: (paraphrased) does this fundamentally change the way
syscalls work? Julian: No, only if that very first system call is
made (to place the kernel in a threaded mode of operation). DG: so if
you don't do that the behavior is exactly the same as it works today.
Julian: Yes. DG: So this is similar to what pthreads does, but we move
it into the kernel. Julian/others: Yes. Julian: Except you don't have
to wrap your system calls (refering to pthreads). Robert: So locks
would result in a switch of this sort, but Mutexes would not? Julian:
right (because mutexes cannot be held across a schedule blocking
condition). John: blocking mutexes and SX locks already do switches,
so it would be relatively easy to do this.
(paraphrased)... discussion about the potential for deadlocks between
Mike Smith and Julian. When the kernel stalls on a context, wakeup
and continuance of that kernel context is independant of the userland
thread it came from.
Lots more stuff. Jordan breaks in: How soon will we see this code
into current? Julian: The first sections of this...it depends how
far I am allowed to go. I can make a lot of the changes now and make
it so it works the same as it does now (as long as the new system call
is not called). Jordan: How would you do that? Julian: Breaking the
proc structure into four parts and having all four present in the
proc structure. Matt: would those be embedded structures or allocated?
Julian: For the moment those would be embedded structures. Jordan:
what else? Julian: You would have to go through and change all the
places where the system runs through the process to run through the KSE.
Jordan: ok, what else? Jordan: Are there any funcitonal changes assuming
you cleanup all the naming issues? Peter: No, there is not much that
has to change functionally. The biggest impact is renaming existing
things under slightly different names that need to be broken up. But
the bigger picture is not much different. DG: the current scheme
for initializing a proc structure is already broken up into three
sections. Julian: I will have a call for each of these broken up
pieces for each of the three sections. Jordan: Assuming all of this
(paraphrased), how long would it take? Julian: Macros, around 4 hours.
Jordan: the rest? Julian: Adding the syscalls, probably around a week.
Jordan: And how long to make the resulting... Julian: The changes to
all the rest of the kernel is the big one.. about a month of time.
(Robert describes the issues involved in the big one). DG: one man
month or one month period? (Lots more questions).. Julian: Yes, it
can be done piecemeal without breaking the kernel.
Robert: How is this going to effect the lock pushdown? Peter and
Julian: We just continue to lock the whole process for now, and say
that it 'locks' all the things under the process (related to the KSE
stuff). Jordan: But are there any objections? Answer from
everyone: No Objections.
Robert: what are the differences between what the NetBSD and we are
doing? Julian: NetBSD is basically implementing scheduler activations
directly from the paper. We looked at the paper and said "Hmm, but
what about...". Peter: There isn't a lot of fundamental change between
the two, it should be possible to run the NetBSD binaries with a simple
layer. Mike Smith: there haven't been any other suggestions that appeal
to people other then this way. Peter: (Peter tries to scare people into
believing that KSEs are really the best way to go by implying that other
systems are much worse). Peter: do you have time? Julian: A quarter
of my time is paid for FreeBSD work, but the work hours only apply to
a 40 hour week. I do not think it will take 4 times as long (aka will not
take 4 real months for 1 man month).
Nik: The mechanical stuff, how easy would it be to document rules for
a junior kernel hacker? Julian: Very easy.
Jordan: Julian has been given clearance. (more jokes follow, sorry
you won't see it on the video, Jordan is changing the tape!).
-- SMP
John: network layer will be locked down for the moment using
three our four larger locks.
Matt: question in regards to the proc lock.
Jordan: so how are you going to break the milestones down? John:
I would happy to get the network and proc locking done by 5.0.
Greg: are we going to have performance goals for 5.0?
Answer (from several people): no, none.
Peter: (paraphrased) we will work on performance goals for 5.1.
Greg: if we had a 5.0 release that is half the speed of 4.x... I would
be unhappy.
Mike smith: Realistically it probably would not be that bad, and if it
were it would set off alarm bells.
Mike smith: The times for buildworlds are still in the ballpark.
Greg: can someone give me something more specific?
Mike smith: it is possible to do it in about 40 minutes, roughly similar
to 4.x.
Peter: On an SMP duel 1.2GHz AMD, it was 27 minutes (stable)
verses 32 or 33 (current). That was both being built .. actually building
-current on 4.3, then install 5.0 and building again. Local filesystems.
No ram disks, etc etc.
Mike smith: Bottom line we care about performance but it is not something
we will be persuing in 5.0.
Greg: bottom line is stability. (Mike says functionality and stability
are similar, Greg says they are very different).
Robert: Maybe we should go on talking about the more general SMP
functionalities.
Jordan: so you are saying proc and networking stuff.
John: yes. So the idea we came up with is having three or four
general locks.
Matt: what about moving the rest of the kernel out of giant?
John: we thought about trying to do subsystem locks when we started all
of this, but the problem is that code flow goes both ways and you really
need to attach locks to data rather then code. (Paraphrased, My
typing is incomplete).
Jordan: so is that not going to happen until 5.1? 5.2?
John: (noncommittal)
Jordan: so when can we call SMP 'finished'?
(now too many people chime in)
Jordan: will giant be involved to hold all the misc stuff so there is
no need to do a lock pushdown everywhere?
John: what I would like to do is get some syscalls outside of Giant.
Mike S: so you would like the infrastructure in place so the lock pushdown
can go on in the background without necessary impinging performance.
You would like the hardest work out of the way?
John: yes. There will not be a lot of instant gratification.
Mike S: we understand that.
Jordan: how much dust will there be in the tree when it branches?
When does it stop?
John: I expect it to take quite a lot of time to get the kernel completely
locked.
(additional discussion).
Mike: so there is no clear line.
John: ... yes. I don't have a line in my head.
Mike: it sounds like a time consuming process. At some point we need to
make a decision as to what level of locking is appropriate for the 5.x
branch. ... We want 5.0 to be reasonably concurrent in the kernel. That
is one of the design goals for the 5.x branch.
John: it is going to take more resources then I have now. I don't know
how long it is going to take. (goes on to explain a number of subsystems
showing the complexity of the issue).
Jordan: these are questions that you probably can't answer in this
meeting... .(and goes on to expound on that a bit). People are going
to want to know when this (5.x) is going to be a win verses 4.x.
Nik: so by 5.2.... Jordan: so by then we would want there to be enough
of a win that people can be comfortable with it (paraphrased).
John: (talks about profiling tools to locate bottlenecks).
(additional discussion about how to break the network up in regards
to lock pushdowns)
Greg: so again we will not have a parallel network stack in 5.0.
Peter: yes, but that will not effect device driver writers per say.
(too many people talking back and forth now, sorry)
Matt: I will be working on -current on weekends (VM and giant related
stuff).
Robert: so what subsystems do we have to worry about?
John:
VM
VFS
Buffer cache
TTY
Proc/Sessions/Group
(long discussion (sorry) on VFS locking. Discussions in regards to
where BSDOS is on this vs us, etc...)
-- MISC
Misc discussions about the state of firewire, USB, NetBSD/FreeBSD
codefork in regards to (firewire?). Misc discussions on what various
people are doing.
Jordan: so is firewire basically dead then?
Mike S: well, it isn't dead but nobody is driving it now
Robert: it's basically dead.
(more talk about firewire)
(my fingers are getting tired)
Jordan: we get beaten up the most about 3D support, on USB support,
on firewire.
Warner: nobody has beaten you up about cardbus:
Jordan: no, nobody has beaten me up...
(others:) they just assume it won't work. (laugh)
(talk on compat/linux stuff as it relates to games. Basic concensus
is that it's possible but a lot of messing around. Jordan never could
get it to work).
What about IRDA? Julian: where there's the S?? chipset, and there's
the Toshiba chipset. It's in the state now where IR data is being
piped up to userland and they are playing with it. Mike Smith: there's
no killer driver to drive IRDA. Nik: In Europe there are phones with
IRDA ports where you point your laptop at the phone and get 9600.
Mike Smith: but, well is there protocol documentation available?
(more talk on that)
Mike Smith: where I am getting at is that by ourselves we will need a
lot of extra attention to get that kind of functionality.
Jordan: can we summarize this as not having anyone particularly working
on this?
Julian: Well, we have some people working on it (working on Benno's
code base)
Jordan: can you get us in contact so they aren't unknowns (paraphrased)
Julian: yes, I've already started that (paraphrased).
Jordan: so Julian is going to drive our IRDA
Julian: I will be the liason.
Jordan: does anyone have any objections to having the ports stuff split
out of the cvs repository, i.e. be a separate cvs repository? (probably
on the same machine).
(general response): No, that's a good idea.
(Matt's internal note: this was brought up a number of times outside
this meeting. The concern is that from a security standpoint the number
of ports committers are growing to a point where we have issues with the
kernel tree, but nobody wants to alienate or categorized a 'ports
committer' as being somehow a 'lesser' committer. This is basically being
driven by security concerns. Similarly, most new committers are not given
shells on freefall any more, just cvs server access).
END
*** [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.
<itojun> keiichi: i guess i agree, it makes sense only after measurement... (again)
<DrZiplok_> see above inre: measurement
--- awfulhak gives channel operator status to dmlb
--- awfulhak gives channel operator status to jlemon
--- awfulhak gives channel operator status to josefk
<itojun> also, it highly depends on application, how many PCI cards you have, apps, whatever.
<-- goofy6 has quit (ircII/tkirc)
<rwatson> dillon challenges current incorrect focus of SMPng.
<rwatson> lots of discussion of preemption, priority inversion, thread migration, interrupts, etc, etc, etc...
<itojun> dillon is going back to giant lock concept???
<jlemon> from what I seem to follow is that dillon doesn't like interrupt threads.
<rwatson> itojun: this I believe has mostly to do with what preempts what--more to do with policies for migrating, and light-weight threads
--> bright (bright@sneakerz.org) has joined #kernelsummit
--> aDe (ident@hub.lovett.com) has joined #kernelsummit
--- ircd.lightning.net gives channel operator status to bright
--- ircd.lightning.net gives channel operator status to aDe
<rwatson> itojun: this is mostly an argument about thread scheduling
<itojun> do you switch process thread (or process) every time you get interrupt?
<rwatson> it's an edge case
<-- josefk has quit (Killed (irc.exodus.net (irc.isdnet.fr <- ircd.lightning.net[207.45.69.70])))
--> josefk_ (~joe@genesis.tao.org.uk) has joined #kernelsummit
<rwatson> jlemon, inspired, suggests drawing a picture
<itojun> i don't understand. how frequently bsdi trick (proper kernel thread invocation on interrupt) happen?
<rwatson> jake: ``It's about correctness'' dillon: ``No it's not''
<DrZiplok_> I think that people should start throwing candy.
<rwatson> I think we should go to dinner
* jlemon seconds rwatson.
<bsdimp> food
<bsdimp> food
<bsdimp> food
<bsdimp> food
<bsdimp> food
<jlemon> beer
<jlemon> beer
<jlemon> beer
<jlemon> beer
<rwatson> jhb wants coke
<BigFork> jhb is nisane
<rwatson> nisane?
<rwatson> perhaps insane?
* rwatson runs.
<BigFork> jhb is not going to say anything else
<BigFork> at the risk of losing my temper
<rwatson> jhb is a bit like caesar, he refers to himself in the third person.
<rwatson> jhb goes, sees, and conquers.
<jlemon> I wish dillon would shut up and give jake a turn at the board.
<rwatson> hey, peter's back.
<keichii_> he's been here since dillon started
<BigFork> s/and.*$//
* bsdimp heads starts to spin.
* jlemon hears "optimize" and tunes out everything after that.
* rwatson enjoys the use of the word ``bust'' in the same sentence as ``cache''.
* rwatson types ``cash'' and ponders dinner.
<BigFork> 10 minutes
* rwatson watches dillon mow over itojun.
<ume> have a good dinner. I'm too sleepy. I'll go to bed.
<rwatson> ume: sounds wise
<-- awfulhak has quit (Client Exiting)
<keichii_> rwatson : i think that's the general jargon :Q
<itojun> aha, you are still awake... i assumed that you woke up early
* keichii_ needs food
<keichii_> we need to leave for dinner?
<-- keichii_ has quit (BitchX: the new hardcore, psycho, nitro client -- in a can)
<-- jlemon has quit (following keichii...)
<-- BigFork has quit (food now)
<-- itojun has quit (Leaving)
<-- rwatson has quit (doof)
<-- hosokawa has quit (Remote closed the connection)
<-- bsdimp has quit (food is near)
<-- ume has quit (irchat exiting...)
<-- kjc has quit (Leaving)
--> poseiden (poseiden@66.64.12.250) has joined #kernelsummit
<-- DrZiplok_ has quit (ircII/tkirc)
--> julian (~julian@tserver.conference.usenix.org) has joined #kernelsummit
<-- julian has quit (Client Exiting)
<-- originat has quit (ircII+tkirc2)
--> dwhite- (dwhite@cust-P5-R7-64.POOL.ESR.SJO.wwc.com) has joined #kernelsummit
--> ppl- (crow@pix142166194095.nbtel.net) has joined #kernelsummit
--- irc.emory.edu gives channel operator status to dwhite-
--- tmm gives channel operator status to tmm2
<-- tmm has quit (sleep)
--> adrian (adrian@node16292.a2000.nl) has joined #kernelsummit
<adrian> moo
<josefk_> baaa
--> stalker (stalker@feerbsd.org) has joined #kernelsummit
--> hsu (hsu@idiom.com) has joined #kernelsummit
<-- ppl- (crow@pix142166194095.nbtel.net) has left #kernelsummit
<hsu> is anything going on? Terry wants to know.
<-- hsu (hsu@idiom.com) has left #kernelsummit
<-- aDe has quit (*zot*)
<josefk_> roto
<josefk_> whoops, there goes my root password :(
* adrian hax0rs the new server
* josefk_ changes the password.
<adrian> dang
* josefk_ blows raspberries at Adrian.
<-- Roamer` has quit (Ping timeout: 360 seconds)
<poseiden> if you didn't tell us that was the root password we wouldn't have guessed
<josefk_> well I figured that I needed to change it anyway so there was no harm in giving you all 3 seconds to try and hack in.
<josefk_> :)
<poseiden> so that's why I got in, must have got in, in the first two seconds :)
<josefk_> damn you - look at the mess you've made ;)
<poseiden> I need to commit some ports this weeked
<poseiden> can't be in bsd all the time anymore
<josefk_> I need to _relax_ this weekend.
<poseiden> heh
--- tmm2 gives channel operator status to adrian
--- tmm2 gives channel operator status to josefk_
--- tmm2 gives channel operator status to poseiden
<dwhite-> things finished here?
<poseiden> I think so
<dwhite-> stupid netsplits
<josefk_> dwhite-: someone said that it starts again 15:00 tomorrow (their time).
<dwhite-> I guess they have sessions to attend, etc. :)
<josefk_> I think that that's 7pm GMT.
<dwhite-> 2 hours, not too bad
<josefk_> dwhite-: They're getting ready for a party tonight.
* dwhite- plays with wget
<tmm2> josefk_: I think it actually is 11:00 EST (16:00 UTC?)
<poseiden> wow, asami lives
<poseiden> time for winblows :(
<-- poseiden has quit (poseiden)
--> tmm3 (lzlzth@pD900C6B5.dip.t-dialin.net) has joined #kernelsummit
--- tmm2 gives channel operator status to tmm3
<-- tmm2 has quit (...)
--> tmm2 (bwcqud@pD900C6B5.dip.t-dialin.net) has joined #kernelsummit
--- tmm3 gives channel operator status to tmm2
<-- tmm3 has quit (...)
<-- tmm2 has quit ('night)
<-- josefk_ has quit (Client Exiting)
--> paradr0id (eric@toxic.magnesium.net) has joined #kernelsummit
--> homos3x (uucp@200.41.85.22) has joined #kernelsummit
<homos3x> homosex homosex homosex homosex homosex homosex homosex homosex
<homos3x> omosex homosex homosex homosex homosex homosex homosex homosex
<homos3x> mosex homosex homosex homosex homosex homosex homosex homosex h
<homos3x> osex homosex homosex homosex homosex homosex homosex homosex ho
<homos3x> sex homosex homosex homosex homosex homosex homosex homosex hom
<homos3x> ex homosex homosex homosex homosex homosex homosex homosex homo
<homos3x> x homosex homosex homosex homosex homosex homosex homosex homos
<homos3x> homosex homosex homosex homosex homosex homosex homosex homose
<homos3x> homosex homosex homosex homosex homosex homosex homosex homosex
<homos3x> omosex homosex homosex homosex homosex homosex homosex homosex
<homos3x> mosex homosex homosex homosex homosex homosex homosex homosex h
<homos3x> osex homosex homosex homosex homosex homosex homosex homosex ho
<homos3x> sex homosex homosex homosex homosex homosex homosex homosex hom
<homos3x> ex homosex homosex homosex homosex homosex homosex homosex homo
<homos3x> x homosex homosex homosex homosex homosex homosex homosex homos
<homos3x> homosex homosex homosex homosex homosex homosex homosex homose
<homos3x> homosex homosex homosex homosex homosex homosex homosex homosex
<homos3x> omosex homosex homosex homosex homosex homosex homosex homosex
<homos3x> mosex homosex homosex homosex homosex homosex homosex homosex h
<homos3x> osex homosex homosex homosex homosex homosex homosex homosex ho
<homos3x> sex homosex homosex homosex homosex homosex homosex homosex hom
<homos3x> ex homosex homosex homosex homosex homosex homosex homosex homo
<homos3x> x homosex homosex homosex homosex homosex homosex homosex homos
<homos3x> homosex homosex homosex homosex homosex homosex homosex homose
<-- homos3x (uucp@200.41.85.22) has left #kernelsummit
--- greid sets ban on *!*@200.41.85.22
--> dannyboy_ (dannyboy@adsl-151-205-126-247.chlstn.adsl.bellatlantic.net) has joined #kernelsummit
<-- dannyboy_ has quit ([x]chat)
<-- nephrozym has quit (Client Exiting)
--> Evil-Bill (wpaul@brak.osd.bsdi.com) has joined #kernelsummit
--> Holocaine (benno@CPE-61-9-137-172.vic.bigpond.net.au) has joined #kernelsummit
<Evil-Bill> Tomorrow is the last day.
<-- Debolaz has quit (Ping timeout: 180 seconds)
<-- Evil-Bill has quit (Leaving)
--> desrt (desrt@pc-12-146.mountaincable.net) has joined #kernelsummit
<-- paradr0id has quit (Ping timeout: no data for 243 seconds)
--> paradr0id (eric@toxic.magnesium.net) has joined #kernelsummit
--> rwatson (~rwatson@tserver.conference.usenix.org) has joined #kernelsummit
<-- paradr0id has quit (ircd.east.gblx.net irc.east.gblx.net)
<-- wca has quit (ircd.east.gblx.net irc.east.gblx.net)
--> wca (will@casimir.physics.purdue.edu) has joined #kernelsummit
--> d4 (~dana@typhon.eng.utah.edu) has joined #kernelsummit
<d4> hmm
<d4> bla
<d4> bla
<cmc> can I help you?
<d4> oh
<d4> eh
<d4> sorry... playing with term shit
<-- Holocaine (benno@CPE-61-9-137-172.vic.bigpond.net.au) has left #kernelsummit
<-- wca has quit (Ping timeout: no data for 974 seconds)
--> wca (will@casimir.physics.purdue.edu) has joined #kernelsummit
<-- dwhite- has quit (ircII EPIC4pre2.003 -- Accept no limitations)
--> poseiden (poseiden@66.64.12.254) has joined #kernelsummit
<-- poseiden has quit ()
<rwatson> someone op me
--- cmc gives channel operator status to rwatson
--- rwatson has changed the topic to: http://blitzkrieg.blackened.com/~dima/IrcLog (next session: 11amEST)
--> dwhite- (dwhite@cust-P5-R7-64.POOL.ESR.SJO.wwc.com) has joined #kernelsummit
<-- rwatson has quit (Client Exiting)
--> rwatson (~rwatson@tserver.conference.usenix.org) has joined #kernelsummit
<-- dwhite- has quit (irc.exodus.net ircd.east.gblx.net)
<-- wca has quit (irc.exodus.net ircd.east.gblx.net)
<-- d4 has quit (irc.exodus.net ircd.east.gblx.net)
--> wca (will@casimir.physics.purdue.edu) has joined #kernelsummit
--> dwhite- (dwhite@cust-P5-R7-64.POOL.ESR.SJO.wwc.com) has joined #kernelsummit
--> d4 (~dana@typhon.eng.utah.edu) has joined #kernelsummit
--> micky35 (~paul@tserver.conference.usenix.org) has joined #kernelsummit
<-- micky35 has quit (ircII+tkirc2)
<rwatson> Obtained from: USENIX Emporium, Cheap Tricks Department
<-- greid has quit (Remote closed the connection)
<-- dwhite- has quit (sleepy time)
<-- rwatson has quit (Client Exiting)
<-- dmlb has quit (Ping timeout: 180 seconds)
--> dmlb (~dmlb@pc1-camb6-0-cust228.cam.cable.ntl.com) has joined #kernelsummit
--> winter_ (winter@sasami.jurai.net) has joined #kernelsummit
--> gehicks (~gehicks@adsl-64-166-87-247.dsl.sntc01.pacbell.net) has joined #kernelsummit
--> tmm_ (hgvwxy@p3E9C2F9E.dip.t-dialin.net) has joined #kernelsummit
<winter_> anyone have logs?
<gehicks> yeah
<gehicks> well, at dima's page
<gehicks> http://people.freebsd.org/~dd/ks.pt1
<-- tmm_ has quit (ircII EPIC4-1.0 -- Are we there yet?)
<-- gehicks has quit (zzz)
--> Debolaz (~debolaz@c224s39h16.upc.chello.no) has joined #kernelsummit
--> tmm_ (gpfmxj@pD900C66C.dip.t-dialin.net) has joined #kernelsummit
--> BigSpoon (~john@tserver.conference.usenix.org) has joined #kernelsummit
--> Roamer` (roam@diskworld.nanolink.com) has joined #kernelsummit
<-- winter_ has quit (Ping timeout: no data for 247 seconds)
<-- BigSpoon has quit (off to a talk)
--> wkb (~wkb@freebie.xs4all.nl) has joined #kernelsummit
<-- wkb has quit ([x]chat)
--> wkb (~wkb@freebie.xs4all.nl) has joined #kernelsummit
<-- wkb has quit ([x]chat)
--> bsdimp (~imp@tserver.conference.usenix.org) has joined #kernelsummit
--> wkb (~wkb@freebie.xs4all.nl) has joined #kernelsummit
<-- Roamer` has quit (hm)
<-- tmm_ has quit (reboot)
<bsdimp> http://people.freebsd.org/~jhb/summit/
--> BigSpoon (~john@tserver.conference.usenix.org) has joined #kernelsummit
<BigSpoon> http://www.freebsd.org/~jhb/summit/schedule.txt
--- wkb is now known as freebie
--> groggy (~grog@tserver.conference.usenix.org) has joined #kernelsummit
<groggy> OK, guys, how about an opfest?
--> tmm_ (jexfox@pC19EBF84.dip.t-dialin.net) has joined #kernelsummit
--> tmm3 (mxggas@pC19EBF84.dip.t-dialin.net) has joined #kernelsummit
* groggy notes that the conference is about to start.
* groggy wanders off.
--> rwatson (~rwatson@tserver.conference.usenix.org) has joined #kernelsummit
<rwatson> g'morning all
--> nik (~nik@tserver.conference.usenix.org) has joined #kernelsummit
<freebie> Morning? Almost dinner time here ;-)
<-- Debolaz has quit (Read error: 54 (Connection reset by peer))
--> Debolaz (~debolaz@c224s39h16.upc.chello.no) has joined #kernelsummit
<-- nik has quit ()
--- tmm_ is now known as tmm2
--> gjvc (gjvc@extremis.net) has joined #kernelsummit
--> missnglnk (missnglnk@hydrant.informationwave.net) has joined #kernelsummit
--> EvilPete (h0h0magic@elvis.mu.org) has joined #kernelsummit
--> keichii_ (~keichii@tserver.conference.usenix.org) has joined #kernelsummit
--> nik (~nik@tserver.conference.usenix.org) has joined #kernelsummit
--> awfulhak (~brian@tserver.conference.usenix.org) has joined #kernelsummit
* bsdimp notes that usenix' network goes down at 2pm today. It is now 11:10
* awfulhak notes that the topic should be changed to http://people.freebsd.org/~jhb/summit/schedule.txt
<tmm3> Hmm, if that schedule is about right, we'll miss most :(
<bsdimp> How we count "1 2 3 10"
<BigSpoon> ok
<rwatson> keichii demonstrates "new math"
<BigSpoon> next time
<BigSpoon> I will tell everyone to be here at 9am
<BigSpoon> maybe then they will be here by 11
<freebie> you're an optimist..
--> jkh_ (~JordanHub@tserver.conference.usenix.org) has joined #kernelsummit
<BigSpoon> bah
<jkh_> ba
<bsdimp> holocane
<rwatson> bah
<jkh_> sound off!
<bsdimp> imp!
<bsdimp> Warner Losh
--> dfr (~dfr@tserver.conference.usenix.org) has joined #kernelsummit
<dfr> Hi
<tmm3> hmm, is someone videotaping this as it was planned?
<dfr> not yet
--> sos (~sos@212.242.86.115) has joined #kernelsummit
<BigSpoon> powerpc: openfirmware progress in the kernel..
<BigSpoon> powerpc: looking to do ddb over ethernet for lack of a serial console (keichii)
<BigSpoon> powerpc: locore 1/2 done, pmap close to done
<bsdimp> G4 only for powerpc.
<EvilPete> after the network goes down, irc server: 10.0.1.171:6667. remember to switch to adhoc first.
<BigSpoon> power: hopefully single user by 5.0
<bsdimp> Single user by 5.0
<bsdimp> powerbook
<bsdimp> titanium
<bsdimp> ibook
<bsdimp> 7410
<bsdimp> robert asks about the ABI?
<bsdimp> embedded or other?
<bsdimp> no abi has been been pciked
<BigSpoon> embedded being used now
<BigSpoon> linux uses svr4
<bsdimp> embedded in use now. SVR4 maybe in the future
--> micky60 (~paul@tserver.conference.usenix.org) has joined #kernelsummit
<bsdimp> bill paul arrives
<bsdimp> endian indendent ffs
<-- micky60 (~paul@tserver.conference.usenix.org) has left #kernelsummit
<BigSpoon> linear independent file system
<BigSpoon> like ffs
<BigSpoon> maybe we need to beat up on kirk for this
--> originat (~paul@tserver.conference.usenix.org) has joined #kernelsummit
<BigSpoon> s/linear/endian/
<bsdimp> netbsd is endian independent.
<BigSpoon> netbsd has an endian independent file system
<BigSpoon> either specify (possibly indirectly by the magic number) specify the endianness of the file system
<bsdimp> peter wants them to be compile time option
<bsdimp> "bisexual ffs option"
<BigSpoon> dfr thinks we should use a fixed endian file system
<-- originat has quit (Ping timeout: 240 seconds)
<bsdimp> jake wants newfs to pick
<BigSpoon> booting probably requires the native boot order
<BigSpoon> (imp)
<bsdimp> g4 and g3 powerbook support.
<bsdimp> then embedded platforms.
<EvilPete> another option is to be able to compile an alternate filesystem.. eg: "ffs" = native, "beffs" = big endian, "leffs" = little endian
<EvilPete> eg: on i386: mount -t beffs /dev/sparcdisk0
<bsdimp> ia64 (doug) status
<EvilPete> and that encapsulates the byte swapping into a seperate code module
<BigSpoon> single user in emulation mode
<bsdimp> in simulator, singleuser mode and we gets a signal
<BigSpoon> signals seem to work
<bsdimp> two stacks
<bsdimp> need to cope
<bsdimp> stacks grow downards, but register stack grows up.
<bsdimp> auto on regular stack.
<bsdimp> a bit sparc register windows.
<BigSpoon> explanation of the ia64 register stack engine and spilling ot memory
<bsdimp> "how much is that in bytes"
--> Storm- (~veers@24.101.36.233.on.wave.home.com) has joined #kernelsummit
<bsdimp> pete says mozilla goes up to 1200 frames deep.
<bsdimp> guard page
<bsdimp> threads library
<BigSpoon> rwaton suggests looking at linux's ia64 stuff
<bsdimp> seconds tack near end of maxstack
<BigSpoon> woot, a tripod!
--> GlockaDe (ident@hub.lovett.com) has joined #kernelsummit
<awfulhak> grog found a tripod -- the meeting pauses while we bikeshed about where it goes
* jkh_ sighs in relief at not having to hold the camera anymore
<bsdimp> loader
<BigSpoon> jkh_: heh
<bsdimp> runs on hardware
<bsdimp> trying to get ficl work
<BigSpoon> needing to debug setjmp/longjmp
<bsdimp> debugging setjmp/longjmp
<bsdimp> once loading, then bring it up on a real machine
<BigSpoon> next step is booting a kernel on a real machine
<bsdimp> dfr has a real machine
<BigSpoon> dfr has access to a real machine
<bsdimp> toolchain issue
<BigSpoon> toolchain issues with gcc 3.0
<bsdimp> c++has big issues
<bsdimp> toolchain
<BigSpoon> crossbuilding a real userland
<groggy> awfulhak: I didn't "find" a tripod, I brought it half way round the world.
<BigSpoon> single user on real hardware by 5.0
<bsdimp> single user before 5.0
<bsdimp> smt
<bsdimp> (4 cpus sorta on one die)
<bsdimp> asks about scalability
<bsdimp> plan ahead
<bsdimp> ibm interested in 96cpu.
<bsdimp> powerpc
<bsdimp> at least 32 cpus
<BigSpoon> not sure that should be public info possibly :)
<bsdimp> coffie
<BigSpoon> coffe is here
<bsdimp> coffee
<dfr> coffee arrives...
<awfulhak> coffee's important !
* BigSpoon notes we are slipping on the schedule
<bsdimp> talk schedule or 5.0 release schedule
<BigSpoon> talk schedule
<bsdimp> signature!
<BigSpoon> I think I'll delegate questions to the end of each section from now on
<bsdimp> BigSpoon: we may need a talking stick.
<bsdimp> powerpc
<bsdimp> beeno
--> originat (~paul@tserver.conference.usenix.org) has joined #kernelsummit
<bsdimp> working his way through the probe
<bsdimp> ppc32
* BigSpoon notes 5 minutes to the break for the end of the first session
<bsdimp> little endian?
* BigSpoon hopes jake's sparc64 update isn't long :)
<bsdimp> nether netbsd nor freebsd works on ppc64
<dfr> american coffee :-(
<bsdimp> groggy will doing it on his occasional basis
<bsdimp> limited number of trusted people can be given access
* nik notes that mail coming from freebsd.org appears to have stalled.
<BigSpoon> to a dual ppc64 machine
<bsdimp> brothel valley wineries
<bsdimp> ultra5
<BigSpoon> sparc65 port from jake
<BigSpoon> remote access to an ultra5, no local box yet
<bsdimp> jake into file system issues.
<groggy> bsdimp: Barossa.
<BigSpoon> definitely single user by 5.0
<bsdimp> single user by 5.0
<groggy> bsdimp: But McLaren Vale is closer.
<bsdimp> stack is the same
<bsdimp> window register don't change things too much.
<BigSpoon> aiming for sparc64 pci based machines
<BigSpoon> obrien doens't want sbus support :)
<BigSpoon> most sparc64's are pci
<bsdimp> obrien can cope :-)
<BigSpoon> Ade Lovett will provide access to an e4500
<BigSpoon> 8 cpu's and 16 gigs of ram (*envy*: bk)
<BigSpoon> lots of native devices might be sbus
<BigSpoon> ethernet and video cards
<jkh_> sam leffler raises the point that we may need sbus whether we want it or not
<bsdimp> need sbus for video
<awfulhak> need sbus for built-in NICs etc
<jkh_> greg lehey goes to a talk but leaves his laptop behind
<jkh_> attendees immediately set upon it and dissassemble it for spare parts
<missnglnk> yikes
--> julian (~julian@tserver.conference.usenix.org) has joined #kernelsummit
<nik> obrien arrives
<jkh_> obrien appears hung-over
<awfulhak> the room goes quiet - nothing to speak about now !!!
<bsdimp> ka-64
<jkh_> obrien is put on the spot
<jkh_> msobrien squi
<jkh_> whoops
<bsdimp> november
<bsdimp> gcc 3.0 into tree needed for ka-64
<bsdimp> maybe not in 5.0
<julian> but b=may need 3.0+ for ka-64 so that may not be in the tree.
<jkh_> to summarize, sparc and ppc will be single user mode by 5.0
<jkh_> obrien isn't sure about x86-64 though
<dfr> ia64 is already single-user (woohoo!)
<jkh_> bigspoon raises strongarm
<jkh_> michael raises the issue that netbsd doesn't support the SA1110
<jkh_> which is what he has hardware access to
* wca yawns
<julian> http://people.freebsd.org/~jhb/summit/schedule.txt for those not here..
<wca> ...and silence falls over the crowd?
<wca> =P
<julian> jhk talking (not intersting)
* jkh_ kicks julian under the table
<julian> imp discusses which ARM machines might be good targets
<BigSpoon> the most likely arm target may be the ipaq
<BigSpoon> dfr suggests that we don't do arm unless someone wants to pay for it
<rwatson> BigSpoon: s/pay/use/
<dfr> money is always welcome
<BigSpoon> david talks about gcc 3.0
<julian> discussion movess to tool-chain
<BigSpoon> he wants it in 5.0 so we don't rip up C++ abi changes in 5.x-stable
<bsdimp> thank you osf
<wca> you guys sound like a bunch of baseball game announcers
<bsdimp> s/osf/fsf
<julian> David says that the C++ ABI has changed....
<julian> for gcc 3
<bsdimp> david compains about wrs
<BigSpoon> newer binutils imported now
<julian> reports that we have been running a new binutils
<BigSpoon> new binutils will support ia64
<julian> more commits coming
<BigSpoon> jkh asks about java support
<julian> jkh asks about gcc java suppport
<bsdimp> libjava
* BigSpoon notes majoe schedule slippage
<bsdimp> kinda sorta works, but sucks.
<keichii_> BigSpoon : i think it is ok
<bsdimp> java support in 3.0 sucks, so says obrien
<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
<julian> jkh and others point out that this is not kernel
<jkh_> we begin discussion of devd
<BigSpoon> imp will lead this discussino
<BigSpoon> lunch from 1 to 2 btw
* jkh_ thwaps julian and notes that it was tangental to the gcc 3.0 import question
<BigSpoon> what is devd's scope?
<BigSpoon> should it manage devfs
<BigSpoon> should it be a policy manager
<BigSpoon> yesterday the consensus was that it should simply be a unified and genericied pccard + usbd
<BigSpoon> phk wants devd to require permissions to the kernel
<groggy> obrien notes hung over from bad jkh supplied pizza, not good beer.
<BigSpoon> h
<BigSpoon> groggy = obrien now
<BigSpoon> julian speaks from the devfs point of view
<groggy> obrien notes that bsdimp was alomost right, gcc 3._1_ is first gcc with basic ka64 support, not 3.0
--> jedgar (jedgar@peitho.fxp.org) has joined #kernelsummit
<wca> hallo jedgar
<BigSpoon> newcard sucks
<BigSpoon> as imp admits
<BigSpoon> and he has funding for devd
<julian> Summary: devd,though originally an idea from the devfs world, will eventually do a lot more than devfs stuff,
<BigSpoon> actually
<BigSpoon> it isnt' really related to devfs.. it's orthogonal
<julian> in fact most
<BigSpoon> it will work exactly the same without devfs
<julian> of the actions will be devfs indepentent..
<julian> it will be an 'event handler and translater'
--> deo (~obrien@tserver.conference.usenix.org) has joined #kernelsummit
<BigSpoon> it's actually mroe of a new-bus eventhandler
<BigSpoon> ether devices don't have /dev entries right now for example
<originat> more generic than just new-bus events, I'd like to be able to support events like overheat warnings etc
<julian> discussin on h what systems have hot-swap capability
<BigSpoon> originat: that's acpi stuff and will probably be part of a healthd
<BigSpoon> i'll raise that issue in a bit though
<BigSpoon> discussion mentions a devfsd
<BigSpoon> which would handle the devfs management things like phk are worried about
<BigSpoon> obrien gets preempted from grog's laptop
<dfr> groggy arrives..
<wca> hrmm, i thought you were on the 5th floor?
<wca> i just saw groggy here
<wca> on the 4th floor
<BigSpoon> jordan switches tapes
<julian> After a quick experiment, I confirm that DEVFS mounts can have independent ownerships and permissions for a device
<BigSpoon> groggy takes pictures
* deo snuck awayfrom grogg's laptop when he closed xchat accidently and could not figure out the window manager...
* deo whistles innocently.
<wca> 10.0.1.171:6667 after 2pm right?
<BigSpoon> wca: yes
<wca> forget it, i don't have my own wireless card anyways
<wca> and i have other plans anyways
* BigSpoon notes the conversation wanders off to devfs in jails
<dfr> grog takes pictures for evidence..
<keichii_> Evil BSD Conspiracy
<-- deo has quit (bye)
* wca notes wireless cards are due at 1pm for those who rented them
<wca> :(
<BigSpoon> wca: doh
--> kaworu (~ems@tserver.conference.usenix.org) has joined #kernelsummit
<wca> yeah
<wca> fuck that crap
--- kaworu is now known as ems_
<ems_> hey
<wca> bigspoon: hope you don't have a rented one ;\
<wca> bigspoon: doubt you would buy a wavelan gold though ;p
* jkh_ pats his integral wireless
<wca> yeah yeah your new titanium
<wca> how's the new job?
<jkh_> great so far
<wca> comfy? ;)
<jkh_> but then, I've only worked there 2 days before taking off. :)
<groggy> wca: I have a spare wireless card if you want to borrow it.
<jkh_> actually, I have a spare wireless card also
<wca> groggy: i think other people could use it more than me
<jkh_> but the network shuts down at 2pm
<jkh_> so it's not like you'll get much use
* groggy smacks the notwork.
<julian> I discuss the 'device symlnk' method of avoiding having a devfs for every jail
--> fenestro (fenner@electricrain.com) has joined #kernelsummit
<wca> jkh: yeah, you can use ad-hoc
<wca> w/ 10.0.1.171 port 6667
<wca> not that there's much point
<jkh_> julian paints the bikeshed green
* groggy wants external connectivity.
<wca> since most of the interested ppl would be in (what room are you in again?)
* groggy sends out for yellow paint.
<wca> I could provide dialup. :P
* groggy smacks pccardd.
<fenestro> picture of groggy taking pictures of everyone at the summit: http://people.freebsd.org/~fenner/groggy.jpg
<groggy> Grr. It's not seeing my flash card.
<wca> hi bill fenner ;)
<fenestro> hi will andrews
<wca> 8)
<julian> discussion moves temporarily to JAIL stuff
<wca> again, where are you guys ?
<fenestro> Maine, on the 5th floor
<wca> you must be on the 4th floor ?
<wca> oh
<awfulhak> 5th
<BigSpoon> wca: 5th floor, maine room
<wca> hmm, kay
<groggy> wca: 5th floor.
<groggy> wca: You need to take the lift.
<BigSpoon> across the hall from new hampshire room that we were originally scheduled for
<wca> grog: i saw you pass by the laptop room and they announced your arrival not much later
<groggy> wca: Turn left when you come out of the lift.
<wca> okay
<ems_> has it started already?
<wca> i've gotta eat lunch anyways
* groggy wonders if his laptop will freeze when he ejects the flash.
<groggy> Anybody else planning lunch?
<wca> ems: the summit started at 11am boston time
<ems_> ok, thanks
* BigSpoon waits for devfs + jail wind down
* groggy ejects his card.
<fenestro> we're vaguely following http://people.freebsd.org/~jhb/summit/schedule.txt
* groggy smacks pccardd again.
<-- groggy has quit (rebooting--grrr)
<wca> i've been logging #kernelsummit since early friday
<wca> anyone who wants the log just send me a mail
<jkh_> lunch is scheduled for 1pm
<BigSpoon> wca: good
<jkh_> e.g. 15 minutes
<BigSpoon> anyone else logging the channel?
<tmm3> me.
<BigSpoon> yes, and we will be all offline when we get back from lunch :(
<BigSpoon> someone local will need to log the channel when we get back from lunch
* jkh_ wonders how he's going to get through 5 hours of summit with 2 hours of tape
<wca> jkh: tape is cheap
<keichii_> jkh: go buy some real quick?
<fenestro> stop by circuit city on the way back from lunch?
<BigSpoon> jkh_: can you do the trick of downloading the tape to your local disk?
* jkh_ plans a visit to circuit city
* BigSpoon hands jkh a receipt to give to apple's expense people
<jkh_> spoon: yeah, that oo
<wca> ooh jkh has a DV cam?
<jkh_> erm, too
<wca> you have DV cam?? :)
* keichii_ ponders how to kill jkh for hardware
<jkh_> yeah, a Sony
<wca> cuz that would rule
<wca> kickass
<fenestro> and then you can burn DVDs of the meeting
<jkh_> it's filming all of us now
<BigSpoon> oooooo
<jkh_> fenestro: Yep!
<BigSpoon> dvd
<wca> do you know how much it cost or was it compliments of apple?
<jkh_> I have a DVD burner at work
* BigSpoon will pay
<BigSpoon> jkh_: you suck
<jkh_> I think I paid $899 for it
<wca> hah
<wca> damn
<keichii_> i have a dvd-ram on my g4 too
<fenestro> shit, I thought I was kidding =)
<keichii_> it costs more to copy a DVD movie than to buy a DVD movie
<jkh_> keichii: intentional. :)
<BigSpoon> 10 minutes left
<wca> yeah
<keichii_> jkh: *nod*
<julian> discussion of device symlinks..
<wca> i hope you guys read your wireless agreements if you made one, because the cards are due
<julian> dg discusses variant symlinks.
<BigSpoon> wca: most of us have our own I think
* jkh_ hopes that the camera's mic is sensitive enough to pick up everyone from the tripod
<wca> bigspoon: I still think it's noteworthy for others benefit
<bsdimp> jkh_: we should check at lunch if possible.
<jkh_> next conference we need a webcast mechanism and some microphones on the table
<wca> since those cards cost $300 to $400 apiece
<jkh_> then we can dispense with IRC
<wca> naw
<wca> no webcast needed ;P
<ems_> Heh, those aironets aren't very good, I got a Lucent WaveLan GOLD on ebay for $100
<fenestro> and no laptops on the cable cuz otherwise the mics will only pick up typing
--> groggy (~grog@tserver.conference.usenix.org) has joined #kernelsummit
<wca> fenestro: good point
<jkh_> fenestro: man, I can just hear the howls now. :)
<fenestro> haha
<julian> discussion of device symlinks to avoid having millions of device filesystems mounted in millions
<julian> of jails
<julian> devd would take events from devfs to configure these if needed (as per phk doc)
<wca> great
<wca> heh
<wca> well my external client will remain logging as long as you guys are here
* groggy points at http://www.lemis.com/grog/Photos/20010630/
<groggy> Things are still copying.
<bsdimp> forbidden!
<-- originat (~paul@tserver.conference.usenix.org) has left #kernelsummit
<BigSpoon> grr
<bsdimp> chaos
<bsdimp> three conversations
<BigSpoon> lunchtime
* jkh_ thinks this would be a fine fine time to break for lunch
<bsdimp> we won't have network after lunch
<bsdimp> and we're about to break.
<BigSpoon> yes
* groggy messes with permissions on www.lemis.com.
<groggy> jkh_: A greed.
<fenestro> and don't forget http://people.freebsd.org/~fenner/groggy.jpg
<wca> heh
<wca> jkh: going to post your pics sometime?
<julian> suggewtion that we get back to architecture....
<BigSpoon> Forbidden
<BigSpoon> You don't have permission to access /grog/Photos/20010630/ on this server.
* BigSpoon notes exodus routing is screwed up causing dns problems on hub
* groggy rubs BigSpoon's nose in the transcript.
<wca> exodus->crap == true;
<groggy> BigSpoon: I think it wants an index.html. I'm writing it.
<BigSpoon> I just tried it
<wca> bye
<BigSpoon> oh
<fenestro> just because you messed with them doesn't mean they're right =)
<-- ems_ has quit (Remote closed the connection)
<BigSpoon> someone logging this?
<BigSpoon> now that wca is leaving?
<groggy> BigSpoon: I've got most of it, except when I rebooted.
<BigSpoon> good
<BigSpoon> I can't get my braindead client to log
<BigSpoon> *sigh*
<nik> BigSpoon: I've got the whole thing logged.
<bsdimp> I can save the logs from xchat
<BigSpoon> cool
--> Holocaine (benno@CPE-61-9-137-172.vic.bigpond.net.au) has joined #kernelsummit
<groggy> Holocaine!
<groggy> Holocaine: Where were we when we needed you?
<Holocaine> Hey groggy =)
<Holocaine> groggy: ?
* keichii_ kicks Holocaine
<BigSpoon> Benno!
<BigSpoon> can you give a quick status report and roadmap for ppc?
<Holocaine> BigSpoon: sure.
<Holocaine> BigSpoon: now?
<BigSpoon> yes
<keichii_> NOW
<nik> Holocaine: Ye
<bsdimp> am I lagged?
<Holocaine> Ok.
<Holocaine> Current status is that I'm starting work on the device tree.
<keichii_> did you?
* groggy points at http://www.lemis.com/grog/Photos/20010630/, now loadable.
<Holocaine> I've got a rudimentary nexus happening and I'm playing with PIC drivers.
<keichii_> you've been busy while i've been drinking eh?
<keichii_> do you have JTAG yet?
<Holocaine> I've got the OpenPIC in my iMac initialising.
<Holocaine> keichii_: Nope.
<dfr> lunch!
<Holocaine> I'm hoping to start groping around for PCI busses in the near future.
<keichii_> i just committed us to target single user mode for 5.0-C
<keichii_> Holocaine the groper
<Holocaine> keichii_: I'm hoping to meet that.
<Holocaine> What time is it there?
<keichii_> 12 noon
<keichii_> we are about to leave for lunch
<Holocaine> Ah, I was an hour out in my calculations.
<Holocaine> Damn.
* Holocaine should've set his alarm for 2am.
<BigSpoon> that's ok
<-- dfr has quit (using sirc version 2.211+KSIRC/1.1)
<Holocaine> BigSpoon: Anything else people want to ask about PowerPC or shall we hold off until after lunch?
<BigSpoon> we won't be around after lunch
<BigSpoon> usenix pulls the plug at 2
<Holocaine> BigSpoon: Ah, damn.
<Holocaine> BigSpoon: You mean I got up for nothing? =)
<-- fenestro has quit (au revoir)
<bsdimp> hoho magic
<keichii_> Holocaine : yes
<Holocaine> Damn.
<groggy> Holocaine: I think you were two hours out.
<Holocaine> groggy: Gawd. I did really well then.
<Holocaine> Oh well, I'll know better next time. =P
<Holocaine> That's weird. I originally calculated 1am, then decided I was wrong and thought 3am. I was right the first time
<groggy> Holocaine: date(1) is your friend.
<Holocaine> groggy: I was using zdump.
<groggy> === grog@sydney (/dev/ttyp5) ~/Photos/20010630 5 -> TZ=Australia/Melbourne date
<groggy> Sun Jul 1 03:11:01 EST 2001
<groggy> === grog@sydney (/dev/ttyp5) ~/Photos/20010630 6 -> TZ=America/New_York date
<groggy> Sat Jun 30 13:11:03 EDT 2001
<groggy> keichii_: You're still on Austin time.
<Holocaine> groggy: Yeah, I'd done the zdump on Friday and must've got turned about.
<keichii_> groggy : well...
<Holocaine> Oh well, back to bed I guess.
<-- rwatson has quit (unch)
<bsdimp> Time to leave.
<-- Holocaine has quit (Client Exiting)
<-- jedgar (jedgar@peitho.fxp.org) has left #kernelsummit
<-- bsdimp has quit (Client Exiting)
<-- BigSpoon has quit (lunch)
* awfulhak is away: I'm busy
* awfulhak is back (gone 00:00:05)
* awfulhak is away: at lunch
<julian> Everyone goes to lunch
<julian> any live people still here?
<julian> (I'm room-watching)
<julian> nope?
<gjvc> hey julian
<-- gjvc has quit (b00m)
<-- jkh_ has quit (Ping timeout: 240 seconds)
<-- julian has quit (Ping timeout: 240 seconds)
<nik> obrien arrives
<tmm3> nik: The network is still up?
<nik> yes apparently..
--> winter_ (winter@sasami.jurai.net) has joined #kernelsummit
* tmm3 suspects that it would be a little too much to hope for it staying up another 3 hours ;)
<-- awfulhak has quit (Ping timeout: 240 seconds)
<-- keichii_ has quit (Ping timeout: 240 seconds)
<-- groggy has quit (Ping timeout: 360 seconds)
<-- nik has quit (Ping timeout: 360 seconds)
<tmm3> Bah. So much for that.
--> canyon (rene@canyon.xs4all.nl) has joined #kernelsummit
<-- canyon has quit (Client Exiting)
--> canyon (~rene@canyon.xs4all.nl) has joined #kernelsummit
--> gshapiro (pjg7y8@horsey.gshapiro.net) has joined #kernelsummit
<-- canyon has quit (Client Exiting)
<-- tmm3 has quit (Ping timeout: 180 seconds)
--> tmm3 (nlegot@pC19EBF84.dip.t-dialin.net) has joined #kernelsummit
--> jhicks (~gehicks@adsl-64-166-87-247.dsl.sntc01.pacbell.net) has joined #kernelsummit
* jhicks notes G5 isn't really that far down the PPC roadmap
<-- gshapiro has quit (Leaving)
<-- jhicks has quit (food)
--> greid (~greid@m274-mp1-cvx1c.gui.ntl.com) has joined #kernelsummit
<-- tmm3 has quit (Ping timeout: 180 seconds)
<-- dmlb (~dmlb@pc1-camb6-0-cust228.cam.cable.ntl.com) has left #kernelsummit
<-- sos (~sos@212.242.86.115) has left #kernelsummit
<-- freebie (~wkb@freebie.xs4all.nl) has left #kernelsummit
--> tmm3 (gkwbst@pC19EBF84.dip.t-dialin.net) has joined #kernelsummit
--> canyon (~rene@canyon.xs4all.nl) has joined #kernelsummit
<-- canyon has quit (Client Exiting)
<-- wca has quit (Dead socket)
--> wca (will@casimir.physics.purdue.edu) has joined #kernelsummit
<-- greid has quit (Read error: 60 (Operation timed out))
<-- wca has quit (ircd.east.gblx.net irc.emory.edu)
--> jhicks (~gehicks@adsl-64-166-87-247.dsl.sntc01.pacbell.net) has joined #kernelsummit
<-- d4 has quit (irc.exodus.net ircd.east.gblx.net)
<-- jhicks (~gehicks@adsl-64-166-87-247.dsl.sntc01.pacbell.net) has left #kernelsummit
<-- cmc (chris@adsl-208-191-149-190.dsl.hstntx.swbell.net) has left #kernelsummit
--> d4 (~dana@typhon.eng.utah.edu) has joined #kernelsummit
<-- desrt has quit (Client Exiting)
<-- tmm3 has quit (Ping timeout: 180 seconds)
--> tmm3 (zpujui@pC19EBF84.dip.t-dialin.net) has joined #kernelsummit
--> aeonflux (latex@h00a0c91e90fe.ne.mediaone.net) has joined #kernelsummit
<-- aeonflux (latex@h00a0c91e90fe.ne.mediaone.net) has left #kernelsummit
<-- adrian has quit (Ping timeout: 240 seconds)
--> adrian (adrian@node16292.a2000.nl) has joined #kernelsummit
<-- Debolaz has quit (Read error: 54 (Connection reset by peer))
--> Debolaz (~debolaz@c224s39h16.upc.chello.no) has joined #kernelsummit
<-- tmm3 has quit (Ping timeout: 180 seconds)
--> tmm3 (ordrqg@pC19EBF84.dip.t-dialin.net) has joined #kernelsummit
<-- tmm3 has quit (Ping timeout: 180 seconds)
--> tmm3 (quodlu@pC19EBF84.dip.t-dialin.net) has joined #kernelsummit
<-- tmm3 has quit (sleep)
<-- Storm- (~veers@24.101.36.233.on.wave.home.com) has left #kernelsummit
<-- tmm2 has quit (Ping timeout: 180 seconds)
<-- Debolaz has quit (Ping timeout: 180 seconds)
<-- winter_ has quit (irc.isdnet.fr irc.exodus.net)
<-- d4 has quit (irc.isdnet.fr irc.exodus.net)
<-- EvilPete has quit (irc.isdnet.fr irc.exodus.net)
<-- GlockaDe has quit (irc.isdnet.fr irc.exodus.net)
<-- missnglnk has quit (irc.isdnet.fr irc.exodus.net)
<-- bright has quit (irc.isdnet.fr irc.exodus.net)
<-- stalker has quit (irc.isdnet.fr irc.exodus.net)
<-- dd2 has quit (irc.isdnet.fr irc.exodus.net)
--> bright (bright@sneakerz.org) has joined #kernelsummit
--> d4 (~dana@typhon.eng.utah.edu) has joined #kernelsummit
--> dd2 (dima@blitzkrieg.blackened.com) has joined #kernelsummit
--> stalker (stalker@feerbsd.org) has joined #kernelsummit
--> missnglnk (missnglnk@hydrant.informationwave.net) has joined #kernelsummit
--> EvilPete (h0h0magic@elvis.mu.org) has joined #kernelsummit
--> GlockaDe (ident@hub.lovett.com) has joined #kernelsummit
--> winter_ (winter@sasami.jurai.net) has joined #kernelsummit
--- ircd.east.gblx.net gives channel operator status to bright
--- ircd.east.gblx.net gives channel operator status to dd2
<-- bright has quit (ircd.east.gblx.net ircd.lightning.net)
<-- dd2 has quit (ircd.east.gblx.net ircd.lightning.net)
<-- stalker has quit (ircd.east.gblx.net ircd.lightning.net)
<-- missnglnk has quit (ircd.east.gblx.net ircd.lightning.net)
<-- EvilPete has quit (ircd.east.gblx.net ircd.lightning.net)
<-- GlockaDe has quit (ircd.east.gblx.net ircd.lightning.net)
<-- winter_ has quit (ircd.east.gblx.net ircd.lightning.net)
--> dd2 (dima@blitzkrieg.blackened.com) has joined #kernelsummit
--> winter_ (winter@sasami.jurai.net) has joined #kernelsummit
--> stalker (stalker@feerbsd.org) has joined #kernelsummit
--- irc.exodus.net gives channel operator status to dd2
--> bright (bright@sneakerz.org) has joined #kernelsummit
--> GlockaDe (ident@hub.lovett.com) has joined #kernelsummit
--> EvilPete (h0h0magic@elvis.mu.org) has joined #kernelsummit
--- ircd.lightning.net gives channel operator status to bright
<-- GlockaDe has quit (Read error: 54 (Connection reset by peer))
<-- EvilPete has quit (Ping timeout: 180 seconds)
--> EvilPete (h0h0magic@elvis.mu.org) has joined #kernelsummit
--- phk gives channel operator status to EvilPete
--- phk gives channel operator status to adrian
--- phk gives channel operator status to winter_
<-- eivind (~eivind@is.too.paranoid.to.irc) has left #kernelsummit
--> tmm3 (nvbtnb@p3E9C2FFD.dip.t-dialin.net) has joined #kernelsummit
<-- bright has quit (irc.isdnet.fr ircd.east.gblx.net)
<-- EvilPete has quit (irc.isdnet.fr ircd.east.gblx.net)
<-- winter_ has quit (irc.isdnet.fr ircd.east.gblx.net)
<-- stalker has quit (irc.isdnet.fr ircd.east.gblx.net)
<-- dd2 has quit (irc.isdnet.fr ircd.east.gblx.net)
<-- d4 has quit (irc.isdnet.fr ircd.east.gblx.net)
--> EvilPete (h0h0magic@elvis.mu.org) has joined #kernelsummit
--> bright (bright@sneakerz.org) has joined #kernelsummit
--> winter_ (winter@sasami.jurai.net) has joined #kernelsummit
--> stalker (stalker@feerbsd.org) has joined #kernelsummit
--> dd2 (dima@blitzkrieg.blackened.com) has joined #kernelsummit
--- irc.exodus.net gives channel operator status to EvilPete
--- irc.exodus.net gives channel operator status to bright
--- irc.exodus.net gives channel operator status to winter_
--- irc.exodus.net gives channel operator status to dd2
--> Debolaz (~debolaz@c224s39h16.upc.chello.no) has joined #kernelsummit
--> ems (~kaworu@209-6-248-16.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com) has joined #kernelsummit
<ems> hey
<-- ems has quit (ircd.east.gblx.net irc.emory.edu)
--> ems (~kaworu@209-6-248-16.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com) has joined #kernelsummit
<-- Debolaz has quit (Read error: 54 (Connection reset by peer))
--> Debolaz (~debolaz@c224s39h16.upc.chello.no) has joined #kernelsummit
<-- tmm3 has quit (Ping timeout: 180 seconds)
--> tmm3 (kzzlhk@p3E9C2FFD.dip.t-dialin.net) has joined #kernelsummit
<-- tmm3 has quit (Ping timeout: 180 seconds)
--> tmm3 (pfolmj@p3E9C2FFD.dip.t-dialin.net) has joined #kernelsummit
--- tmm3 is now known as tmm_
<-- ems has quit (ircd.east.gblx.net irc.emory.edu)
--> ems (~kaworu@209-6-248-16.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com) has joined #kernelsummit
--> rene (~rene@canyon.xs4all.nl) has joined #kernelsummit
<-- rene has quit (Client Exiting)
<-- tmm_ has quit (Ping timeout: 180 seconds)
--> tmm_ (ttlnzl@p3E9C2FFD.dip.t-dialin.net) has joined #kernelsummit
<-- Debolaz has quit (Read error: 54 (Connection reset by peer))
--> Debolaz (~debolaz@c224s39h16.upc.chello.no) has joined #kernelsummit
<-- ems has quit (ircd.east.gblx.net irc.emory.edu)
--> ems (~kaworu@209-6-248-16.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com) has joined #kernelsummit
<-- tmm_ has quit (sleep)
<-- Debolaz has quit (irc.isdnet.fr irc.homelien.no)
<-- dd2 has quit (http://www.blackened.com/blackened/)
<-- stalker has quit (irc.exodus.net irc.mcs.net)
<-- ems has quit (ircd.east.gblx.net irc.emory.edu)
<-- EvilDES has quit (Ping timeout: 339 seconds)
--> EvilDES_ (des@flood.ping.uio.no) has joined #kernelsummit
<-- EvilDES_ has quit (efnet.demon.co.uk irc.light.se)
<-- adrian has quit (efnet.demon.co.uk irc.light.se)
<-- Keltia has quit (efnet.demon.co.uk irc.light.se)
--> adrian (adrian@node16292.a2000.nl) has joined #kernelsummit
--> Keltia (roberto@brasil.brainstorm.fr) has joined #kernelsummit
--- irc.isdnet.fr gives channel operator status to adrian
--- irc.isdnet.fr gives channel operator status to Keltia
<-- adrian has quit (irc.exodus.net irc.isdnet.fr)
<-- Keltia has quit (irc.exodus.net irc.isdnet.fr)
--> adrian (adrian@node16292.a2000.nl) has joined #kernelsummit
--> Keltia (roberto@brasil.brainstorm.fr) has joined #kernelsummit
--- irc.isdnet.fr gives channel operator status to adrian
--- irc.isdnet.fr gives channel operator status to Keltia
--> EvilDES_ (des@flood.ping.uio.no) has joined #kernelsummit
<-- EvilPete has quit (irc.exodus.net ircd.lightning.net)
<-- bright has quit (irc.exodus.net ircd.lightning.net)
<-- winter_ has quit (irc.exodus.net irc.east.gblx.net)
--> EvilPete (h0h0magic@elvis.mu.org) has joined #kernelsummit
--> bright (bright@sneakerz.org) has joined #kernelsummit
--- ircd.lightning.net gives channel operator status to EvilPete
--- ircd.lightning.net gives channel operator status to bright
--- bright is now known as zb^tang
--> Debolaz (~debolaz@c224s39h16.upc.chello.no) has joined #kernelsummit
<-- Debolaz has quit (Read error: 54 (Connection reset by peer))
--> Debolaz (~debolaz@c224s39h16.upc.chello.no) has joined #kernelsummit
<-- Debolaz has quit (Ping timeout: 180 seconds)
<-- EvilDES_ has quit (Ping timeout: 355 seconds)
--> EvilDES (des@des.no) has joined #kernelsummit
--> DebolazIW (~debolaz@novus.debolaz.com) has joined #kernelsummit
--> ems (~kaworu@209-6-248-16.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com) has joined #kernelsummit
--> MdocGuard (ircxaf@whale.sunbay.crimea.ua) has joined #kernelsummit
<-- MdocGuard (ircxaf@whale.sunbay.crimea.ua) has left #kernelsummit
<-- ems has quit (ircd.east.gblx.net irc.emory.edu)
--> ems (~kaworu@209-6-248-16.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com) has joined #kernelsummit
--> missnglnk (missnglnk@hydrant.informationwave.net) has joined #kernelsummit
--> kmissngln (missnglnk@hydrant.informationwave.net) has joined #kernelsummit
<-- missnglnk has quit (Read error: 54 (Connection reset by peer))
--- kmissngln is now known as missnglnk
--> Debolaz (~debolaz@c224s39h16.upc.chello.no) has joined #kernelsummit
<-- Debolaz has quit (Read error: 54 (Connection reset by peer))
--> Debolaz (~debolaz@c224s39h16.upc.chello.no) has joined #kernelsummit
<-- missnglnk has quit (ircd.lightning.net ircd.solidstreaming.net)
--> missnglnk (missnglnk@hydrant.informationwave.net) has joined #kernelsummit
<-- EvilDES has quit (ircd.lightning.net ircd.east.gblx.net)
<-- missnglnk has quit (irc.exodus.net ircd.lightning.net)
<-- zb^tang has quit (irc.exodus.net ircd.lightning.net)
<-- EvilPete has quit (irc.exodus.net ircd.lightning.net)
<-- ems has quit (irc.hub.uk irc.exodus.net)
--> zb^tang (bright@sneakerz.org) has joined #kernelsummit
--> missnglnk (missnglnk@hydrant.informationwave.net) has joined #kernelsummit
--> EvilPete (h0h0magic@elvis.mu.org) has joined #kernelsummit
--> EvilDES (des@des.no) has joined #kernelsummit
--- irc.light.se gives channel operator status to zb^tang
--- irc.light.se gives channel operator status to EvilPete
<-- missnglnk has quit (irc.light.se ircd.east.gblx.net)
<-- zb^tang has quit (irc.light.se ircd.east.gblx.net)
<-- EvilPete has quit (irc.light.se ircd.east.gblx.net)
--> zb^tang (bright@sneakerz.org) has joined #kernelsummit
--> EvilPete (h0h0magic@elvis.mu.org) has joined #kernelsummit
--- irc.exodus.net gives channel operator status to zb^tang
--- irc.exodus.net gives channel operator status to EvilPete
<-- zb^tang has quit (irc.exodus.net ircd.lightning.net)
<-- EvilPete has quit (irc.exodus.net ircd.lightning.net)
--> EvilPete (h0h0magic@elvis.mu.org) has joined #kernelsummit
--> missnglnk (missnglnk@hydrant.informationwave.net) has joined #kernelsummit
--> zb^tang (bright@sneakerz.org) has joined #kernelsummit
--- ircd.lightning.net gives channel operator status to EvilPete
--- ircd.lightning.net gives channel operator status to zb^tang
--> nik (nik@10.0.2.99) has joined #kernel-summit --- You have left channel #kernel-summit --> nik (nik@10.0.2.99) has joined #kernelsummit --> peter (peter@10.0.1.171) has joined #kernelsummit --> rwatson (rwatson@10.0.1.103) has joined #kernelsummit <BigSpoon> foo <rwatson> bar --- Disconnected (Remote host closed socket). --> nik (nik@10.0.2.99) has joined #kernelsummit <nik> Bing --- rwatson has changed the topic to: -- --> bsdimp (imp@10.0.2.110) has joined #kernelsummit --- rwatson has changed the topic to: n/a --> BigSpoon (john@10.0.1.125) has joined #kernelsummit <BigSpoon> _ _ _ <BigSpoon> _ __ ___| |_ ___ _ __ (_)___ | | __ _ _ __ ___ ___ <BigSpoon> | '_ \ / _ \ __/ _ \ '__| | / __| | |/ _` | '_ ` _ \ / _ \ <BigSpoon> | |_) | __/ || __/ | | \__ \ | | (_| | | | | | | __/ <BigSpoon> | .__/ \___|\__\___|_| |_|___/ |_|\__,_|_| |_| |_|\___| <BigSpoon> |_| <bsdimp> exec -o banner bigknife sucks <rwatson> ____ _ ____ _ <rwatson> | __ ) (_) __ _ / ___| _ __ ___ _ __ | | __ __ __ __ _ ___ <rwatson> | _ \ | | / _` |\___ \ | '_ \ / _ \ | '__|| |/ / \ \ /\ / // _` |/ __| <rwatson> | |_) || || (_| | ___) || |_) || (_) || | | < \ V V /| (_| |\__ \ <rwatson> |____/ |_| \__, ||____/ | .__/ \___/ |_| |_|\_\ \_/\_/ \__,_||___/ <rwatson> |___/ |_| <rwatson> _ <rwatson> | |__ ___ _ __ ___ <rwatson> | '_ \ / _ \| '__|/ _ \ <rwatson> | | | || __/| | | __/ <rwatson> |_| |_| \___||_| \___| <rwatson> <rwatson> child death --> fenestro (fenner@10.0.1.84) has joined #kernelsummit --> awfulhak (brian@10.0.1.106) has joined #kernelsummit --> ems (ems@10.0.1.30) has joined #kernelsummit <fenestro> It's good that we're spending time on the *important* stuff now =) <ems> indeed <BigSpoon> fenestro: of course <fenestro> Wait, maybe we can do a SecureDNS testbed while we're at it <-- dfr has quit (using sirc version 2.211+KSIRC/1.1) <rwatson> fenestro: hmm. I have bind9 here and some secure zones... <rwatson> fenestro: however, various versions of BIND barf on various zone files, so I don't know if they work together --> dfr (dfr@10.0.1.4) has joined #kernelsummit <fenestro> and we can all update our resolver libraries <bsdimp> 5.0 <bsdimp> set -market-speek jkh <bsdimp> deadline reason: <bsdimp> Novemeber <bsdimp> likely won't slip. <bsdimp> 5.0 cuts off features way before --> msmith (msmith@10.0.128.255) has joined #kernelsummit <msmith> Fnord --> julian (julian@10.0.1.1) has joined #kernelsummit <julian> ahah! <awfulhak> dns at 10.0.1.171 <bsdimp> FreeBSD-5.0-TRIAL-BALLOON <rwatson> bsdimp: FreeBSD-5.0-BUBBLE-BURST <msmith> FreeBSD-5.0-FREE-DRUG-TRIAL <bsdimp> branch 5.1 or 5.2 time frame <msmith> Consider the 3.x/4.x branch, what did we learn from it? <rwatson> msmith: nothing? <bsdimp> We rushed that branch a little so mdillon could get stuff into -current that we didn't want in 3.x <msmith> Ouch. Probably more true than any of us would like to agree with. <julian> no, in 3.0 we branched too early <bsdimp> We branched around 3.1 and should have done it than 3.2 <msmith> julian: not suggesting we should do the same as with 3.0, just wondering if we learnt anything. --> jkh (jkh@10.0.1.180) has joined #kernelsummit <bsdimp> banches suck <BigSpoon> bsdimp: in cvs <awfulhak> What's a banch ? <msmith> ie. we need to spend 6-9-12 months in "customer focus" mode <bsdimp> p4 <julian> "rearchitecting" is not english... <julian> try "redesigning" <BigSpoon> p4.. hmmm --> keichii (keichii@10.0.3.33) has joined #kernelsummit <-- keichii has quit (User abort with 5 Ctrl-C's) <bsdimp> ABI? When is it stable? --> keichii (keichii@10.0.3.33) has joined #kernelsummit <bsdimp> SO implications? <awfulhak> Oops, that dns is on 10.0.1.106 ! <-- keichii has quit (Read error: 0 (Undefined error: 0)) <msmith> We're typically pretty anal about interface consistency anyway... * jkh agrees --> keichii (keichii@10.0.3.33) has joined #kernelsummit <BigSpoon> major API changes by 5.0 <-- keichii has quit (BitchX: so real, you'll wet yourself!) --> keichii (keichii@10.0.3.33) has joined #kernelsummit <msmith> K PLS NEW DEFECT MANAGEMENT SYSTEM K THX <BigSpoon> msmith: T <foo> <julian> this is core stufff, nt kernel.... <BigSpoon> well <julian> oops NOT kenrel <julian> kernel <BigSpoon> there are several things that need discussion <nik> One good thing about GNATS. You can mirror the PR database locally, and work offline. <msmith> nik: you can do this with Keystone as well, just mirror the mysql database <nik> msmith: And run a local copy of mysql. . . ugh <bsdimp> projects.freebsd.org <bsdimp> Need a maintainer <ems> projects.freebsd.org, I could help with that? <bsdimp> send mail to core. <ems> ok <msmith> ems: that'd be handy, thanks <ems> Alright, I'll send it when I get 'ome :-) <msmith> ems: it needs proactive maintenance, some development and active advocation. <ems> msmith: I'm quite interested in development <msmith> Cool. We've smacked our heads against project management issues so many times, and always fallen short. <bsdimp> 200M into flash <ems> Heh <msmith> Meta-organisation is not "sexy" for kernel developers. 8) <bsdimp> 5 iso <msmith> bsdimp: IBM 1GB Microdrive <-- awfulhak has quit (Client Exiting) <bsdimp> heheh <bsdimp> msmith: You can get 2G pcmcia ata cards <bsdimp> 1 minisio <bsdimp> 4 packages iso <bsdimp> a bunch of other huge set of packages <msmith> T JKH DONUT DISCUSS SYSINSTALL, SPEAK NO EVIL OF THE DEAD K THX <BigSpoon> sysinstall < * <julian> Errrrr is this kernel relavent? <msmith> julian: 5.0 tangent, needs to get reined in. <msmith> Oh great. FreeBSD System Base. <julian> hey ENOUGH ALREADY! <msmith> Er, no they haven't. <msmith> Laser-5, PHT, Cheapbytes, etc. <BigSpoon> yah <bsdimp> Those are releases of FreeBSD. <bsdimp> They aren't "official" <BigSpoon> dang it <bsdimp> small semantics <BigSpoon> I have to go the restroom <msmith> bsdimp: er, yes, they're all the same thing <BigSpoon> make em talk about KSE <bsdimp> on to kse --> awfulhak (brian@10.0.1.106) has joined #kernelsummit <bsdimp> hmmm darwin <awfulhak> darn-bsd <bsdimp> kse: system calls become async <bsdimp> all things become simple kse. <bsdimp> every time something blocks, it comes back to the same place. <msmith> Very similar to the way that v86 mode works. <bsdimp> proc -> 4 different procs <bsdimp> Proc currently owns all the resources <BigSpoon> ems: ? <BigSpoon> grr <BigSpoon> msmith: ? <ems> ems: what? <rwatson> hmm, guess I'll wait for the intro to stop before asking a question <bsdimp> next thing owns scheduling info <rwatson> note that this user credential behavior is incompatible with threading model on linux <bsdimp> kseg s what is called <bsdimp> kseG <rwatson> note kseg name conflict <BigSpoon> rwatson: creds are per-thread? <bsdimp> kse <-- jkh has quit (Read error: 0 (Undefined error: 0)) <bsdimp> kse an empty shell onto which things are loaded to run <BigSpoon> bsdimp: include descriptors <BigSpoon> oh, you are, nm <rwatson> BigSpoon: in linux, yes <rwatson> evil stuff <msmith> BigSpoon: you call in to the kernel to "activate" the mechanism, and a copy is made of the return context for the call. <bsdimp> kse provides the parallelisation <bsdimp> system call contexts get loaded into kse <msmith> BigSpoon: the 'return context' is then recycled every time you want to re-enter the original caller. <bsdimp> ksec <BigSpoon> msmith: ah, yes, like the vm86 syscall stuff then <bsdimp> <note names may change> * ems is taking notes in latex, will post dvi if anyone wants it later <bsdimp> ksec: kern stack <msmith> ems: K THX <bsdimp> ksec all state of blocked and running <rwatson> LaTeX perhaps <BigSpoon> ems: spiff <nik> ems: dillon is taking notes in plain text. .. <BigSpoon> latex would be good, too <ems> nik: oh, whatever is easier <nik> ems: dillon is taking excessive notes. <ems> nik: Ok <BigSpoon> we can't have too many notes <rwatson> sorry, who is ems? * msmith ponders why the kse/ksec division, since a ksec is just the saved contents of a kse... <bsdimp> New systemcall. <bsdimp> name to follow. <bsdimp> msmith I wondered too <ems> heh <ems> I'm the openroot guy ;p <BigSpoon> msmith: you tie one of them to cpu's <rwatson> ems: sorry, didn't recognize you <BigSpoon> the other is per-thread <ems> rwatson: s'allright <ems> :) <rwatson> ems: have your paper printed out over here :-) <ems> ems: Ok <BigSpoon> you can have more ksec's than kse's if you have more threads than runnable scheduler contexts <msmith> BigSpoon: so you can partition threads vs. CPUs? <ems> ack <ems> rwatson: cool, how did you like it? <msmith> BigSpoon: Unf. So the KSE is just a big way of storing an integer? <BigSpoon> well... --> jkh (jkh@10.0.128.254) has joined #kernelsummit <jkh> foo <BigSpoon> it stoers the context while you run on a cpu <peter> julian is explaining this badly <bsdimp> typedef int kse; <rwatson> ems: needs some tweaking, of course, but looks like a good start. Probably best to take to e-mail over the next week. * jkh falls slowly onto his keyboard <ems> rwatson: alright, will do. <msmith> I think we want to discuss this, not have it explained. <rwatson> jkh: we need terminology fixes, this is confusing <BigSpoon> but if the process isn't using up all its' available kse's, you may have idle kse's not attached to any threads (ksecs) <msmith> Since most of us that need to understand it already do. <BigSpoon> I think <rwatson> jkh: everything is a KSEFOO <jkh> high level discussion PLZ K TNX <jkh> %3GREEN%0 <bsdimp> fred <fenestro> okbye <-- fenestro has quit (Client Exiting) <-- BigSpoon has quit (new kernel) <rwatson> beep goes new-kernel boy <msmith> Mm, ok, so userland components don't present a threat to the kernel <jkh> crash crash goes new kernel boy <ems> eh <rwatson> msmith: sounds good to me --> BigSpoon (john@10.0.1.123) has joined #kernelsummit * bsdimp nominates BigSpoon for head cat hearder <msmith> rwatson: indeed; that was my major concern * jkh notes that BigSpoon IS the head cat herder here - this is his meeting. :) <keichii> will we encounter the same problem with KQ? * jkh prods BigSpoon to Assert More Effective Leadership <keichii> in that no one wants to do the mechanical work of converting userland to KSE/KQ <msmith> T BIGSPOON TOO TECHNICAL K THX <msmith> keichii: Hopefully not. <msmith> keichii: since userland doesn't need to be "converted" <msmith> keichii: This is an assist for code that is already threaded. <keichii> right <BigSpoon> this is a technical meeting <-- dfr has quit (this is a technical meeting) * rwatson notes he would slap in another month of dev time based on locking concerns. <msmith> BigSpoon: ... not a classroom. --> dfr (dfr@10.0.1.4) has joined #kernelsummit * BigSpoon notes this is going to wreak hell on proc locking <rwatson> BigSpoon: exactyl <peter> BigSpoon: actually, it is a mechanical hell, not a strategic hell. <rwatson> BigSpoon: you probably have hold the proc lock to get to the proc lock <BigSpoon> peter: no, not really <rwatson> :-) * msmith wants a way of attaching a warning to a preprocessor macro expansion <BigSpoon> peter: cause the locking strategies change <peter> BigSpoon: lets talk about it after, I'm not sure it's that big.. <BigSpoon> peter: it's not huge <BigSpoon> but it's different <BigSpoon> would be easier to get it done before changing midstream <rwatson> BigSpoon: well, certainly better to do now than later... <BigSpoon> rwatson: not if I haev to go back and redo half the stuff I've done <rwatson> BigSpoon: better to get it done before 5.0-RELEASE than after <msmith> T NIK PLS COFFEE? BEG GROVEL ETC K THX <nik> msmith: Black, white, sugar? <msmith> nik: NATO standard (white, two) <rwatson> XF864 sounds good to me, hope they fix the configurator <msmith> rwatson: X -configure good <keichii> hmm, are we going to address some administrative issues? <rwatson> msmith: dunno, on this notebook, it would exit whenever run <msmith> keichii: project admin? We can probably workshop that. * msmith worship nik <nik> We're out of coffee <jkh> catastrophe! <keichii> it's only $33, somebody else pay for it? <jkh> well, this meeting is only scheduled for another 10 minutes. :) <keichii> oh, didnt realize that time flies by <ems> hrm, I thought the meeting ended at five? <jkh> even if we run 40 minutes over, we can still get good coffee downstairs <jkh> hurm <jkh> I thought 11-4 <jkh> maybe just wishful thinking <nik> jkh: Downstairs does not have good coffee <ems> heh <jkh> I'm talking about the cappucino place <jkh> gourmet bean <ems> Expensive? <jkh> their latte isn't bad <keichii> bah humbug <msmith> Mm. humugs. <msmith> Er, Humbugs. * rwatson wonders if BigKnife knows he is the SMPng manager yet. <jkh> bigknife was supposed to know that the minute jason quit <julian> AAAAAARGGGHHHH!! There is no such word as "Architecting".. try "Designing" !!!!!! <rwatson> BigKnife: we expect you to talk about the general status of SMPng, and the remaining components requiring locking, plus tell us about tasks not getting done. * BigSpoon hates managing * jkh prods BigSpoon <rwatson> BigSpoon: you are the "technical manager" <jkh> manage! manage! * jkh chases BigSpoon around with the hair-shaping helmet <BigSpoon> you suck * jkh notes that BigSpoon doesn't have enough hair to point up properly * jkh gets a wig and some hairspray * jkh shoots groggy also <jkh> BigSpoon: T PLZ NO PERFORMANCE DEBATE AT THIS TIIME K PLZ TNX * BigSpoon detaches to write down some quick notes * jkh hands BigSpoon his favorite .44 magnum <rwatson> BigSpoon: change topic to remaining technical goals for smpng * nik submits "K PLZ TNX" to esr for the hackers handbook <BigSpoon> rwatson: maybe if I knew it all in detail <rwatson> BigSpoon: where you don't have detail, assert as much. <jkh> BIGSPOON <ems> su <ems> argh <peter> Password: <rwatson> Permission denied. <nik> # <msmith> NO CARRIER <rwatson> OK <ems> dare i say 0wned? <keichii> hmm <nik> openroot <ems> yes openroot <keichii> isnt this a regression test and performance benchmark thing? <keichii> i think this requires a quantitative measurement <msmith> keichii: not really, this is a "when do we go to -STABLE" question. <msmith> keichii: um, yeah, so yes, actually. 8) <keichii> so, set a quantitative goal of performance gain? <BigSpoon> it has not to be worse than 4.x at the very least <keichii> or lowest limit of pessimization <keichii> there, we have a goal <nik> BigSpoon: 4.x on multi-processor, or 4.x on uni-processor? <BigSpoon> both <keichii> now, several usual benchmarks exist <msmith> nik: uniprocessor *has* to be "no worse" <keichii> networking performance, and make world time <bsdimp> hmmm vm lock <jkh> ls -la <jkh> whoops <nik> <Left 30 pixels> <Up 25 pixels> <click> <nik> Oops <rwatson> rm -Rf / <rwatson> oops <ems> cowsay -f jkh.cow <keichii> figlet <keichii> oops <keichii> shall we set a performance goal now? <rwatson> n o <keichii> a quantitative one... <keichii> for 5.0 <rwatson> performance testing first <bsdimp> yes. <bsdimp> No worse than 2x slower. <keichii> bsdimp: ..... <bsdimp> Or 3x slower <keichii> i am not saying that we should have a 50000% performance gain. :Q <bsdimp> vfs. <bsdimp> Evil. <bsdimp> Run. <bsdimp> Flee <bsdimp> Panic. <jkh> the kernel should run at a performance level > 0 <awfulhak> jkh: before or after 5.0 ? <bsdimp> buffer cache <jkh> e.g. it shouldn't halt periodically <bsdimp> tty * msmith bends bsdimp over and inserts the cardbus lock <keichii> usb? <msmith> keichii: most of that stuff is relatively straightforward because you have a single "owner" of the device subtree <keichii> well, if you eliminate those, then we dont really have much left <msmith> Mm. <bsdimp> I thought cardbus was already locked. <msmith> bsdimp: and loaded, I think. <bsdimp> But if not, then that's part of newcard enhancement. <msmith> Yeah. I'm just pondering how tightly it's worth locking the device tree. <awfulhak> msmith: Do you want that archive that I haven't got ? <bsdimp> msmith: There's some interrupt blocking code that neds to happen. <bsdimp> And also some "am I there" interface for isrs <-- keichii has quit (bye bye bye) <msmith> bsdimp: yeah, but I think that's orthogonal to locking the device tree as a whole. <bsdimp> right. <BigSpoon> cardbus locking is all screwed upp <bsdimp> BigSpoon: eh? <dfr> device tree should just get a code lock <bsdimp> BigSpoon: how is cardbus locking all screwed up. <BigSpoon> well, the pccbb mutex is <BigSpoon> :) <msmith> dfr: code lock, or just have a lock that covers the entire device tree? <bsdimp> ah. <bsdimp> that's evil. <BigSpoon> code lock? <BigSpoon> ou could use an sx lock to protect the device tree if you want <peter> BigSpoon: the problem is that if you insert a pccard code, it gets removed as a cardbus card. :-) <BigSpoon> hahahahaahahaaha <bsdimp> yes. That sucks too. * rwatson fears. <bsdimp> phear the cardbus <bsdimp> phear NEWCARD <bsdimp> lower expectations. * rwatson adds some items to lost cause list: irda, firewire, ... <BigSpoon> peter: sounds like mroe mb,bpos vs. md,dpos tyle bugs :) * peter feared the 'printf CARD_DELETE_CARD(cbdev)' (not pccarddev) when he ejected the pccard card. <BigSpoon> rwatson: SMP.. <rwatson> /kick BigSpoon <rwatson> BigSpoon: AXP... <BigSpoon> /kick rwatson <BigSpoon> vm_mtx :) <bsdimp> IrDA is a big rat hole * rwatson watches EvilPete's machine crash on mention of AlfredEvil <BigSpoon> hehehehehhehehehehe <peter> aargh! * BigSpoon sprinkles some PWMF dust on imp's laptop <peter> I'll remind you that my machine has a dirct murphey-field connection to all yours via the power connections... (and wavelan) <rwatson> julian is driving <rwatson> (irda) <ems> flee! <-- ems has quit (My damn controlling terminal disappeared!) <bsdimp> flee <msmith> /usr/sbin/laptop_emp * <-- jkh has quit (ircII+tkirc2) <bsdimp> log done <-- bsdimp has quit (Client Exiting) <-- msmith has quit (ircII/tkirc) <-- dfr has quit (using sirc version 2.211+KSIRC/1.1) <-- BigSpoon has quit (oblivion/1.0c1 epic4-0.9.2 - the lost souls of time..envy life.) <-- rwatson has quit (awf) <-- awfulhak has quit (Client Exiting)