This month's meetings

<< <  2011 / 4 >  >>
Mon Tue Wed Thu Fri Sat Sun
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

Meeting info

  • Kernel WG meetings are conducted over IRC: #linaro-kernel on Freenode.


  • Arnd Bergmann:
  • Dave Martin: x
  • Deepak Saxena: x
  • Grant Likely:
  • Jason Hui:
  • John Stultz: x
  • Linus Walleij: x
  • Manjunath Kondaiah:
  • Mounir Bsaibes: x
  • Nicolas Pitre: x
  • Niklas Hernaeus: x
  • Rajendara Nayak: x
  • Thomas Abraham: x
  • Shawn Guo: s
  • Venkatraman Sathiyamoorthy: x


  1. Announcement / Upcoming Release Dates
  2. Pending Action items
  3. Around the table: Work Items updates, what's next
  4. BUGS review

Action Items from Previous Meeting


  • Discussed potential Orlando Linaro Connect Sessions, Deepak will create the initial sessions blueprint this week
    • Sessions suggested:
      • a session on the CI/testing thread
      • struct clk discussion
      • single kernel zimage
      • How to test the code we develop, sharing methotology with validation
      • session on mapping KWG work to Linaro process
      • session for android upstream projects?
      • private KWG session to go to go over all old technical requirement
      • dmart to ping the platform team and see if they want to schedule a session on vexpress deployment?
      • session covering KWG vision ??
      • Storage Work
      • UEFI
      • KVM
      • Secure World play
      • EMMC 4.5
      • DT 2-3 specific topics, like DT clock support is the next major DT item, DT binding for clock and pin control
      • debugging session OpenOCD, printascii, KGDB, KDB, lttng
      • DT BoF to discuss any issues converting platforms


  • dmart to ping the platform team and see if they want to schedule a session on vexpress deployment
  • Deepak to talk to toolchain group about OPENOCD, KGDB ...


 dsaxena ( has joined #linaro-kernel
* nhe ( has joined #linaro-kernel
* robher has quit (Ping timeout: 256 seconds)
<dsaxena> Good morning/afternoon/evening
<nhe> Hi.
<thomas-ab> Hi All
<jstultz_vm> dsaxena:  morning
<mounir> hi dsaxena
<linusw_> Hi
* robher (~rob@ has joined #linaro-kernel
* svenkatr (~svenkatr@nat/ti/x-hrzvuwmlfbsibsrv) has joined #linaro-kernel
<dsaxena> I hope everyone had a good weekend
<dsaxena> hi nhe thomas-ab jstultz_vm mounir linusw svenkatr
<npitre> hello there
<dsaxena> hi npitre
<dsaxena> For today's meeting from my end I mainly wanted to focus on Linaro Connect logistics
<dsaxena> and session planning
<dsaxena> First a couple of logistical items...
<dsaxena> - if you haven't booked flight/hotel/visa, please do so as soon as possible.
<dsaxena> flights from Europe to Floriday  really specially expensive this time of year
<dmart> hi all btw
<dsaxena> hi dmart
* rnayak (~a0131687@ has joined #linaro-kernel
<dsaxena> The way the event is organized is a mix of the traditional summit and last connect's hacking sessions
<dsaxena> we'll be spending the mornings in planning meetings and the afternoons focused on hacking
<dsaxena> we'll be sharing a room with the Power Management Working Group, so we may work on some stuff in unison with them (struct clk for example)
<dsaxena> I think we had some good ideas thrown out on the mailing list in regards to sessions, what I'd like to do now is have a go around and have folks share any other ideas they have
<dsaxena> this week I'll be creating session blue prints and assigning them to folks to fill in with details on what we'd be discussing at connect
<linusw_> dsaxena: question - will there be some subarch maintainers invited this time?
<dsaxena> linusw_, we've invited a few already
<dsaxena> the challenge is that many of them are going to Prague the week before for the ARM summit
<linusw_> dsaxena: OK all I needed to know...
<dsaxena> and two weeks of travel is not something all are willing to do (understandably)
<dsaxena> linusw_, ok
<dsaxena> npitre, want to start...any more ideas on session topics, any sessions you think are key or need more than 1 hr?
<linusw_> dsaxena: its just that it's quite nice to have them around :-)
* CosmicPenguin ( has joined #linaro-kernel
<dmart> dsaxena: a session on the CI/testing thread seems like a good idea
<npitre> current stumbling block is certainly the struct clk debate
<dsaxena> linusw_, agree
<dsaxena> npitre, amitk is planning on doing some hacking around that during the hacking sessions
<dsaxena> dmart, yes.
<npitre> dsaxena: hacking is not enough
<npitre> dsaxena: lot of hacking already happened and went by the wayside
<dsaxena> npitre, i'm hoping we can hash out some of the remaining discussions in Prague
<npitre> other than that, the single zImage work list remain substantial
* rnayak has quit (Quit: Leaving.)
<dsaxena> dmart, i want us to start thinking about how we test any code we write in the team
* rnayak (~a0131687@ has joined #linaro-kernel
<dsaxena> and also how we validate functionality of various devices on a board
<dmart> dsaxena: ideally, we'd want to share methodology and infrastructure with the validation guys
<dsaxena> dmart, yep
<mounir> dsaxena: a session on mapping KWG work to Linaro process 
<dmart> But if can flexibly point the system at arbitrary configs and branches (maybe with automatic attempts to merge/rebase) that could be pretty useful
<dsaxena> mounir, agree. I think a general session on the linaro process
<mounir> dsaxena, I have shared a google doc on that topic with you
<dsaxena> mounir, i saw that, will read
<dsaxena> dmart, the goal of the ci-loop is that any engineer can point it to a tree, specify a number of configs/boards, and specify build frequency
<dsaxena> automatic merge is something that gerrit handles
<dsaxena> but not in use by our kwg process
<dsaxena> jstultz_vm, any topic session suggestions? should we do one for each of the android upstream projects?
<dmart> We also need work to define test cases.  For example, the recent "audio doesn't work on vexpress" could have been detected by a simple check that the /dev/snd/* device nodes existed and were usable
<dmart> I think it would also be good to have a discussion on vexpress image deployment -- but that's more in the platform team area
<linusw_> dmart: isn't LTP the tool of the trade for such things? Then scripting that into say Hudson or whatever...
<jstultz_vm> dsaxena:  not sure if doing them separately is needed..
<jstultz_vm> dsaxena:  i suspect doing them together is reasonable.
<dsaxena> jstultz_vm, ok. 1 hour session or 2?
<dsaxena> dmart, i agree with your assessment. we need to figure out what are different types of tests that can be done to probe for devices and document those
<jstultz_vm> dsaxena:  hrmm.. probably 1 hour...  its just sort of me right now, so i'm not sure there's too much debate.
<dsaxena> jstultz_vm, :)
<mounir> dsaxena, something to consider, a session to go over all old technical requirement, take action on them, eith get rid of them or plan to complete in next quarter, or defer till later 
<dsaxena> dmart, want to ping the platform team and see if they want to schedule a session on vexpress deployment?
<jstultz_vm> dsaxena:  but if you think two would be better, i'm fine with that.. i just don't want to schedule something long and then spend 20 minutes on the overview and then have nothing else to cover..
<dmart> dsaxena: yes, I'll do that
<dsaxena> jstultz_vm, understood. let me think about it it a bit more
<dsaxena> mounir, should that be a general public session or should we cover that in a more private KWG meeting?
<dmart> linusw_, dsaxena: we should definitely run LTP (however, validation should definitely already be planning to provide that).  LTP is neither perfect nor adequate though -- we will almost certainly want to add some extra tests
<mounir> dsaxena, private KWG, then tell the TSC for agreement
<linusw_> dmart: so yeah, it needs per-board and per-SoC tests, and for ux500 we have such tests in place already
<linusw_> dsaxena, mounir: is any session covering a KWG "vision"
<dsaxena> linusw_, as in long-term deliverables?
<linusw_> dsaxena: yeah right now I have some vague idea that our vision is: get a single kernel, then get device tree, then boot a single distro with userspace on a set of boards
* rnayak has quit (Ping timeout: 248 seconds)
<dsaxena> linusw_, I think it would be good for us to talk about long-term roadmap
<dsaxena> linusw_, that's part of our vision. :)
<dsaxena> we also have a lot of storage work that svenkatr (and earlier Per and Tixy) is looking at
<linusw_> dsaxena: and say making UEFI and secure world play nice with the kernel could be another thing
<dsaxena> and we'll also be starting to look at UEFI, KVM, etc
<linusw_> dsaxena: just some stuff like that
<npitre> I expect that some ... developments from ARM Ltd would also affect our vision eventually
<linusw_> npitre: right, they didn't like that I disturbed their Global Platform people by suggesting the kernel use that API, haha :-)
<npitre> linusw_: I was more thinking in terms of available bits per general purpose registers
<svenkatr> dsaxena: If there are slots left, I can present an overview on block layer and the associated storage work items
<linusw_> npitre: aha down-to earth, I was up in the blue...
<dsaxena> svenkatr, ok, I'll create a BP for you to fill out
<dsaxena> svenkatr, we'll also have a session on EMMC 4.5
<dsaxena> i think all together we get around 20 session slots (I'll double check)
<dsaxena> anything beyond that we'll just have to discuss at the hacking sessions
<dsaxena> thomas-ab, nhe, robher are there any  DT specific sessions you want to see us run?
<npitre> I don't know if there would be any interest into debug tools
<dsaxena> i think we're beyond needing a session on overall DT planning, but it might be good to focus on 2-3 specific topics?
<npitre> especially the alternatives to DS5
<npitre> such as OpenOCD
<linusw_> npitre: I really like the debug tool called printascii() you taught me last week...
<dsaxena> linusw_, :)
<robher> I think DT clock support is the next major DT item
<thomas-ab> dsaxena: should there be a session for device tree bindings for clock and pin-control.
<npitre> linusw_: indeed, I'm heavily using it at this very moment ;-)
<linusw_> npitre: Vincent Guittot from PM has OpenOCD running on the ux500 board and can probably demo it to us
<robher> which of course is dependent on common struct clk
<dsaxena> npitre, does openocd need kernel changes?
<dsaxena> robher, thomas-ab ok, I'll setup 1 DT session where we can discuss those bindings
<dsaxena> rnayak (who just joined the team) will be looking into pinmux bindings
<dsaxena> robher, will you be @ connect or ELC-E?
<npitre> dsaxena: no, but it could be useful for kernel development
<robher> dsaxena: Connect yes,  ELC-E no
<npitre> dsaxena: but to be honest I don't crave for that myself so...
<dsaxena> npitre, i could see a session talking about in-kernel debug tools (KGDB, KDB, lttng, etc) being useful if there's a) enough interest and b) a likely chance that we'll work on those items in the next year
<robher> dsaxena: perhaps also a DT BoF to discuss any issues converting platforms
<dsaxena> I see (b) as not too likely with everything else on our plates
<dsaxena> robher, that can be one of the items in the DT discussion
<dsaxena> i'll fill in the initial outline for the session and robher, thomas-ab, and others can review
<npitre> dsaxena: I think (a) is also questionnable
<npitre> dsaxena: ... amongst kernel devs at least
<mounir> dsaxena, npitre, for KGDB, OpenOCD, lttmg we may want to include Uli and Michael from toolchain group
<dsaxena> npitre, yeah. I can see it being a topic of interest at ELC-E where there are more system level developers
<dsaxena> mounir, i'll ping them to see if there's any interest from their end
<dsaxena> so this week I'll create all the initial session BPs based on the topics here and in the email thread
<dsaxena> and send out emails to folks to help fill in the outlines of what we discuss
<dsaxena> please let me know ASAP if you are having issues with travel budget and visas
* manjugk (~manjugk@ has joined #linaro-kernel
<dsaxena> does anyone have any open issues outside of connect planning that need to be discussed?
<dsaxena> ok, thanks all for your time and for your input!
<robher> npitre: are you aware that rmk dropped your memory.h patch series in his latest for-next tree?
* linusw_ is off
<npitre> robher: he just never merged it into his for-next branch, as the rest of his devel-stable branch yet

WorkingGroups/KernelArchived/Meetings/2011-10-03 (last modified 2013-01-14 19:33:41)