Current List of Kernel Summit suggested topics from the discuss list - Kernel

This is a discussion on Current List of Kernel Summit suggested topics from the discuss list - Kernel ; 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 ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Current List of Kernel Summit suggested topics from the discuss list

  1. Current List of Kernel Summit suggested topics from the discuss list

    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


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [Ksummit-2008-discuss] Current List of Kernel Summit suggested topics from the discuss list

    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.


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [Ksummit-2008-discuss] Current List of Kernel Summit suggested topics from the discuss list

    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


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [Ksummit-2008-discuss] Current List of Kernel Summit suggested topics from the discuss list

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [Ksummit-2008-discuss] Current List of Kernel Summit suggested topics from the discuss list

    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.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: Current List of Kernel Summit suggested topics from the discuss list

    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

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [Ksummit-2008-discuss] Current List of Kernel Summit suggested topics from the discuss list

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [Ksummit-2008-discuss] Current List of Kernel Summit suggested topics from the discuss list

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [Ksummit-2008-discuss] Current List of Kernel Summit suggested topics from the discuss list

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: Current List of Kernel Summit suggested topics from the discuss list

    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 <><
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [Ksummit-2008-discuss] Current List of Kernel Summit suggested topics from the discuss list

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [Ksummit-2008-discuss] Current List of Kernel Summit suggested topics from the discuss list

    On Thu, 3 Jul 2008 11:27:07 -0700 Greg KH 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 sfr@canb.auug.org.au
    http://www.canb.auug.org.au/~sfr/

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkhtZ8sACgkQjjKRsyhoI8xkogCfSwoN4nguqU f6Z187wyLr6i6P
    p1EAn2EJ5sTE56ZdWTYcUDpVU2oLzYV1
    =M89U
    -----END PGP SIGNATURE-----


+ Reply to Thread