Hi All,
This is the synopsis of the currently suggested topics so far. That's
not to say this is the list we will be doing, just to say that if
there's something you think we should be discussing and it's not on the
list, now would be a good time to add it (don't trust the programme
committee magically to add it at the last minute ...)
James
---
Meta Topics:
1. Do KS as an unconference - Matthew Wilcox
2. Do a Mini Hackfest for 50% of the time - Greg KH
3. Expand to three days and do Tech/Process/Tech on each day - Dave
Miller
Agenda Topics:
1. Asynchronous Operations - Ulrich Drepper
* How do we make programs more parallel (driven by
multicore)
* Can we use tasklets for this
2. Fixing the Kernel Janitor's Project - James Bottomley
* KJ Isn't a good intro to kernel hacking, need better
ones like bug finding and fixing.
* Need to find more ways for non coders to make useful
contributions
* Need to think more about what 'useful contributions' are
* What about the kernel tester's project [Adrian Bunk]
3. Moving firmware Blobs out of the Kernel - David Woodhouse
* remove all firmware and repackage in ways that would
either be pulled in at runtime or could be linked into
the kernel (distro choice)
* Need to be careful about licensing compatibility
* Where should we actually keep the extracted firmware
4. Barriers - Neil Brown
* Need to define what semantics filesystems actually want
* Need to relate this to what devices and subsystems can
actually provide.
5. Tracking Regressions - Rafael Wysocki
* Describe experiences with the current running of the
regression lists
* How could we make the current list and practice more
useful
6. Discuss new Suspend/Resume Framework - Rafael Wysocki
* Discuss semantics of what drivers should be expecting
and what best practices are.
* Need better documentation on this
* can we make subsystem libraries of helpers for their
driver suspend/resume to ease the pain?
7. Hack/Fix session for Laptop Suspend and NOHZ/idle - Thomas
Gleixner
* Perhaps this should be done at Plumbers instead
8. Content Accessed Filesystems - Lars Noschinski
* Filesystem that would store the same block only once
* Would be useful for git [Pavel Machek]
9. When should Drivers be Merged - James Bottomley
* Options seem to be ASAP, Wait for a bit for it to
mature, when the vendor has fixed the obvious bugs
* Have a fast submission track for drivers for which the
hardware documentation is available [Tony Luck]
* Run driver submissions early through staging trees while
they get fixed
* How should these be run? Centrally or in
subsystem trees
* Should staging trees be part of linux-next
James Bottomley wrote:
> Hi All,
>
> This is the synopsis of the currently suggested topics so far. That's
> not to say this is the list we will be doing, just to say that if
> there's something you think we should be discussing and it's not on the
> list, now would be a good time to add it (don't trust the programme
> committee magically to add it at the last minute ...)
>
> James
>
I'd like to propose a topic about kernel quality; there's been a lot of
lkml traffic about it (in ups and downs). As part of this topic I could present
trends, data and conclusions from the kerneloops.org project. I'm sure Andrew has
a set of data and views from his part of the world, and the regressions topic
could fall under this too. If we, unlike last year, ask various subsystem maintainers
to prepare data or at least something more solid than "eh I think we're fine" ahead of the
conference, we could have a more thought out set of inputs from that direction as well.
On Fri, 2008-06-27 at 07:53 -0700, Arjan van de Ven wrote:
> James Bottomley wrote:
> > Hi All,
> >
> > This is the synopsis of the currently suggested topics so far. That's
> > not to say this is the list we will be doing, just to say that if
> > there's something you think we should be discussing and it's not on the
> > list, now would be a good time to add it (don't trust the programme
> > committee magically to add it at the last minute ...)
> >
> > James
> >
>
> I'd like to propose a topic about kernel quality; there's been a lot of
> lkml traffic about it (in ups and downs). As part of this topic I could present
> trends, data and conclusions from the kerneloops.org project. I'm sure Andrew has
> a set of data and views from his part of the world, and the regressions topic
> could fall under this too. If we, unlike last year, ask various subsystem maintainers
> to prepare data or at least something more solid than "eh I think we're fine" ahead of the
> conference, we could have a more thought out set of inputs from that direction as well.
Really, then you want this topic:
> 5. Tracking Regressions - Rafael Wysocki
> * Describe experiences with the current running of the
> regression lists
> * How could we make the current list and practice more
> useful
broadened to include all quality issues?
James
On Friday, 27 of June 2008, James Bottomley wrote:
> On Fri, 2008-06-27 at 07:53 -0700, Arjan van de Ven wrote:
> > James Bottomley wrote:
> > > Hi All,
> > >
> > > This is the synopsis of the currently suggested topics so far. That's
> > > not to say this is the list we will be doing, just to say that if
> > > there's something you think we should be discussing and it's not on the
> > > list, now would be a good time to add it (don't trust the programme
> > > committee magically to add it at the last minute ...)
> > >
> > > James
> > >
> >
> > I'd like to propose a topic about kernel quality; there's been a lot of
> > lkml traffic about it (in ups and downs). As part of this topic I could present
> > trends, data and conclusions from the kerneloops.org project. I'm sure Andrew has
> > a set of data and views from his part of the world, and the regressions topic
> > could fall under this too. If we, unlike last year, ask various subsystem maintainers
> > to prepare data or at least something more solid than "eh I think we're fine" ahead of the
> > conference, we could have a more thought out set of inputs from that direction as well.
>
> Really, then you want this topic:
>
>
> > 5. Tracking Regressions - Rafael Wysocki
> > * Describe experiences with the current running of the
> > regression lists
> > * How could we make the current list and practice more
> > useful
>
> broadened to include all quality issues?
That would be fine by me.
Thanks,
Rafael
On Fri, Jun 27, 2008 at 09:41:49AM -0500, James Bottomley wrote:
> 8. Content Accessed Filesystems - Lars Noschinski
> * Filesystem that would store the same block only once
> * Would be useful for git [Pavel Machek]
This is an intersting research topic, but nothing that needs to be
discussed at KS. It's a pure filesystem implementation issue, and
not a kernel-wide dsicussion item.
On Fri, Jun 27 2008, James Bottomley wrote:
> 4. Barriers - Neil Brown
> * Need to define what semantics filesystems actually want
> * Need to relate this to what devices and subsystems can
> actually provide.
Again? Barriers must be the most persistent topic at the kernel summit,
yet nothing has happened since my initial implementation back in 2001 or
so! :-)
This being a fairly wide and technical topic, I think it's actually
better suited for mailing list discussion for starters.
--
Jens Axboe
On Friday, June 27, 2008 7:53 am Arjan van de Ven wrote:
> James Bottomley wrote:
> > Hi All,
> >
> > This is the synopsis of the currently suggested topics so far. That's
> > not to say this is the list we will be doing, just to say that if
> > there's something you think we should be discussing and it's not on the
> > list, now would be a good time to add it (don't trust the programme
> > committee magically to add it at the last minute ...)
> >
> > James
>
> I'd like to propose a topic about kernel quality; there's been a lot of
> lkml traffic about it (in ups and downs). As part of this topic I could
> present trends, data and conclusions from the kerneloops.org project. I'm
> sure Andrew has a set of data and views from his part of the world, and the
> regressions topic could fall under this too. If we, unlike last year, ask
> various subsystem maintainers to prepare data or at least something more
> solid than "eh I think we're fine" ahead of the conference, we could have a
> more thought out set of inputs from that direction as well.
I think this could be an interesting topic, as long as we have data like what
you collect at kerneloops.org. Unfortunately, data for other stuff is harder
to come by.
Another question this raises is how we define "quality". Is it simply having
a low bug count? Or just having few bugs that affect large numbers of
people? Given that we'll always have bugs though, we could also measure
quality in terms of how effectively we handle bugs, e.g. how quickly fixes
are proposed and integrated, how well we work with distros to incorporate
fixes for their high priority issues, etc.
If we measure quality using bug metrics, things are pretty hard. We have
kerneloops.org which tracks one class if issues, but there are so few bugs
filed at kernel.org, relative to other projects that use bug tracking
heavily, that for PCI at least I could only paint an anecdotal picture of
things (though we do have one fairly clear area of weakness that I've seen
based on my triaging). Contrast this to the Intel graphics projects at
freedesktop.org where we have a fairly large bug history and can say pretty
convincingly that things are improving a lot, and fairly rapidly.
I guess I'm saying this *could* be an interesting topic, but it could also be
the same discussion we've had for years, which never even reaches a
conclusion about whether we're improving or not.
Jesse
Jesse Barnes wrote:
> If we measure quality using bug metrics, things are pretty hard.
One problem with any metric is that the metric becomes a driving factor
in itself. Consider the whole whitespace issue, for example.
As far as the whitespace issue is concerned, we may want to consider
just setting a flag day -- probably immediately before an -rc1 release
-- and just run "cleanfile" on the whole tree. In-flux patches are
still appliable with "patch -l", and by now we should have enough tools
to avoid adding new whitespace problems, so we can just kill this issue
once and for all.
-hpa
On Friday, June 27, 2008 11:11 am H. Peter Anvin wrote:
> Jesse Barnes wrote:
> > If we measure quality using bug metrics, things are pretty hard.
>
> One problem with any metric is that the metric becomes a driving factor
> in itself. Consider the whole whitespace issue, for example.
Sure, but I don't think that's a reason to avoid metrics altogether. We've
already seen that purely qualitative discussions don't really get us
anywhere. For any discussion about kernel quality I think we have to:
a) define our goals (no oopses? fast bug fix turnaround? whatever)
b) define a way to measure progress against those goals
c) periodically re-evaluate both
I think all of these are fairly difficult tasks, and any goal or metric we
create will have problems, but does that mean we should just ignore quality?
Or limit ourselves to our current situation where everyone has a different
idea of what it means and whether we're achieving it?
Jesse
On Friday 27 June 2008, James Bottomley wrote:
> Agenda Topics:
>
> 1. Asynchronous Operations - Ulrich Drepper
> * How do we make programs more parallel (driven by
> multicore)
> * Can we use tasklets for this
I suppose you mean "threadlets" or "syslets" here, not "tasklets",
which are a kernel internal concept, right?
Arnd <><
On Fri, Jun 27, 2008 at 09:41:49AM -0500, James Bottomley wrote:
> Hi All,
>
> This is the synopsis of the currently suggested topics so far. That's
> not to say this is the list we will be doing, just to say that if
> there's something you think we should be discussing and it's not on the
> list, now would be a good time to add it (don't trust the programme
> committee magically to add it at the last minute ...)
Another proposal:
Working well with other subsystems - Jean Delvare
There are a number of times where different subsystems in the
kernel need to interact with each other in ways that are not
always easy or obvious. This talk will be about some examples
of how this has been done well, as well as work to figure out
how to handle this better in the future.
thanks,
greg k-h
On Thu, 3 Jul 2008 11:27:07 -0700 Greg KH <[email protected]> wrote:
>
> Another proposal:
>
> Working well with other subsystems - Jean Delvare
>
> There are a number of times where different subsystems in the
> kernel need to interact with each other in ways that are not
> always easy or obvious. This talk will be about some examples
> of how this has been done well, as well as work to figure out
> how to handle this better in the future.
Hear! Hear! :-)
This could be expanded into a general discussion of how to handle API
change in our distributed environment.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/