[Ksummit-discuss] Draft Agenda for the Kernel Summit

[Ksummit-discuss] Draft Agenda for the Kernel Summit

[Theodore Ts'o]

The following is a draft agenda for the Kernel Summit.

Please note that three are still a number of TBD slots, and there will
also be another room available for unconference topics.  The timeslots
are still largely arbitrary and subject to change.

Please comment and propose any requests you might have for schedule
changes, things that you would like to talk about, etc.

Thanks!

						- Ted


Tuesday
========

 9:00 Keynotes
10:25 Coffee Break 
10:55 Pulling away from the tracing ABI quicksand (Mattieu Desnoyer, Steve Rostedt)
11:45 Printk redesign (Petr Mladek & Steve Rostedt)
12:25 Lunch
14:05 Media Summit issues to discuss (Mauro Carvalho)
14:55 TBD
15:35 Coffee Break 
16:05 Getting better/supplementary error info to userspace (David Howells)
16:55 TBD

Onsite Attendee reception 5:35pm

Wednesday
=========

 9:00 Keynotes
10:15 Conversation with Linus
10:35 Coffee break
11:05 Improve regression tracking (Thorsten Leemuis)
11:55 Kselftest use-cases (Shuah Khan)
12:35 lunch
14:15 Kernel Security (James Morris)
15:05 TBD
15:45 Coffee break
16:15 TBD
17:05 TAB Elections

All-Attendee reception 6pm


Tech topics that were discussed, but it's not clear whether we have
focus / someone to organize:

* Mobile phones
* Improving Kconfig
* Any of the more technical topics that were proposed for
     maintainer summit, or if people want to do some pre-discussion
     beforehand

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Konstantin Ryabitsev]

On Thu, Oct 12, 2017 at 08:15:34PM -0400, Theodore Ts'o wrote:
>The following is a draft agenda for the Kernel Summit.
>
>Please note that three are still a number of TBD slots, and there will
>also be another room available for unconference topics.  The timeslots
>are still largely arbitrary and subject to change.
>
>Please comment and propose any requests you might have for schedule
>changes, things that you would like to talk about, etc.

Ted:

If there is a 40-ish minute slot to talk about basic developer 
workstation security hygiene, I'm up for doing it. It would cover things 
like:

- PGP and ssh keys best practices
- Git and PGP signatures overview
- Safer browsing with firefox+firejail
- Security benefits of Wayland
- Q&A

Best,
-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation
Montréal, Québec

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[James Morris]

On Thu, 12 Oct 2017, Theodore Ts'o wrote:

> Wednesday
> =========
> 
>  9:00 Keynotes
> 10:15 Conversation with Linus
> 10:35 Coffee break
> 11:05 Improve regression tracking (Thorsten Leemuis)
> 11:55 Kselftest use-cases (Shuah Khan)
> 12:35 lunch
> 14:15 Kernel Security (James Morris)

Here's a preliminary agenda for the security session:

http://kernsec.org/wiki/index.php/Linux_Kernel_Summit_2017,_Security_Session

This agenda will likely evolve up until the day.


-- 
James Morris
<james.l.morris@oracle.com>

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Mauro Carvalho Chehab]

Hi Ted,

Em Thu, 12 Oct 2017 20:15:34 -0400
Theodore Ts'o <tytso@mit.edu> escreveu:

> The following is a draft agenda for the Kernel Summit.
> 
> Please note that three are still a number of TBD slots, and there will
> also be another room available for unconference topics.  The timeslots
> are still largely arbitrary and subject to change.
> 
> Please comment and propose any requests you might have for schedule
> changes, things that you would like to talk about, etc.
> 
> Thanks!
> 
> 						- Ted
> 
> 
> Tuesday
> ========
> 
>  9:00 Keynotes
> 10:25 Coffee Break 
> 10:55 Pulling away from the tracing ABI quicksand (Mattieu Desnoyer, Steve Rostedt)
> 11:45 Printk redesign (Petr Mladek & Steve Rostedt)
> 12:25 Lunch
> 14:05 Media Summit issues to discuss (Mauro Carvalho)

The idea here were to have the media summit discussions as part of the
KS. We'll end by doing it on Friday. So, we can remove it as a topic.

-

Yet, as we'll now have an open slot, and we ended by not adding
documentation to the Maintainers Summit, if this would be OK for
Jonathan, I propose to take this slot to do some technical discuss
about documentation.

From my side, there are two topics related to documentation that
that could fit at the technical non-maintainers part of KS:


1) Grouping drivers documentation files

While working on media and input doc file conversion to ReST, and while
looking to other similar driver-specific subsystems, I found a problem
about how we gather driver documentation.

On a typical driver subsystem, we have different sorts of documentation:

	- uAPI;
	- subsystem's core kAPI;
	- driver's implementation:
	- driver's user-centric stuff (like driver's specific modprobe
	  parameters and explanation about how hardware features will
	  be visible on userspace);

The model that it was used with DocBook were to place the uAPI docs under
the driver API book, and the rest on plain files.

I believe that the main reason for it was technical: with the old building 
system, we needed a XML file in order to handle kernel-doc markups.
However, using XML for every single doc file was not too practical.

Now that all doc files can include kernel-doc markups, IMHO we could do
a better job organizing them.

2) Documentation conversion to ReST

We finally got rid of the DocBook documents, with were all converted
to ReST. So, now documentation outside kernel-doc source file markups
are all in plain text, either using a ReST compatible format or
using some other random format[1].

[1] On a patch series I wrote to convert Documentation/*.txt files
    to a common style, I found several documents using some other
    Markup language (Markdown, Twiki, media wiki, ...). I also
    found several documents that seemed to be created by cloning
    a documentation style that were presenting on other .txt files
    (probably some de-facto Kernel's own documentation style).

From maintainer's PoV, in order to make the Kernel documentation
coherent, we need to stick with just one format and ensure that 
all new documents should follow it (that's basically why I proposed
it as a theme for the Maintainers summit), using some tool to check
if those files are following the documentation style - perhaps adding
some logic at checkpatch.pl to call Sphinx if a text file is inside a
patch - letting Sphinx do the file validation. In other words, I still
think we should discuss it at the Maintainer's summit.

Yet, from technical standpoint, it makes sense to discuss about how should
we organize the files at Documentation/ that aren't currently included
into any existing book.

My proposal is to cleanup all Documentation/*.txt files, discarding
the ones that are too outdated up to a point where it won't make sense to
keep. The remaining files would be moved into a sub-directory,
renamed to *.rst and added into an existing book (or a new one).

Cheers,
Mauro

Re: [Ksummit-discuss] Documentation session (was: Draft Agenda for the Kernel Summit)

[Jonathan Corbet]

On Thu, 19 Oct 2017 04:35:01 -0700
Mauro Carvalho Chehab <mchehab@infradead.org> wrote:

> Yet, as we'll now have an open slot, and we ended by not adding
> documentation to the Maintainers Summit, if this would be OK for
> Jonathan, I propose to take this slot to do some technical discuss
> about documentation.
> 
> From my side, there are two topics related to documentation that
> that could fit at the technical non-maintainers part of KS:

I'd thought about trying to propose a documentation-oriented session, but
I've just not had the time to really even think about it.

> 1) Grouping drivers documentation files
> 
> While working on media and input doc file conversion to ReST, and while
> looking to other similar driver-specific subsystems, I found a problem
> about how we gather driver documentation.
> 
> On a typical driver subsystem, we have different sorts of documentation:
> 
> 	- uAPI;
> 	- subsystem's core kAPI;
> 	- driver's implementation:
> 	- driver's user-centric stuff (like driver's specific modprobe
> 	  parameters and explanation about how hardware features will
> 	  be visible on userspace);
> 
> The model that it was used with DocBook were to place the uAPI docs under
> the driver API book, and the rest on plain files.

I think, honestly, that media is about the only subsystem that put
UAPI-related stuff in DocBook, just FWIW.  The bulk of the user-space API
has no in-kernel documentation at all, of course.

> I believe that the main reason for it was technical: with the old building 
> system, we needed a XML file in order to handle kernel-doc markups.
> However, using XML for every single doc file was not too practical.
> 
> Now that all doc files can include kernel-doc markups, IMHO we could do
> a better job organizing them.

Well, I have been trying to push that way.  One of my biggest points has
been trying to separate the documentation by audience; somebody looking for
UAPI info or module parameters probably doesn't care about the in-kernel
interfaces.  It's surprising how much resistance I got on that at times,
though.

Beyond that, I'd been trying to resist the temptation to design the
documentation layout too much.  Whatever we come up with seems likely to be
wrong and require some reshuffling anyway.  We've never tried to pull all
of the kernel docs together into a coherent whole before.

> 2) Documentation conversion to ReST
> 
> We finally got rid of the DocBook documents, with were all converted
> to ReST. So, now documentation outside kernel-doc source file markups
> are all in plain text, either using a ReST compatible format or
> using some other random format[1].
> 
> [1] On a patch series I wrote to convert Documentation/*.txt files
>     to a common style, I found several documents using some other
>     Markup language (Markdown, Twiki, media wiki, ...). I also
>     found several documents that seemed to be created by cloning
>     a documentation style that were presenting on other .txt files
>     (probably some de-facto Kernel's own documentation style).
> 
> From maintainer's PoV, in order to make the Kernel documentation
> coherent, we need to stick with just one format and ensure that 
> all new documents should follow it (that's basically why I proposed
> it as a theme for the Maintainers summit), using some tool to check
> if those files are following the documentation style - perhaps adding
> some logic at checkpatch.pl to call Sphinx if a text file is inside a
> patch - letting Sphinx do the file validation. In other words, I still
> think we should discuss it at the Maintainer's summit.

Pushing for RST-compatible formatting makes sense, and I tend to do that
when I see docs posted.  I'm not convinced that we want to apply a lot of
force to get there, though, for not-yet-converted docs.  The whole idea is
for RST to win over on its merits so we don't get too much pushback; for
the most part, I think that's working.

> Yet, from technical standpoint, it makes sense to discuss about how should
> we organize the files at Documentation/ that aren't currently included
> into any existing book.
> 
> My proposal is to cleanup all Documentation/*.txt files, discarding
> the ones that are too outdated up to a point where it won't make sense to
> keep. The remaining files would be moved into a sub-directory,
> renamed to *.rst and added into an existing book (or a new one).

Mauro, when I see you actually wanting to discard an obsolete document I'm
going to fall out of my chair in shock :)

I do very much want to see the remaining documentation brought under the
RST umbrella.  To a great extent, I think it's going to involve working
with the relevant subsystem maintainers, one by one, and doing the
conversion, kerneldoc comment fixups, etc. in a way that doesn't create too
much trouble for them.  Perhaps a session next week could be a good start
on that.

Thanks,

jon

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Theodore Ts'o]

On Fri, Oct 13, 2017 at 02:28:04PM -0400, Konstantin Ryabitsev wrote:
> Ted:
> 
> If there is a 40-ish minute slot to talk about basic developer workstation
> security hygiene, I'm up for doing it. It would cover things like:
> 
> - PGP and ssh keys best practices
> - Git and PGP signatures overview
> - Safer browsing with firefox+firejail
> - Security benefits of Wayland
> - Q&A

That sounds execellent, thanks!

							- Ted

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Theodore Ts'o]

On Thu, Oct 19, 2017 at 01:12:27PM -0700, Mauro Carvalho Chehab wrote:
> > 14:05 Media Summit issues to discuss (Mauro Carvalho)  
> 
> The idea here were to have the media summit discussions as part of the
> KS. We'll end by doing it on Friday. So, we can remove it as a topic.
> 
> Yet, as we'll now have an open slot, and we ended by not adding
> documentation to the Maintainers Summit, if this would be OK for
> Jonathan, I propose to take this slot to do some technical discuss
> about documentation.

OK, sounds good.

						- Ted

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Rafael J. Wysocki]

Hi Ted,

On Friday, October 13, 2017 2:15:34 AM CEST Theodore Ts'o wrote:
> The following is a draft agenda for the Kernel Summit.
> 
> Please note that three are still a number of TBD slots, and there will
> also be another room available for unconference topics.  The timeslots
> are still largely arbitrary and subject to change.
> 
> Please comment and propose any requests you might have for schedule
> changes, things that you would like to talk about, etc.

I haven't CCed you directly on my recent tech-topic message, so
let me repeat it below:

If this isn't too late, I'd like to put a PM topic on the agenda.

One problem basically is that runtime PM interacts with system-wide PM for
devices in ways that need to be taken care of.  The most common patterns are:

- What if a device is in runtime suspend before system suspend?  Can it
  remain suspended and under what conditions if so?

- Can devices be left in suspend when the system is resuming from
  system-wide suspend?

- Can driver runtime PM callbacks be used for system-wide PM too and to
  what extent?  If they can, how to make that happen?

We have tried to address these points in a couple of different ways so
far, but none of them is universal enough.  Moreover, one approach is
mostly for systems with PCI/ACPI and the other one is used on systems
without those and they both are not compatible.  That sort of didn't
matter until IP block sharing between vendors led to situations in
which one and the same driver is expected to work in both environments.

It would be good to have a common approach and IMO it should be based on
changing the PM core to help address the most common cases, so I posted
a set of patches to that end:

https://marc.info/?l=linux-kernel&m=150811822405206&w=2

and I'd like to have a discussion regarding that and it spans many
different subsystems potentially, so the KS seems to be the right venue
for that discussion to happen.

The second issue is that some bus types and quite a few drivers still use
legacy power management callbacks and I'd like to get rid of those at last,
first from the bus types and then from drivers too.  That's more of a
heads-up thing, but also possibly touches multiple places, so should be
suitable for a KS session as well.

At least Ulf is interested in this too, but it should be at least
tangentially interesting to other people at the KS too.

Thanks,
Rafael

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Theodore Ts'o]

On Thu, Oct 12, 2017 at 08:15:34PM -0400, Theodore Ts'o wrote:
> Wednesday
> =========
> 
> 11:05 Improve regression tracking (Thorsten Leemhuis)

I'm finalizing the schedule for the kernel summit, and I wanted to
check in with you about whether (a) you think this topic is still a
useful one for us to have, and (b) whether you will be available / the
best person to lead the topic.

Thanks!!

					- Ted

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Theodore Ts'o]

On Thu, Oct 12, 2017 at 08:15:34PM -0400, Theodore Ts'o wrote:
> 
> Wednesday
> =========
> 
> 11:55 Kselftest use-cases (Shuah Khan)

I'm finalizing the schedule for the kernel summit, and I wanted to
check in with you about whether (a) you think this topic is still a
useful one for us to have, and (b) whether you will be available / the
best person to lead the topic.

Thanks!!

						- Ted

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Thorsten Leemhuis]

Lo! On 20.10.2017 04:18, Theodore Ts'o wrote:
> On Thu, Oct 12, 2017 at 08:15:34PM -0400, Theodore Ts'o wrote:
>> Wednesday
>> =========
>> 11:05 Improve regression tracking (Thorsten Leemhuis)
> 
> I'm finalizing the schedule for the kernel summit, and I wanted to
> check in with you about whether (a) you think this topic is still a
> useful one for us to have,

IMHO it definitely is. The mailing list discussion when I proposed that
session here shows there were a lot of people interested in regression
tracking or bug reporting/qa in general. And it was something that was
discussed in the past years on the kerenl or maintainers summit all the
time afaics from lwn.net reporting; sometimes it special sessions,
sometimes it just came up somewhere.

And FWIW: I just plan to speak a few minutes about my work and then go
over to a more discussion style format to ask people how to improve
things. From there we can also drift to some of the other topics that
came up on this list when I proposed the sessions (I wanted to mentioned
those anyway as a sort of reminder).

> and (b) whether you will be available / the
> best person to lead the topic.

Well, I'm the new kid in town, so maybe I'm not. Rafael (CCed) is
interested in this topic as well and is more experienced in the format.
I had thought about asking him to join me on stage anway if he wants, as
I expected him to be around. But if you think he's better suited for
leading this session I can hand over to him. no worries.

Ciao, Thorsten

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Steven Rostedt]

On Thu, 12 Oct 2017 20:15:34 -0400
Theodore Ts'o <tytso@mit.edu> wrote:

> Tuesday
> ========

> 11:45 Printk redesign (Petr Mladek & Steve Rostedt)

Sergey needs to be part of this discussion too.

-- Steve

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Rafael J. Wysocki]

On Friday, October 20, 2017 5:32:53 AM CEST Thorsten Leemhuis wrote:
> Lo! On 20.10.2017 04:18, Theodore Ts'o wrote:
> > On Thu, Oct 12, 2017 at 08:15:34PM -0400, Theodore Ts'o wrote:
> >> Wednesday
> >> =========
> >> 11:05 Improve regression tracking (Thorsten Leemhuis)
> > 
> > I'm finalizing the schedule for the kernel summit, and I wanted to
> > check in with you about whether (a) you think this topic is still a
> > useful one for us to have,
> 
> IMHO it definitely is. The mailing list discussion when I proposed that
> session here shows there were a lot of people interested in regression
> tracking or bug reporting/qa in general. And it was something that was
> discussed in the past years on the kerenl or maintainers summit all the
> time afaics from lwn.net reporting; sometimes it special sessions,
> sometimes it just came up somewhere.
> 
> And FWIW: I just plan to speak a few minutes about my work and then go
> over to a more discussion style format to ask people how to improve
> things. From there we can also drift to some of the other topics that
> came up on this list when I proposed the sessions (I wanted to mentioned
> those anyway as a sort of reminder).
> 
> > and (b) whether you will be available / the
> > best person to lead the topic.
> 
> Well, I'm the new kid in town, so maybe I'm not. Rafael (CCed) is
> interested in this topic as well and is more experienced in the format.
> I had thought about asking him to join me on stage anway if he wants, as
> I expected him to be around. But if you think he's better suited for
> leading this session I can hand over to him. no worries.

I'll be around, but I think that this should be your session. :-)

I can help with the content etc anyway, though.

Thanks,
Rafael

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Shuah Khan]

On 10/19/2017 08:19 PM, Theodore Ts'o wrote:
> On Thu, Oct 12, 2017 at 08:15:34PM -0400, Theodore Ts'o wrote:
>>
>> Wednesday
>> =========
>>
>> 11:55 Kselftest use-cases (Shuah Khan)
> 
> I'm finalizing the schedule for the kernel summit, and I wanted to
> check in with you about whether (a) you think this topic is still a
> useful one for us to have, and (b) whether you will be available / the
> best person to lead the topic.
> 

Hi Ted,

Sorry - I have been traveling didn't get back to you earlier.
I haven't seen much response to my original posting, so I am
not very sure how useful people think this would be as a topic.

If you need to drop this in favor of another topic, it would be
fine.

thanks,
-- Shuah

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[James Bottomley]

On Fri, 2017-10-20 at 08:31 -0600, Shuah Khan wrote:
> On 10/19/2017 08:19 PM, Theodore Ts'o wrote:
> > 
> > On Thu, Oct 12, 2017 at 08:15:34PM -0400, Theodore Ts'o wrote:
> > > 
> > > 
> > > Wednesday
> > > =========
> > > 
> > > 11:55 Kselftest use-cases (Shuah Khan)
> > 
> > I'm finalizing the schedule for the kernel summit, and I wanted to
> > check in with you about whether (a) you think this topic is still a
> > useful one for us to have, and (b) whether you will be available /
> > the
> > best person to lead the topic.
> > 
> 
> Hi Ted,
> 
> Sorry - I have been traveling didn't get back to you earlier.
> I haven't seen much response to my original posting, so I am
> not very sure how useful people think this would be as a topic.
> 
> If you need to drop this in favor of another topic, it would be
> fine.

Actually, it would be really useful to do an overview for people who
run git trees of what resources are available to us for easy tree
testing.  Most people are aware of linux-next and 0day, but fewer
understand how to customise the tests of the latter and get email
failure reports on specific branches.  I suspect even fewer know how to
run their own CI based on something like kselftests or xfstests.

James

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Joe Perches]

On Fri, 2017-10-20 at 02:04 -0400, Steven Rostedt wrote:
> On Thu, 12 Oct 2017 20:15:34 -0400
> Theodore Ts'o <tytso@mit.edu> wrote:
> 
> > Tuesday
> > ========
> > 11:45 Printk redesign (Petr Mladek & Steve Rostedt)
> 
> Sergey needs to be part of this discussion too.

Is there going to be any streaming of these discussions?

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Shuah Khan]

On 10/20/2017 09:27 AM, James Bottomley wrote:
> On Fri, 2017-10-20 at 08:31 -0600, Shuah Khan wrote:
>> On 10/19/2017 08:19 PM, Theodore Ts'o wrote:
>>>
>>> On Thu, Oct 12, 2017 at 08:15:34PM -0400, Theodore Ts'o wrote:
>>>>
>>>>
>>>> Wednesday
>>>> =========
>>>>
>>>> 11:55 Kselftest use-cases (Shuah Khan)
>>>
>>> I'm finalizing the schedule for the kernel summit, and I wanted to
>>> check in with you about whether (a) you think this topic is still a
>>> useful one for us to have, and (b) whether you will be available /
>>> the
>>> best person to lead the topic.
>>>
>>
>> Hi Ted,
>>
>> Sorry - I have been traveling didn't get back to you earlier.
>> I haven't seen much response to my original posting, so I am
>> not very sure how useful people think this would be as a topic.
>>
>> If you need to drop this in favor of another topic, it would be
>> fine.
> 
> Actually, it would be really useful to do an overview for people who
> run git trees of what resources are available to us for easy tree
> testing.  Most people are aware of linux-next and 0day, but fewer
> understand how to customise the tests of the latter and get email
> failure reports on specific branches.  I suspect even fewer know how to
> run their own CI based on something like kselftests or xfstests.
> 

Awesome. I can go over how to and various use-cases and how I am using
kselftest for stable realease testing.

thanks,
-- Shuah

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Theodore Ts'o]

On Fri, Oct 20, 2017 at 02:53:05AM +0200, Rafael J. Wysocki wrote:
> 
> I haven't CCed you directly on my recent tech-topic message, so
> let me repeat it below:
> 
> If this isn't too late, I'd like to put a PM topic on the agenda.

Sorry, I thought I had acked you earlier.  Sure, no problem, I'll add
a power management topic onto the agenda.

					- Ted

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Theodore Ts'o]

On Fri, Oct 20, 2017 at 08:57:30AM -0700, Joe Perches wrote:
> On Fri, 2017-10-20 at 02:04 -0400, Steven Rostedt wrote:
> > On Thu, 12 Oct 2017 20:15:34 -0400
> > Theodore Ts'o <tytso@mit.edu> wrote:
> > 
> > > Tuesday
> > > ========
> > > 11:45 Printk redesign (Petr Mladek & Steve Rostedt)
> > 
> > Sergey needs to be part of this discussion too.
> 
> Is there going to be any streaming of these discussions?

Unfortunately, no, sorry.

For the technical topics, the primary issue is one of cost.

						- Ted

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Rafael J. Wysocki]

On Friday, October 20, 2017 9:46:16 PM CEST Theodore Ts'o wrote:
> On Fri, Oct 20, 2017 at 02:53:05AM +0200, Rafael J. Wysocki wrote:
> > 
> > I haven't CCed you directly on my recent tech-topic message, so
> > let me repeat it below:
> > 
> > If this isn't too late, I'd like to put a PM topic on the agenda.
> 
> Sorry, I thought I had acked you earlier.  Sure, no problem, I'll add
> a power management topic onto the agenda.
> 

Thank you!

[Ksummit-discuss] Documentation session (was: Draft Agenda for the Kernel Summit)

[Mauro Carvalho Chehab]

Em Thu, 19 Oct 2017 04:35:01 -0700
Mauro Carvalho Chehab <mchehab@infradead.org> escreveu:

> Hi Ted,
> 
> Em Thu, 12 Oct 2017 20:15:34 -0400
> Theodore Ts'o <tytso@mit.edu> escreveu:

Not sure what happened, but I didn't receive the answers from this
e-mail (and not even my original one), although I'm seeing them
at:
	https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2017-October/004876.html

So, I'm just copy-pasting Jon's answer and answering below and answering to
it. 

I'm also copying two other addresses, to be sure that I'll receive any
replies to it.

Ted,

I talked with Jon today, and he said that the time for this session is
not good for him, due to the Kernel panel at OSS.

On Oct 19 21:02:53 UTC 2017
Jonathan Corbet corbet at lwn.net wrote:

> On Thu, 19 Oct 2017 04:35:01 -0700
> Mauro Carvalho Chehab <mchehab at infradead.org> wrote:
> 
> > Yet, as we'll now have an open slot, and we ended by not adding
> > documentation to the Maintainers Summit, if this would be OK for
> > Jonathan, I propose to take this slot to do some technical discuss
> > about documentation.
> > 
> > From my side, there are two topics related to documentation that
> > that could fit at the technical non-maintainers part of KS:
> 
> I'd thought about trying to propose a documentation-oriented session, but
> I've just not had the time to really even think about it.

:-)

> 
> > 1) Grouping drivers documentation files
> > 
> > While working on media and input doc file conversion to ReST, and while
> > looking to other similar driver-specific subsystems, I found a problem
> > about how we gather driver documentation.
> > 
> > On a typical driver subsystem, we have different sorts of documentation:
> > 
> > 	- uAPI;
> > 	- subsystem's core kAPI;
> > 	- driver's implementation:
> > 	- driver's user-centric stuff (like driver's specific modprobe
> > 	  parameters and explanation about how hardware features will
> > 	  be visible on userspace);
> > 
> > The model that it was used with DocBook were to place the uAPI docs under
> > the driver API book, and the rest on plain files.
> 
> I think, honestly, that media is about the only subsystem that put
> UAPI-related stuff in DocBook, just FWIW.  The bulk of the user-space API
> has no in-kernel documentation at all, of course.

Yes, only media was having uAPI related documentation in DocBook. and most
has no in-kernel documentation :-)

There are some uAPI documentation at Documentation/ABI (that reminds the
patchset I wrote sometime ago to generate a book with those stuff).

But there are other subsystems have some uAPI documentation on text files.
I noticed that when I converted the input documentation :-)

There are other places with uAPI (and sysadmin) stuff on per-subsystem
documents, like, for example:

	Documentation/usb/usbmon.txt

> 
> > I believe that the main reason for it was technical: with the old building 
> > system, we needed a XML file in order to handle kernel-doc markups.
> > However, using XML for every single doc file was not too practical.
> > 
> > Now that all doc files can include kernel-doc markups, IMHO we could do
> > a better job organizing them.
> 
> Well, I have been trying to push that way.  One of my biggest points has
> been trying to separate the documentation by audience; somebody looking for
> UAPI info or module parameters probably doesn't care about the in-kernel
> interfaces.  It's surprising how much resistance I got on that at times,
> though.

Yeah, grouping documentation per audience is a good thing. However, 
identifying the audience may not be trivial.

To be clear about what I'm meaning here, my main concern is how to organize
driver documentation.

Right now, for most driver subsystem we're grouping documentation
altogether an a single driver's kAPI book.

Yet, the audience for a random driver subsystem (for instance input)
is likely different than the audience for another subsystem (like network).

In other words, for someone developing stuff for, let's say, the input
subsystem, it is a way more likely that it will likely 

Also, it is a way likely would be a way more likely that someone that reads a
Linux input uAPI to also read a Linux input kAPI than to read about the
network API.

So, grouping per-subsystem makes more sense, IMHO.

That's a side effect of grouping per-subsystem that sounds positive:
people may start from userspace at the initial chapters of the documentation,
and then goes deeper to "advanced" topics, e. g. kAPI. That way, we could
attract more Kernel developers long term.

> Beyond that, I'd been trying to resist the temptation to design the
> documentation layout too much.  Whatever we come up with seems likely to be
> wrong and require some reshuffling anyway.  We've never tried to pull all
> of the kernel docs together into a coherent whole before.

Yeah, I'm pretty sure it will take some time to organize. I won't doubt that
we may need to change things again on some future.

> 
> > 2) Documentation conversion to ReST
> > 
> > We finally got rid of the DocBook documents, with were all converted
> > to ReST. So, now documentation outside kernel-doc source file markups
> > are all in plain text, either using a ReST compatible format or
> > using some other random format[1].
> > 
> > [1] On a patch series I wrote to convert Documentation/*.txt files
> >     to a common style, I found several documents using some other
> >     Markup language (Markdown, Twiki, media wiki, ...). I also
> >     found several documents that seemed to be created by cloning
> >     a documentation style that were presenting on other .txt files
> >     (probably some de-facto Kernel's own documentation style).
> > 
> > From maintainer's PoV, in order to make the Kernel documentation
> > coherent, we need to stick with just one format and ensure that 
> > all new documents should follow it (that's basically why I proposed
> > it as a theme for the Maintainers summit), using some tool to check
> > if those files are following the documentation style - perhaps adding
> > some logic at checkpatch.pl to call Sphinx if a text file is inside a
> > patch - letting Sphinx do the file validation. In other words, I still
> > think we should discuss it at the Maintainer's summit.
> 
> Pushing for RST-compatible formatting makes sense, and I tend to do that
> when I see docs posted.  I'm not convinced that we want to apply a lot of
> force to get there, though, for not-yet-converted docs.  The whole idea is
> for RST to win over on its merits so we don't get too much pushback; for
> the most part, I think that's working.

Yeah, that's true. Yet, IMHO we should do some efforts for the stuff that
are used on other subsystems (like USB and core driver APIs).

If nobody steps up, I may likely do that for USB documents, if I lose
Internet connection and hardware access for some time (like while on some
conference or during Seasons).

> > Yet, from technical standpoint, it makes sense to discuss about how should
> > we organize the files at Documentation/ that aren't currently included
> > into any existing book.
> > 
> > My proposal is to cleanup all Documentation/*.txt files, discarding
> > the ones that are too outdated up to a point where it won't make sense to
> > keep. The remaining files would be moved into a sub-directory,
> > renamed to *.rst and added into an existing book (or a new one).
> 
> Mauro, when I see you actually wanting to discard an obsolete document I'm
> going to fall out of my chair in shock :)

Well, you complained to me a few times that I was converting obsolete
documents :-)

> I do very much want to see the remaining documentation brought under the
> RST umbrella.  To a great extent, I think it's going to involve working
> with the relevant subsystem maintainers, one by one, and doing the
> conversion, kerneldoc comment fixups, etc. in a way that doesn't create too
> much trouble for them.  Perhaps a session next week could be a good start
> on that.

Yeah, sure!

Cheers,
Mauro

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Joe Perches]

On Fri, 2017-10-20 at 15:50 -0400, Theodore Ts'o wrote:
> On Fri, Oct 20, 2017 at 08:57:30AM -0700, Joe Perches wrote:
> > On Fri, 2017-10-20 at 02:04 -0400, Steven Rostedt wrote:
> > > On Thu, 12 Oct 2017 20:15:34 -0400
> > > Theodore Ts'o <tytso@mit.edu> wrote:
> > > 
> > > > Tuesday
> > > > ========
> > > > 11:45 Printk redesign (Petr Mladek & Steve Rostedt)
> > > 
> > > Sergey needs to be part of this discussion too.
> > 
> > Is there going to be any streaming of these discussions?
> 
> Unfortunately, no, sorry.
> 
> For the technical topics, the primary issue is one of cost.

I would appreciate a recap of the printk discussions

Re: [Ksummit-discuss] Draft Agenda for the Kernel Summit

[Jonathan Corbet]

On Mon, 30 Oct 2017 22:10:25 -0700
Joe Perches <joe@perches.com> wrote:

> I would appreciate a recap of the printk discussions

I'll get there, hopefully soon.

jon

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Sakari Ailus]

Hi Mauro and Mark,

(Fixed Mark's e-mail.)

On Tue, Oct 20, 2015 at 01:34:43PM -0200, Mauro Carvalho Chehab wrote:
> Em Tue, 20 Oct 2015 14:22:09 +0100
> Mark Brown <broonie@kernel.org> escreveu:
> 
> > On Tue, Oct 20, 2015 at 12:55:37PM +0100, Liam Girdwood wrote:
> > > On Mon, 2015-10-19 at 14:46 -0600, Shuah Khan wrote:
> > 
> > > > You can find the media graph that includes ALSA Mixer Function and
> > > > Control Interface (Device: /dev/snd/controlC2), PCM Audio Capture
> > > > Function and PCM Audio Capture interface (Device: /dev/snd/pcmC2D0c)
> > > > at:
> > 
> > > > https://drive.google.com/open?id=0B0NIL0BQg-AlbjZkcElJb2RtVk0
> > 
> > > Looks nice. Fwiw, the graph will probably get a lot bigger when we show
> > > the audio DSP and codec paths (as DSPs and codecs have multiple muxes
> > > and mixers). It may be good to have a cmd line option to stop at certain
> > > nodes on the graph to avoid over populated/complex graphs ?
> > 
> > Having the ability to describe which physical device things are part of
> > would probably help a lot with the rendering here - I'm guessing that a
> > lot of filtering is likely to be things like collapsing down devices not
> > being looked at right now into a single block in the graph and it'd
> > probably help with user comprehesibilty provide a mapping back to things
> > they can see in the physical world.
> > 
> > This doesn't entirely correspond with struct device due to MFD and
> > multi-function USB stuff but it'd be a good start I expect.
> 
> Yeah, collapsing devices make sense.
> 
> Sakari is working on a properties API to be added to Media
> Controller entities/interfaces/links. Perhaps he could add this
> requirement to the API he's working with.

I think that's entirely possible. It's up to how we want to describe
devices. I wonder if we could e.g. add a sysfs path as a property there. The
user would then need to check which entities have equal sysfs paths.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Sakari Ailus]

Hi Mauro and Mark,

On Tue, Oct 20, 2015 at 01:34:43PM -0200, Mauro Carvalho Chehab wrote:
> Em Tue, 20 Oct 2015 14:22:09 +0100
> Mark Brown <broonie@kernel.org> escreveu:
> 
> > On Tue, Oct 20, 2015 at 12:55:37PM +0100, Liam Girdwood wrote:
> > > On Mon, 2015-10-19 at 14:46 -0600, Shuah Khan wrote:
> > 
> > > > You can find the media graph that includes ALSA Mixer Function and
> > > > Control Interface (Device: /dev/snd/controlC2), PCM Audio Capture
> > > > Function and PCM Audio Capture interface (Device: /dev/snd/pcmC2D0c)
> > > > at:
> > 
> > > > https://drive.google.com/open?id=0B0NIL0BQg-AlbjZkcElJb2RtVk0
> > 
> > > Looks nice. Fwiw, the graph will probably get a lot bigger when we show
> > > the audio DSP and codec paths (as DSPs and codecs have multiple muxes
> > > and mixers). It may be good to have a cmd line option to stop at certain
> > > nodes on the graph to avoid over populated/complex graphs ?
> > 
> > Having the ability to describe which physical device things are part of
> > would probably help a lot with the rendering here - I'm guessing that a
> > lot of filtering is likely to be things like collapsing down devices not
> > being looked at right now into a single block in the graph and it'd
> > probably help with user comprehesibilty provide a mapping back to things
> > they can see in the physical world.
> > 
> > This doesn't entirely correspond with struct device due to MFD and
> > multi-function USB stuff but it'd be a good start I expect.
> 
> Yeah, collapsing devices make sense.
> 
> Sakari is working on a properties API to be added to Media
> Controller entities/interfaces/links. Perhaps he could add this
> requirement to the API he's working with.

I think that's entirely possible. It's up to how we want to describe
devices. I wonder if we could e.g. add a sysfs path as a property there. The
user would then need to check which entities have equal sysfs paths.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

On Wed, Oct 21, 2015 at 03:04:49AM +0300, Laurent Pinchart wrote:

> not saying that such a feature should be a hard requirement for MC as I 
> haven't evaluated the complexity yet. Using the same format as the ALSA DSP 
> firmware topology binary would probably not be possible though, as I expect 
> that format to be quite ALSA-specific.

It'd definitely need extension but hopefully there's enough space in
there for doing that.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Liam Girdwood]

On Wed, 2015-10-21 at 03:04 +0300, Laurent Pinchart wrote:
> Hi Liam,
> 
> On Monday 19 October 2015 17:27:56 Liam Girdwood wrote:
> > On Mon, 2015-10-19 at 14:53 +0100, Mark Brown wrote:
> > > On Mon, Oct 19, 2015 at 10:33:04AM -0200, Mauro Carvalho Chehab wrote:
> > > > We did a Media Controller Summit in July. During the summit, it was
> > > > pointed that other subsystems like IIO (Linux Industrial I/O) have
> > > > similar needs and also need to track complex pipelines.
> > > > 
> > > > The goal of this tech topic is to present the MC next generation
> > > > concepts and how the patches to support MC was written, showing some
> > > > pipeline examples.
> > > > 
> > > > The next gen support patches were written in August, with some
> > > > additional patches written after that, and it has support for DVB
> > > > and for one ALSA driver (snd-usb-audio).
> > > > 
> > > > The patches are not merged yet at the media development tree and
> > > > at -next, as one of the core developers of the media controller
> > > > is missing time to review patches. So, while it was originally
> > > > targeted to be merged on Kernel 4.4, it is likely that this will be
> > > > merged only for Kernel 4.5, in order to give him more time to
> > > > review the patchset.
> > > 
> > > One fun thing on this that came up at the audio meeting we had in Dublin
> > > after ELC-E is that there is some desire to export the internal topology
> > > of audio devices to userspace using the same format that we're using to
> > > load topology information for DSP firmwares (see
> > > include/sound/soc-topoloy.h). If we go ahead with that it'd create an
> > > alternative topology ABI, it seems like we should at least consider if
> > > it's worth trying to share things here.
> > > 
> > > I've not had a chance to look at the new media controller work yet, I've
> > > CCed Lars and Liam who have more knowledge in this area.  Unfortunately
> > > I don't think any of the people working directly on this will be at KS
> > > this year.
> > 
> > Just to give a little more background (for any non audio folks), there
> > are many audio DSPs today that can load their topology and other
> > capabilities at runtime depending on the target device (phone, laptop,
> > PC, etc) and the audio use cases.
> > 
> > Our intention is to also have a single audio driver per DSP family (i.e.
> > single skylake audio DSP driver to cover all skylake based devices). The
> > DSP driver would load it's topology data alongside the DSP firmware so
> > that the driver topology (i.e. graph, controls, capabilities) would be
> > aligned with the DSP firmware topology.
> > 
> > The process for creating the topology data involves either compiling a
> > text topology file to the binary topology file (used by the kernel) or
> > using a new ALSA C API to generate the binary topology file (as part of
> > a firmware toolchain). The topology text compiler and C API are both
> > upstream.
> > 
> > We are currently implementing de-compiler support to the userspace
> > compiler in order to convert the binary topology files into text files
> > for debug and development purposes.
> > 
> > Ideally I'd like to be able to dump the topology data using the same
> > format that it used for topology loading. That way we could easily feed
> > them into the de-compiler for development/debug.
> > 
> > Having a simple mechanism for dumping topology data is important as we
> > will need to be able to easily dump this data on Android and Chrome
> > alongside regular Linux for development and debug purposes. i.e.
> > cat /sys/some/dump/file > audio_topology
> > 
> > I'm also supportive of having a higher level and more elegant topology
> > query interface for non kernel/firmware developers using media
> > controller.
> > 
> > What I'd like to propose is that we support both mechanisms for dumping
> > the audio topology data. :-
> > 
> > 1) Simple file dump using same format that topology is loaded. Used by
> > kernel/firmware developers only when media controller userspace not
> > available. Enabled by kernel Kconfig debug option.
> 
> I wouldn't be against an option to dump the topology of MC devices through a 
> file to capture the topology on a remote system that doesn't have the 
> necessary tools installed and analyze it on a development machine. I'm however 
> not saying that such a feature should be a hard requirement for MC as I 
> haven't evaluated the complexity yet. Using the same format as the ALSA DSP 
> firmware topology binary would probably not be possible though, as I expect 
> that format to be quite ALSA-specific.

Yeah, it is quite ALSA specific. It may just be best to just dump this
data format for driver/firmware developers only if it's going to be
difficult to align with MC. The internal ALSA code used to gather this
data will be mostly similar for this simple dump and MC though, so we
will still have a lot of codec reuse.

I think we may just have to support both formats, but stick a big fat
warning about the simple developer format is not for general use and
will change without warning etc. It's intended that the topology
compiler will be the only tool that will read this format (when it
de-compiles ALSA topology data).

Liam
> 
> > 2) Media controller API used by everyone else.
> 

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Geert Uytterhoeven]

On Mon, Oct 19, 2015 at 6:27 PM, Liam Girdwood
<liam.r.girdwood@linux.intel.com> wrote:
> We are currently implementing de-compiler support to the userspace
> compiler in order to convert the binary topology files into text files
> for debug and development purposes.

Just wondering: could this topology be represented/dumped as a DT?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Laurent Pinchart]

Hi Liam,

On Monday 19 October 2015 17:27:56 Liam Girdwood wrote:
> On Mon, 2015-10-19 at 14:53 +0100, Mark Brown wrote:
> > On Mon, Oct 19, 2015 at 10:33:04AM -0200, Mauro Carvalho Chehab wrote:
> > > We did a Media Controller Summit in July. During the summit, it was
> > > pointed that other subsystems like IIO (Linux Industrial I/O) have
> > > similar needs and also need to track complex pipelines.
> > > 
> > > The goal of this tech topic is to present the MC next generation
> > > concepts and how the patches to support MC was written, showing some
> > > pipeline examples.
> > > 
> > > The next gen support patches were written in August, with some
> > > additional patches written after that, and it has support for DVB
> > > and for one ALSA driver (snd-usb-audio).
> > > 
> > > The patches are not merged yet at the media development tree and
> > > at -next, as one of the core developers of the media controller
> > > is missing time to review patches. So, while it was originally
> > > targeted to be merged on Kernel 4.4, it is likely that this will be
> > > merged only for Kernel 4.5, in order to give him more time to
> > > review the patchset.
> > 
> > One fun thing on this that came up at the audio meeting we had in Dublin
> > after ELC-E is that there is some desire to export the internal topology
> > of audio devices to userspace using the same format that we're using to
> > load topology information for DSP firmwares (see
> > include/sound/soc-topoloy.h). If we go ahead with that it'd create an
> > alternative topology ABI, it seems like we should at least consider if
> > it's worth trying to share things here.
> > 
> > I've not had a chance to look at the new media controller work yet, I've
> > CCed Lars and Liam who have more knowledge in this area.  Unfortunately
> > I don't think any of the people working directly on this will be at KS
> > this year.
> 
> Just to give a little more background (for any non audio folks), there
> are many audio DSPs today that can load their topology and other
> capabilities at runtime depending on the target device (phone, laptop,
> PC, etc) and the audio use cases.
> 
> Our intention is to also have a single audio driver per DSP family (i.e.
> single skylake audio DSP driver to cover all skylake based devices). The
> DSP driver would load it's topology data alongside the DSP firmware so
> that the driver topology (i.e. graph, controls, capabilities) would be
> aligned with the DSP firmware topology.
> 
> The process for creating the topology data involves either compiling a
> text topology file to the binary topology file (used by the kernel) or
> using a new ALSA C API to generate the binary topology file (as part of
> a firmware toolchain). The topology text compiler and C API are both
> upstream.
> 
> We are currently implementing de-compiler support to the userspace
> compiler in order to convert the binary topology files into text files
> for debug and development purposes.
> 
> Ideally I'd like to be able to dump the topology data using the same
> format that it used for topology loading. That way we could easily feed
> them into the de-compiler for development/debug.
> 
> Having a simple mechanism for dumping topology data is important as we
> will need to be able to easily dump this data on Android and Chrome
> alongside regular Linux for development and debug purposes. i.e.
> cat /sys/some/dump/file > audio_topology
> 
> I'm also supportive of having a higher level and more elegant topology
> query interface for non kernel/firmware developers using media
> controller.
> 
> What I'd like to propose is that we support both mechanisms for dumping
> the audio topology data. :-
> 
> 1) Simple file dump using same format that topology is loaded. Used by
> kernel/firmware developers only when media controller userspace not
> available. Enabled by kernel Kconfig debug option.

I wouldn't be against an option to dump the topology of MC devices through a 
file to capture the topology on a remote system that doesn't have the 
necessary tools installed and analyze it on a development machine. I'm however 
not saying that such a feature should be a hard requirement for MC as I 
haven't evaluated the complexity yet. Using the same format as the ALSA DSP 
firmware topology binary would probably not be possible though, as I expect 
that format to be quite ALSA-specific.

> 2) Media controller API used by everyone else.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Shuah Khan]

On Tue, Oct 20, 2015 at 9:18 AM, Mauro Carvalho Chehab
<mchehab@osg.samsung.com> wrote:
> Em Tue, 20 Oct 2015 12:55:37 +0100

> Shuah,
>
> I guess the links for the ALSA part are not ok. On your graph, it is
> showing:
>
>         ATV decoder [PAD 3] --> Audio Mixer
>                             --> Audio Capture
>
> I suspect that the right graph would be, instead:
>
>         ATV decoder [PAD 3] --> Audio Mixer --> Audio Capture
>

Mauro,

Thanks for the find Fixed now in patch v2 series. Please find the media graphs
at

https://drive.google.com/open?id=0B0NIL0BQg-AlLWE3SzAxazBJWm8

thanks,
-- Shuah

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Mauro Carvalho Chehab]

Em Tue, 20 Oct 2015 17:47:24 +0200
Takashi Iwai <tiwai@suse.de> escreveu:

> On Tue, 20 Oct 2015 17:18:16 +0200,
> Mauro Carvalho Chehab wrote:
> > > Looks nice. Fwiw, the graph will probably get a lot bigger when we show
> > > the audio DSP and codec paths (as DSPs and codecs have multiple muxes
> > > and mixers).
> > 
> > Yeah, the graph is simplified, as for now we only needed to represent
> > the parts of the graph that are associated with the ALSA interfaces.
> 
> So this doesn't expose the graphs inside USB-audio chip but rather
> only the mixer elements parsed by ALSA driver, right?  That's what I
> understood from Shuah's patchset, so far.

Yes, Shuah's patch set is only exposing the minimal stuff that 
it is currently needed to identify if there are shared resources
with the DVB and V4L2/ALSA usage.

Adding support for the graphs inside the USB-audio chip is simple,
though. Basically, one call to create the entities and another
one to create the links between two entities.

> 
> > > It may be good to have a cmd line option to stop at certain
> > > nodes on the graph to avoid over populated/complex graphs ?
> > 
> > Yes, it makes sense to have some ways to simplify the graph plot.
> > Yet, I'm not sure yet what would be the best ways to simplify
> > the graph when plotted, as this is not a simple task.
> > 
> > For example, on the au0828/snd-usb-audio graph, the dvb-demux entity 
> > actually has a lot more than 5 source PADs. The demux basically gets
> > a MPEG-TS stream and splits audio, video and data channels on different
> > I/O outputs. Most drivers (including au0828) have 256 outputs.
> > Each node connected to two or more I/O entities. On an USB driver
> > like this one, those outputs are seen via two device nodes, but
> > TV sets and Set Top Boxes provide ways to wire the output of the
> > demux to the aSoC and to the DRM driver, in order to be able to
> > output sound and video directly. On some hardware, it is even possible
> > to reboot the CPU keeping those wires while the CPU reboots. So, the
> > user may not even notice if the CPU reboots due to some trouble.
> > 
> > So, we need all outputs of the demux to be controlled by the Media
> > Controller, for it to allow dynamically route audio and video to
> > the right entities at the ALSA and DRM parts of the graph.
> > 
> > The au0828 graphs that Shuah and I have were generated with a Kernel
> > hack patch that reduces the number of outputs to just 5, just to make
> > the graph visually readable. Of course, such patch should not be sent
> > upstream, and we need to find a solution on userspace to simplify
> > the graph on plots.
> > 
> > There are some ways that we could do that:
> > 
> > 1) we could group entities/interfaces per subsystem. So, if all the user
> > wants is to see ALSA-related nodes, it will filter out the other nodes
> > (eventually, keeping the nodes that are directly connected to ALSA
> > but belongs to the other subsystems);
> 
> This actually made me wonder how all things are managed.  Are all
> mapped into the same topology, or they are individual trees (e.g. per
> device object)?

It was mapped as one tree by device. That makes easier to handle
the links between two entities that may belong to different subsystems.

In other words, if you have two USB sticks, each one will have its
own media controller. All stuff inside each USB stick will belong to
the same graph.

Regards,
Mauro

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2383 bytes --]

On Tue, Oct 20, 2015 at 01:29:55PM -0200, Mauro Carvalho Chehab wrote:
> Mark Brown <broonie@kernel.org> escreveu:

> > It's still a program that has to be built for and installed on the
> > device under test which is the big bar for a lot of users (consider the
> > case where an audio expert is doing system tuning on a device using a
> > firmware image supplied from elsewhere, it may be difficult for them to
> > build new programs for the image or request that they be included in the
> > image).

> Well, with such assumption, even having a debug option would be
> a problem, as the firmware image may not be compiled with such option.

> I think that it is actually easier to cross-compile a program with all
> libraries required statically linked and then copy it to the target
> than convincing the firmware image manufacturer to send an image
> compiled with some additional options.

No, not normally - this is usually within OEMs and in places where this
is a problem you've typically got separate teams looking after userspace
and kernel delivery.  The kernel team is providing the drivers, the
userspace team isn't really involved and so it's more natural to work
with the kernel people.  It's kind of a specific need but it's
surprisingly common, and if it's just a debugfs thing there's a
reasonable chance someone wanted debugfs anyway.

> > My main concern here is ending up with two different machine parsable
> > formats for exporting the topology information to userspace - it's
> > potentially a bit confusing for people to know which one to pick and
> > might end up needing multiple tools and libraries to parse depending on
> > the situation.  It would be much nicer if we could get a consistent
> > format between the two.

> I'm open to suggestions. The advantage of the MC next gen API is that it
> is subsystem independent, and we're adding some ways for an already
> existing MC graph to be used by other subsystems. So, it can provide an
> end-to-end graph that represents how the stream is wired on the entire
> Kernel.

Yeah, I like the idea behind MC - I think what I'm suggesting is mainly
looking at the topology binary format that has been defined for the DSPs
and seeing if it can be reused in the MC ABI (or if there's some
blockers to reuse which might also impact the topology code in its
current use cases which would be just as valuable).


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Takashi Iwai]

On Tue, 20 Oct 2015 17:18:16 +0200,
Mauro Carvalho Chehab wrote:
> > Looks nice. Fwiw, the graph will probably get a lot bigger when we show
> > the audio DSP and codec paths (as DSPs and codecs have multiple muxes
> > and mixers).
> 
> Yeah, the graph is simplified, as for now we only needed to represent
> the parts of the graph that are associated with the ALSA interfaces.

So this doesn't expose the graphs inside USB-audio chip but rather
only the mixer elements parsed by ALSA driver, right?  That's what I
understood from Shuah's patchset, so far.

> > It may be good to have a cmd line option to stop at certain
> > nodes on the graph to avoid over populated/complex graphs ?
> 
> Yes, it makes sense to have some ways to simplify the graph plot.
> Yet, I'm not sure yet what would be the best ways to simplify
> the graph when plotted, as this is not a simple task.
> 
> For example, on the au0828/snd-usb-audio graph, the dvb-demux entity 
> actually has a lot more than 5 source PADs. The demux basically gets
> a MPEG-TS stream and splits audio, video and data channels on different
> I/O outputs. Most drivers (including au0828) have 256 outputs.
> Each node connected to two or more I/O entities. On an USB driver
> like this one, those outputs are seen via two device nodes, but
> TV sets and Set Top Boxes provide ways to wire the output of the
> demux to the aSoC and to the DRM driver, in order to be able to
> output sound and video directly. On some hardware, it is even possible
> to reboot the CPU keeping those wires while the CPU reboots. So, the
> user may not even notice if the CPU reboots due to some trouble.
> 
> So, we need all outputs of the demux to be controlled by the Media
> Controller, for it to allow dynamically route audio and video to
> the right entities at the ALSA and DRM parts of the graph.
> 
> The au0828 graphs that Shuah and I have were generated with a Kernel
> hack patch that reduces the number of outputs to just 5, just to make
> the graph visually readable. Of course, such patch should not be sent
> upstream, and we need to find a solution on userspace to simplify
> the graph on plots.
> 
> There are some ways that we could do that:
> 
> 1) we could group entities/interfaces per subsystem. So, if all the user
> wants is to see ALSA-related nodes, it will filter out the other nodes
> (eventually, keeping the nodes that are directly connected to ALSA
> but belongs to the other subsystems);

This actually made me wonder how all things are managed.  Are all
mapped into the same topology, or they are individual trees (e.g. per
device object)?


thanks,

Takashi

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Mauro Carvalho Chehab]

[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]

Em Tue, 20 Oct 2015 14:22:09 +0100
Mark Brown <broonie@kernel.org> escreveu:

> On Tue, Oct 20, 2015 at 12:55:37PM +0100, Liam Girdwood wrote:
> > On Mon, 2015-10-19 at 14:46 -0600, Shuah Khan wrote:
> 
> > > You can find the media graph that includes ALSA Mixer Function and
> > > Control Interface (Device: /dev/snd/controlC2), PCM Audio Capture
> > > Function and PCM Audio Capture interface (Device: /dev/snd/pcmC2D0c)
> > > at:
> 
> > > https://drive.google.com/open?id=0B0NIL0BQg-AlbjZkcElJb2RtVk0
> 
> > Looks nice. Fwiw, the graph will probably get a lot bigger when we show
> > the audio DSP and codec paths (as DSPs and codecs have multiple muxes
> > and mixers). It may be good to have a cmd line option to stop at certain
> > nodes on the graph to avoid over populated/complex graphs ?
> 
> Having the ability to describe which physical device things are part of
> would probably help a lot with the rendering here - I'm guessing that a
> lot of filtering is likely to be things like collapsing down devices not
> being looked at right now into a single block in the graph and it'd
> probably help with user comprehesibilty provide a mapping back to things
> they can see in the physical world.
> 
> This doesn't entirely correspond with struct device due to MFD and
> multi-function USB stuff but it'd be a good start I expect.

Yeah, collapsing devices make sense.

Sakari is working on a properties API to be added to Media
Controller entities/interfaces/links. Perhaps he could add this
requirement to the API he's working with.

Regards,
Mauro



[-- Attachment #2: Assinatura digital OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Mauro Carvalho Chehab]

[-- Attachment #1: Type: text/plain, Size: 3726 bytes --]

Em Tue, 20 Oct 2015 14:13:30 +0100
Mark Brown <broonie@kernel.org> escreveu:

> On Mon, Oct 19, 2015 at 05:34:19PM -0200, Mauro Carvalho Chehab wrote:
> > Liam Girdwood <liam.r.girdwood@linux.intel.com> escreveu:
> 
> > > Having a simple mechanism for dumping topology data is important as we
> > > will need to be able to easily dump this data on Android and Chrome
> > > alongside regular Linux for development and debug purposes. i.e.
> > > cat /sys/some/dump/file > audio_topology
> 
> > Well, it is not hard to get the topology using the media controller.
> > I wrote a testing program using it at:
> > 	http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-utils.git/tree/contrib/test/mc_nextgen_test.c
> 
> > The only library optional dependency is libudev, used to get the
> > device node names. The code falls back to use /sys/dev/char/ and
> > /dev to find the device names when compiled without libudev.
> 
> > So, it should be easy to provide a cat-like program that would be
> > dumping the audio topology on some file.
> 
> It's still a program that has to be built for and installed on the
> device under test which is the big bar for a lot of users (consider the
> case where an audio expert is doing system tuning on a device using a
> firmware image supplied from elsewhere, it may be difficult for them to
> build new programs for the image or request that they be included in the
> image).

Well, with such assumption, even having a debug option would be
a problem, as the firmware image may not be compiled with such option.

I think that it is actually easier to cross-compile a program with all
libraries required statically linked and then copy it to the target
than convincing the firmware image manufacturer to send an image
compiled with some additional options.

That's said, it shouldn't be hard to add some debugfs module that
would output the MC topology.

> > > What I'd like to propose is that we support both mechanisms for dumping
> > > the audio topology data. :-
> 
> > > 1) Simple file dump using same format that topology is loaded. Used by
> > > kernel/firmware developers only when media controller userspace not
> > > available. Enabled by kernel Kconfig debug option.
> 
> > Yeah, it sounds reasonable to have a mechanism like that just for
> > debug purposes.
> 
> > > 2) Media controller API used by everyone else.
> 
> > Makes sense to me.
> 
> My main concern here is ending up with two different machine parsable
> formats for exporting the topology information to userspace - it's
> potentially a bit confusing for people to know which one to pick and
> might end up needing multiple tools and libraries to parse depending on
> the situation.  It would be much nicer if we could get a consistent
> format between the two.

I'm open to suggestions. The advantage of the MC next gen API is that it
is subsystem independent, and we're adding some ways for an already
existing MC graph to be used by other subsystems. So, it can provide an
end-to-end graph that represents how the stream is wired on the entire
Kernel.

This is a requirement for some sorts of usages, where userspace may need
to change the stream path on more than one subsystem.

It also helps to lock resources that may be shared by more than one
subsystem. There are such cases between V4L2 and DVB subsystems, for
things like TV tuner. There are also such cases between V4L2 and DRM
subsystems, where the same video codec could be used by both
subsystems, but not at the same time.

So, I guess it is easier to extend the MC to fulfill the needs
for ALSA than doing the reverse or writing some other solution.

Regards,
Mauro

[-- Attachment #2: Assinatura digital OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Mauro Carvalho Chehab]

Em Tue, 20 Oct 2015 12:55:37 +0100
Liam Girdwood <liam.r.girdwood@linux.intel.com> escreveu:

> On Mon, 2015-10-19 at 14:46 -0600, Shuah Khan wrote:
> > On Mon, Oct 19, 2015 at 1:34 PM, Mauro Carvalho Chehab
> > <mchehab@osg.samsung.com> wrote:
> > > Hi Mark/Liam,
> > >
> > > Em Mon, 19 Oct 2015 17:27:56 +0100
> > > Liam Girdwood <liam.r.girdwood@linux.intel.com> escreveu:
> > >
> > >> On Mon, 2015-10-19 at 14:53 +0100, Mark Brown wrote:
> > >> > On Mon, Oct 19, 2015 at 10:33:04AM -0200, Mauro Carvalho Chehab wrote:
> > >> >
> > >> > > We did a Media Controller Summit in July. During the summit, it was
> > >> > > pointed that other subsystems like IIO (Linux Industrial I/O) have
> > >> > > similar needs and also need to track complex pipelines.
> > >> >
> > >> > > The goal of this tech topic is to present the MC next generation
> > >> > > concepts and how the patches to support MC was written, showing some
> > >> > > pipeline examples.
> > >> >
> > >> > > The next gen support patches were written in August, with some
> > >> > > additional patches written after that, and it has support for DVB
> > >> > > and for one ALSA driver (snd-usb-audio).
> > >> >
> > >> > > The patches are not merged yet at the media development tree and
> > >> > > at -next, as one of the core developers of the media controller
> > >> > > is missing time to review patches. So, while it was originally
> > >> > > targeted to be merged on Kernel 4.4, it is likely that this will be
> > >> > > merged only for Kernel 4.5, in order to give him more time to
> > >> > > review the patchset.
> > >> >
> > >> > One fun thing on this that came up at the audio meeting we had in Dublin
> > >> > after ELC-E is that there is some desire to export the internal topology
> > >> > of audio devices to userspace using the same format that we're using to
> > >> > load topology information for DSP firmwares (see include/sound/soc-topoloy.h).
> > >> > If we go ahead with that it'd create an alternative topology ABI, it
> > >> > seems like we should at least consider if it's worth trying to share
> > >> > things here.
> > >
> > > Thanks for the feedback. I was wanting to go to ELC-E this year due to
> > > ALSA summit, but, unfortunately, I had 3 other trips happening on a one
> > > month interval (two of them are 28+28 hours of trip). So, I had to give
> > > up going to ELC-E.
> > >
> > >> >
> > >> > I've not had a chance to look at the new media controller work yet, I've
> > >> > CCed Lars and Liam who have more knowledge in this area.  Unfortunately
> > >> > I don't think any of the people working directly on this will be at KS
> > >> > this year.
> > >>
> > >> Just to give a little more background (for any non audio folks), there
> > >> are many audio DSPs today that can load their topology and other
> > >> capabilities at runtime depending on the target device (phone, laptop,
> > >> PC, etc) and the audio use cases.
> > >>
> > >> Our intention is to also have a single audio driver per DSP family (i.e.
> > >> single skylake audio DSP driver to cover all skylake based devices). The
> > >> DSP driver would load it's topology data alongside the DSP firmware so
> > >> that the driver topology (i.e. graph, controls, capabilities) would be
> > >> aligned with the DSP firmware topology.
> > >>
> > >> The process for creating the topology data involves either compiling a
> > >> text topology file to the binary topology file (used by the kernel) or
> > >> using a new ALSA C API to generate the binary topology file (as part of
> > >> a firmware toolchain). The topology text compiler and C API are both
> > >> upstream.
> > >>
> > >> We are currently implementing de-compiler support to the userspace
> > >> compiler in order to convert the binary topology files into text files
> > >> for debug and development purposes.
> > >>
> > >> Ideally I'd like to be able to dump the topology data using the same
> > >> format that it used for topology loading. That way we could easily feed
> > >> them into the de-compiler for development/debug.
> > >>
> > >> Having a simple mechanism for dumping topology data is important as we
> > >> will need to be able to easily dump this data on Android and Chrome
> > >> alongside regular Linux for development and debug purposes. i.e.
> > >> cat /sys/some/dump/file > audio_topology
> > >
> > > Well, it is not hard to get the topology using the media controller.
> > > I wrote a testing program using it at:
> > >         http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-utils.git/tree/contrib/test/mc_nextgen_test.c
> > >
> > 
> > Adding to what Mauro said, I have a patch series out that updates
> > ASLA and AU0828 drivers (Hauppauge Win TV HVR 950Q Hybrid
> > USB TV Stick) to share tuner. I am speaking about this work at the
> > KLF on Oct 26th.
> > 
> > http://korealinuxforum2015.sched.org/event/f59175cc49f866dbc9bebc36f86fe663#.ViVWjGwVhBd
> > 
> > You can find the media graph that includes ALSA Mixer Function and
> > Control Interface (Device: /dev/snd/controlC2), PCM Audio Capture
> > Function and PCM Audio Capture interface (Device: /dev/snd/pcmC2D0c)
> > at:
> > 
> > https://drive.google.com/open?id=0B0NIL0BQg-AlbjZkcElJb2RtVk0

Shuah,

I guess the links for the ALSA part are not ok. On your graph, it is
showing:

	ATV decoder [PAD 3] --> Audio Mixer
			    --> Audio Capture

I suspect that the right graph would be, instead:

	ATV decoder [PAD 3] --> Audio Mixer --> Audio Capture

> 
> Looks nice. Fwiw, the graph will probably get a lot bigger when we show
> the audio DSP and codec paths (as DSPs and codecs have multiple muxes
> and mixers).

Yeah, the graph is simplified, as for now we only needed to represent
the parts of the graph that are associated with the ALSA interfaces.

> It may be good to have a cmd line option to stop at certain
> nodes on the graph to avoid over populated/complex graphs ?

Yes, it makes sense to have some ways to simplify the graph plot.
Yet, I'm not sure yet what would be the best ways to simplify
the graph when plotted, as this is not a simple task.

For example, on the au0828/snd-usb-audio graph, the dvb-demux entity 
actually has a lot more than 5 source PADs. The demux basically gets
a MPEG-TS stream and splits audio, video and data channels on different
I/O outputs. Most drivers (including au0828) have 256 outputs.
Each node connected to two or more I/O entities. On an USB driver
like this one, those outputs are seen via two device nodes, but
TV sets and Set Top Boxes provide ways to wire the output of the
demux to the aSoC and to the DRM driver, in order to be able to
output sound and video directly. On some hardware, it is even possible
to reboot the CPU keeping those wires while the CPU reboots. So, the
user may not even notice if the CPU reboots due to some trouble.

So, we need all outputs of the demux to be controlled by the Media
Controller, for it to allow dynamically route audio and video to
the right entities at the ALSA and DRM parts of the graph.

The au0828 graphs that Shuah and I have were generated with a Kernel
hack patch that reduces the number of outputs to just 5, just to make
the graph visually readable. Of course, such patch should not be sent
upstream, and we need to find a solution on userspace to simplify
the graph on plots.

There are some ways that we could do that:

1) we could group entities/interfaces per subsystem. So, if all the user
wants is to see ALSA-related nodes, it will filter out the other nodes
(eventually, keeping the nodes that are directly connected to ALSA
but belongs to the other subsystems);

2) Group the entities that have the same routes (like DVB demux
output PADs that are routed to the same userspace interfaces);

3) Hide unused entities;

4) Have a property describing the "level" of the entity. By default, 
the tool would only show entities that are above a certain level.

We could, of course, add knowledge at the userspace tool for it to
simplify some specific entity types, but I would prefer to keep the 
userspace tools more generic and add some properties for each
entity/interface that would allow the tool to automatically simplify
the graph based on the hints provided by the Kernel.

For now, we're more focused on adding the proper Kernel support for
MC, but I'm sure we'll need to work at an userspace library afterwards,
providing such capabilities.

Regards,
Mauro

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

On Tue, Oct 20, 2015 at 12:55:37PM +0100, Liam Girdwood wrote:
> On Mon, 2015-10-19 at 14:46 -0600, Shuah Khan wrote:

> > You can find the media graph that includes ALSA Mixer Function and
> > Control Interface (Device: /dev/snd/controlC2), PCM Audio Capture
> > Function and PCM Audio Capture interface (Device: /dev/snd/pcmC2D0c)
> > at:

> > https://drive.google.com/open?id=0B0NIL0BQg-AlbjZkcElJb2RtVk0

> Looks nice. Fwiw, the graph will probably get a lot bigger when we show
> the audio DSP and codec paths (as DSPs and codecs have multiple muxes
> and mixers). It may be good to have a cmd line option to stop at certain
> nodes on the graph to avoid over populated/complex graphs ?

Having the ability to describe which physical device things are part of
would probably help a lot with the rendering here - I'm guessing that a
lot of filtering is likely to be things like collapsing down devices not
being looked at right now into a single block in the graph and it'd
probably help with user comprehesibilty provide a mapping back to things
they can see in the physical world.

This doesn't entirely correspond with struct device due to MFD and
multi-function USB stuff but it'd be a good start I expect.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]

On Mon, Oct 19, 2015 at 05:34:19PM -0200, Mauro Carvalho Chehab wrote:
> Liam Girdwood <liam.r.girdwood@linux.intel.com> escreveu:

> > Having a simple mechanism for dumping topology data is important as we
> > will need to be able to easily dump this data on Android and Chrome
> > alongside regular Linux for development and debug purposes. i.e.
> > cat /sys/some/dump/file > audio_topology

> Well, it is not hard to get the topology using the media controller.
> I wrote a testing program using it at:
> 	http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-utils.git/tree/contrib/test/mc_nextgen_test.c

> The only library optional dependency is libudev, used to get the
> device node names. The code falls back to use /sys/dev/char/ and
> /dev to find the device names when compiled without libudev.

> So, it should be easy to provide a cat-like program that would be
> dumping the audio topology on some file.

It's still a program that has to be built for and installed on the
device under test which is the big bar for a lot of users (consider the
case where an audio expert is doing system tuning on a device using a
firmware image supplied from elsewhere, it may be difficult for them to
build new programs for the image or request that they be included in the
image).

> > What I'd like to propose is that we support both mechanisms for dumping
> > the audio topology data. :-

> > 1) Simple file dump using same format that topology is loaded. Used by
> > kernel/firmware developers only when media controller userspace not
> > available. Enabled by kernel Kconfig debug option.

> Yeah, it sounds reasonable to have a mechanism like that just for
> debug purposes.

> > 2) Media controller API used by everyone else.

> Makes sense to me.

My main concern here is ending up with two different machine parsable
formats for exporting the topology information to userspace - it's
potentially a bit confusing for people to know which one to pick and
might end up needing multiple tools and libraries to parse depending on
the situation.  It would be much nicer if we could get a consistent
format between the two.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Liam Girdwood]

On Mon, 2015-10-19 at 14:46 -0600, Shuah Khan wrote:
> On Mon, Oct 19, 2015 at 1:34 PM, Mauro Carvalho Chehab
> <mchehab@osg.samsung.com> wrote:
> > Hi Mark/Liam,
> >
> > Em Mon, 19 Oct 2015 17:27:56 +0100
> > Liam Girdwood <liam.r.girdwood@linux.intel.com> escreveu:
> >
> >> On Mon, 2015-10-19 at 14:53 +0100, Mark Brown wrote:
> >> > On Mon, Oct 19, 2015 at 10:33:04AM -0200, Mauro Carvalho Chehab wrote:
> >> >
> >> > > We did a Media Controller Summit in July. During the summit, it was
> >> > > pointed that other subsystems like IIO (Linux Industrial I/O) have
> >> > > similar needs and also need to track complex pipelines.
> >> >
> >> > > The goal of this tech topic is to present the MC next generation
> >> > > concepts and how the patches to support MC was written, showing some
> >> > > pipeline examples.
> >> >
> >> > > The next gen support patches were written in August, with some
> >> > > additional patches written after that, and it has support for DVB
> >> > > and for one ALSA driver (snd-usb-audio).
> >> >
> >> > > The patches are not merged yet at the media development tree and
> >> > > at -next, as one of the core developers of the media controller
> >> > > is missing time to review patches. So, while it was originally
> >> > > targeted to be merged on Kernel 4.4, it is likely that this will be
> >> > > merged only for Kernel 4.5, in order to give him more time to
> >> > > review the patchset.
> >> >
> >> > One fun thing on this that came up at the audio meeting we had in Dublin
> >> > after ELC-E is that there is some desire to export the internal topology
> >> > of audio devices to userspace using the same format that we're using to
> >> > load topology information for DSP firmwares (see include/sound/soc-topoloy.h).
> >> > If we go ahead with that it'd create an alternative topology ABI, it
> >> > seems like we should at least consider if it's worth trying to share
> >> > things here.
> >
> > Thanks for the feedback. I was wanting to go to ELC-E this year due to
> > ALSA summit, but, unfortunately, I had 3 other trips happening on a one
> > month interval (two of them are 28+28 hours of trip). So, I had to give
> > up going to ELC-E.
> >
> >> >
> >> > I've not had a chance to look at the new media controller work yet, I've
> >> > CCed Lars and Liam who have more knowledge in this area.  Unfortunately
> >> > I don't think any of the people working directly on this will be at KS
> >> > this year.
> >>
> >> Just to give a little more background (for any non audio folks), there
> >> are many audio DSPs today that can load their topology and other
> >> capabilities at runtime depending on the target device (phone, laptop,
> >> PC, etc) and the audio use cases.
> >>
> >> Our intention is to also have a single audio driver per DSP family (i.e.
> >> single skylake audio DSP driver to cover all skylake based devices). The
> >> DSP driver would load it's topology data alongside the DSP firmware so
> >> that the driver topology (i.e. graph, controls, capabilities) would be
> >> aligned with the DSP firmware topology.
> >>
> >> The process for creating the topology data involves either compiling a
> >> text topology file to the binary topology file (used by the kernel) or
> >> using a new ALSA C API to generate the binary topology file (as part of
> >> a firmware toolchain). The topology text compiler and C API are both
> >> upstream.
> >>
> >> We are currently implementing de-compiler support to the userspace
> >> compiler in order to convert the binary topology files into text files
> >> for debug and development purposes.
> >>
> >> Ideally I'd like to be able to dump the topology data using the same
> >> format that it used for topology loading. That way we could easily feed
> >> them into the de-compiler for development/debug.
> >>
> >> Having a simple mechanism for dumping topology data is important as we
> >> will need to be able to easily dump this data on Android and Chrome
> >> alongside regular Linux for development and debug purposes. i.e.
> >> cat /sys/some/dump/file > audio_topology
> >
> > Well, it is not hard to get the topology using the media controller.
> > I wrote a testing program using it at:
> >         http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-utils.git/tree/contrib/test/mc_nextgen_test.c
> >
> 
> Adding to what Mauro said, I have a patch series out that updates
> ASLA and AU0828 drivers (Hauppauge Win TV HVR 950Q Hybrid
> USB TV Stick) to share tuner. I am speaking about this work at the
> KLF on Oct 26th.
> 
> http://korealinuxforum2015.sched.org/event/f59175cc49f866dbc9bebc36f86fe663#.ViVWjGwVhBd
> 
> You can find the media graph that includes ALSA Mixer Function and
> Control Interface (Device: /dev/snd/controlC2), PCM Audio Capture
> Function and PCM Audio Capture interface (Device: /dev/snd/pcmC2D0c)
> at:
> 
> https://drive.google.com/open?id=0B0NIL0BQg-AlbjZkcElJb2RtVk0

Looks nice. Fwiw, the graph will probably get a lot bigger when we show
the audio DSP and codec paths (as DSPs and codecs have multiple muxes
and mixers). It may be good to have a cmd line option to stop at certain
nodes on the graph to avoid over populated/complex graphs ?

Liam

> 
> thanks,
> -- Shuah

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Shuah Khan]

On Mon, Oct 19, 2015 at 1:34 PM, Mauro Carvalho Chehab
<mchehab@osg.samsung.com> wrote:
> Hi Mark/Liam,
>
> Em Mon, 19 Oct 2015 17:27:56 +0100
> Liam Girdwood <liam.r.girdwood@linux.intel.com> escreveu:
>
>> On Mon, 2015-10-19 at 14:53 +0100, Mark Brown wrote:
>> > On Mon, Oct 19, 2015 at 10:33:04AM -0200, Mauro Carvalho Chehab wrote:
>> >
>> > > We did a Media Controller Summit in July. During the summit, it was
>> > > pointed that other subsystems like IIO (Linux Industrial I/O) have
>> > > similar needs and also need to track complex pipelines.
>> >
>> > > The goal of this tech topic is to present the MC next generation
>> > > concepts and how the patches to support MC was written, showing some
>> > > pipeline examples.
>> >
>> > > The next gen support patches were written in August, with some
>> > > additional patches written after that, and it has support for DVB
>> > > and for one ALSA driver (snd-usb-audio).
>> >
>> > > The patches are not merged yet at the media development tree and
>> > > at -next, as one of the core developers of the media controller
>> > > is missing time to review patches. So, while it was originally
>> > > targeted to be merged on Kernel 4.4, it is likely that this will be
>> > > merged only for Kernel 4.5, in order to give him more time to
>> > > review the patchset.
>> >
>> > One fun thing on this that came up at the audio meeting we had in Dublin
>> > after ELC-E is that there is some desire to export the internal topology
>> > of audio devices to userspace using the same format that we're using to
>> > load topology information for DSP firmwares (see include/sound/soc-topoloy.h).
>> > If we go ahead with that it'd create an alternative topology ABI, it
>> > seems like we should at least consider if it's worth trying to share
>> > things here.
>
> Thanks for the feedback. I was wanting to go to ELC-E this year due to
> ALSA summit, but, unfortunately, I had 3 other trips happening on a one
> month interval (two of them are 28+28 hours of trip). So, I had to give
> up going to ELC-E.
>
>> >
>> > I've not had a chance to look at the new media controller work yet, I've
>> > CCed Lars and Liam who have more knowledge in this area.  Unfortunately
>> > I don't think any of the people working directly on this will be at KS
>> > this year.
>>
>> Just to give a little more background (for any non audio folks), there
>> are many audio DSPs today that can load their topology and other
>> capabilities at runtime depending on the target device (phone, laptop,
>> PC, etc) and the audio use cases.
>>
>> Our intention is to also have a single audio driver per DSP family (i.e.
>> single skylake audio DSP driver to cover all skylake based devices). The
>> DSP driver would load it's topology data alongside the DSP firmware so
>> that the driver topology (i.e. graph, controls, capabilities) would be
>> aligned with the DSP firmware topology.
>>
>> The process for creating the topology data involves either compiling a
>> text topology file to the binary topology file (used by the kernel) or
>> using a new ALSA C API to generate the binary topology file (as part of
>> a firmware toolchain). The topology text compiler and C API are both
>> upstream.
>>
>> We are currently implementing de-compiler support to the userspace
>> compiler in order to convert the binary topology files into text files
>> for debug and development purposes.
>>
>> Ideally I'd like to be able to dump the topology data using the same
>> format that it used for topology loading. That way we could easily feed
>> them into the de-compiler for development/debug.
>>
>> Having a simple mechanism for dumping topology data is important as we
>> will need to be able to easily dump this data on Android and Chrome
>> alongside regular Linux for development and debug purposes. i.e.
>> cat /sys/some/dump/file > audio_topology
>
> Well, it is not hard to get the topology using the media controller.
> I wrote a testing program using it at:
>         http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-utils.git/tree/contrib/test/mc_nextgen_test.c
>

Adding to what Mauro said, I have a patch series out that updates
ASLA and AU0828 drivers (Hauppauge Win TV HVR 950Q Hybrid
USB TV Stick) to share tuner. I am speaking about this work at the
KLF on Oct 26th.

http://korealinuxforum2015.sched.org/event/f59175cc49f866dbc9bebc36f86fe663#.ViVWjGwVhBd

You can find the media graph that includes ALSA Mixer Function and
Control Interface (Device: /dev/snd/controlC2), PCM Audio Capture
Function and PCM Audio Capture interface (Device: /dev/snd/pcmC2D0c)
at:

https://drive.google.com/open?id=0B0NIL0BQg-AlbjZkcElJb2RtVk0

thanks,
-- Shuah

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Mauro Carvalho Chehab]

Hi Mark/Liam,

Em Mon, 19 Oct 2015 17:27:56 +0100
Liam Girdwood <liam.r.girdwood@linux.intel.com> escreveu:

> On Mon, 2015-10-19 at 14:53 +0100, Mark Brown wrote:
> > On Mon, Oct 19, 2015 at 10:33:04AM -0200, Mauro Carvalho Chehab wrote:
> > 
> > > We did a Media Controller Summit in July. During the summit, it was
> > > pointed that other subsystems like IIO (Linux Industrial I/O) have
> > > similar needs and also need to track complex pipelines. 
> > 
> > > The goal of this tech topic is to present the MC next generation
> > > concepts and how the patches to support MC was written, showing some
> > > pipeline examples. 
> > 
> > > The next gen support patches were written in August, with some 
> > > additional patches written after that, and it has support for DVB
> > > and for one ALSA driver (snd-usb-audio).
> > 
> > > The patches are not merged yet at the media development tree and
> > > at -next, as one of the core developers of the media controller
> > > is missing time to review patches. So, while it was originally
> > > targeted to be merged on Kernel 4.4, it is likely that this will be 
> > > merged only for Kernel 4.5, in order to give him more time to
> > > review the patchset.
> > 
> > One fun thing on this that came up at the audio meeting we had in Dublin
> > after ELC-E is that there is some desire to export the internal topology
> > of audio devices to userspace using the same format that we're using to 
> > load topology information for DSP firmwares (see include/sound/soc-topoloy.h).
> > If we go ahead with that it'd create an alternative topology ABI, it
> > seems like we should at least consider if it's worth trying to share
> > things here.

Thanks for the feedback. I was wanting to go to ELC-E this year due to
ALSA summit, but, unfortunately, I had 3 other trips happening on a one
month interval (two of them are 28+28 hours of trip). So, I had to give
up going to ELC-E.

> > 
> > I've not had a chance to look at the new media controller work yet, I've
> > CCed Lars and Liam who have more knowledge in this area.  Unfortunately
> > I don't think any of the people working directly on this will be at KS
> > this year.
> 
> Just to give a little more background (for any non audio folks), there
> are many audio DSPs today that can load their topology and other
> capabilities at runtime depending on the target device (phone, laptop,
> PC, etc) and the audio use cases.
> 
> Our intention is to also have a single audio driver per DSP family (i.e.
> single skylake audio DSP driver to cover all skylake based devices). The
> DSP driver would load it's topology data alongside the DSP firmware so
> that the driver topology (i.e. graph, controls, capabilities) would be
> aligned with the DSP firmware topology.
> 
> The process for creating the topology data involves either compiling a
> text topology file to the binary topology file (used by the kernel) or
> using a new ALSA C API to generate the binary topology file (as part of
> a firmware toolchain). The topology text compiler and C API are both
> upstream.
> 
> We are currently implementing de-compiler support to the userspace
> compiler in order to convert the binary topology files into text files
> for debug and development purposes.
> 
> Ideally I'd like to be able to dump the topology data using the same
> format that it used for topology loading. That way we could easily feed
> them into the de-compiler for development/debug.
> 
> Having a simple mechanism for dumping topology data is important as we
> will need to be able to easily dump this data on Android and Chrome
> alongside regular Linux for development and debug purposes. i.e.
> cat /sys/some/dump/file > audio_topology

Well, it is not hard to get the topology using the media controller.
I wrote a testing program using it at:
	http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-utils.git/tree/contrib/test/mc_nextgen_test.c

The only library optional dependency is libudev, used to get the
device node names. The code falls back to use /sys/dev/char/ and
/dev to find the device names when compiled without libudev.

So, it should be easy to provide a cat-like program that would be
dumping the audio topology on some file.

> I'm also supportive of having a higher level and more elegant topology
> query interface for non kernel/firmware developers using media
> controller.

The media controller also allows runtime topology changes. This is
important specially on SoC devices that allow runtime changes.

One of the advanced use cases of the media controller API is on SoC
that have dynamic pipelines on more than one subsystem that could be
wired on a single circuit.

One such example would be to setup a TV decoding pipeline
that starts on a TV tuner, goes though DVB, V4L, DRM and ALSA
subsystems and the sink nodes would be the audio speaker and the
TV display.

As the TV channel is changed, different codecs may be needed for
video and/or audio. Also, as the program may be encrypted (or not),
it may be needed to add Conditional Access Modules at the pipelines
and/or other hardware IP blocks in order to decrypt the contents.

> 
> What I'd like to propose is that we support both mechanisms for dumping
> the audio topology data. :-
> 
> 1) Simple file dump using same format that topology is loaded. Used by
> kernel/firmware developers only when media controller userspace not
> available. Enabled by kernel Kconfig debug option.

Yeah, it sounds reasonable to have a mechanism like that just for
debug purposes.

> 2) Media controller API used by everyone else.

Makes sense to me.

Regards,
Mauro

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 530 bytes --]

> We are currently implementing de-compiler support to the userspace
> compiler in order to convert the binary topology files into text files
> for debug and development purposes.

> Ideally I'd like to be able to dump the topology data using the same
> format that it used for topology loading. That way we could easily feed
> them into the de-compiler for development/debug.

...this being the topology information for the entire card rather than
just that for the DSP.

[BTW, note that I typoed my address in my earlier reply]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Jonathan Cameron]

On 19 October 2015 13:33:04 BST, Mauro Carvalho Chehab <mchehab@osg.samsung.com> wrote:
>Em Mon, 12 Oct 2015 15:01:37 -0400
>Theodore Ts'o <tytso@mit.edu> escreveu:
>
>> This is an initial draft for the upcoming kernel summit.
>> 
>> It is still very drafty; in particular, just because a topic has been
>> listed, it may turn out that the topic has been resolved off-line, or
>> otherwise overtaken by events, in which case we will drop it.  In
>> addition, we're also in the process of sending queries to the
>proposed
>> topic leaders to see if they are willing to kick off the discussion,
>> and so that is subject to change as well.
>> 
>> I'd appreciate comments about any topics that you think might be
>> missing and that would be worth our discussing.  In addition, if you
>> have strong opinions moving a topic from the technical session day to
>> the core day or vice versa, please make the case for the change.
>> 
>> There will be some TBD slots which can be scheduled at the last
>> minute, but I'd like to get at least one full track of the technical
>> sessions and most of the core sessions scheduled.
>> 
>> Many thanks,
>> 
>> 					- Ted
>> 
>> 
>> 			  Kernel Summit Agenda
>> 			   October 26-28, 2015
>> 				 DRAFT
>> 
>> Web Version Agenda:		
>> 
>> * Monday: Workshops and break out sessions (overlap with Korea Linux
>Forum)
>> * Tuesday: Dual-track technical sessions
>> * Wednesday: Invite-only core attendees' plenary sessions
>> 
>> Dual-Track Technical sessions (Oct. 27th)
>> =========================================
>> 
>> 9:00    - Welcome and agenda bashing
>> 9:30	- Topic A1                   | Topic B1
>> 10:00   - Topic A2                   | Topic B2
>> 10:30   - Break
>> 11:00	- Topic A3                   | Topic B3
>> 11:30   - Topic A4                   | Topic B4
>> 12:00   - Topic A5                   | Topic B5
>> 12:30   - Lunch
>> 1:30    - Topic A6                   | Topic B6
>> 2:00    - Topic A7                   | Topic B7
>> 2:30    - Break
>> 3:00    - Topic A8                   | Topic B8
>> 3:30    - Topic A9                   | Topic B9
>> 4:00    - Topic A10                  | Topic B10
>> 4:30    - Break
>> 5:00    - Kernel Summit Tech Day -- What went well, what can we do
>better? 
>> 5:30    - Group Photograph (for core day attendees)
>> 6:30    - Dinner
>> 
>> Potential Tech topics
>> =====================
>> 
>> 1. Mainline kernel on a cellphone (need someone to lead?)
>> 2. Semantics of MMIO mapping attributes across archs (Benjamin
>Herrenschmidt)
>> 3. GPIO API/ABI discussion (need someone to lead?)
>> 4. System-wide interface to specify the level of PM tuning (Rafael J.
>Wysocki)
>> 5. Giving freezer well-defined semantics (Jiri Kosina)
>> 6. IRQ affinity (Christoph Hellwig)
>> 7. benchmarking and performance trends (Chris Mason)
>> 8. FPGAs and how to program them from kernel (need somone to lead?
>> 9. Overlays and file(system) unioning issues (David Howells)
>> 10. Firmware signing (David Howells)
>> 11. Context tracking / nohz / RCU state (Andy Lutomirski)
>> 12. userspace infrastructure services (Stephen Hemminger)
>> 13. Kernel support for compute-offload devices (Joerg Roedel)
>> 14. Improving Kernel Security 
>> 15. Developer Workflow Security (Panel)
>
>Could you please add a new topic:
>
>16. The Next Generation of the Media Controller (Mauro Carvalho Chehab)
>
>Along the years, we've been developing a mechanism at the Kernel to
>store
>and present graphs to userspace, called Media Controller. The original
>scope of the Media Controller were to store and represent pipeline
>connections between hardware components on complex streaming devices,
>like the ones that are used for webcams on cell phones, where there are
>typically two camera sensors, and lots of processing units to enhance
>the image and to convert it into different formats.
>
>Since the beginning, we found that it would be useful to use it some
>day
>on other subsystems, but we were too busy doing it at V4L2.
>
>At the end of the last year, we added support for the Media Controller
>on DVB, using the existing API, in order to represent hybrid TV devices
>with radio, analog TV (video and audio) and digital TV.  However, as it
>didn't fit quite well, the DVB MC support was marked as broken before
>reaching upstream, and we designed and implemented a next generation of
>the API, together with userspace applications to test it.
>
>The ultimate goal will be to support the pipelines on a TV set and Set
>Top Boxes. On such devices, the streaming data pipeline can cover
>camera
>sensors, analog TV, digital TV, crypto/decrypto modules, audio and GPU.
>Also, they may have network interfaces that may be provided via DVB
>(with is very useful on Cable TV).
>
>So, as we want/need to represent and control the full pipeline, the
>media
>controller has to have support on different subsystems: V4L2, DVB,
>ALSA,
>DRM and Network. It also needs a way to share a common struct between
>those subsystems without making them depend on each other. So, it
>should
>use devres.
>
>We did a Media Controller Summit in July. During the summit, it was
>pointed that other subsystems like IIO (Linux Industrial I/O) have
>similar needs and also need to track complex pipelines. 

I was one who expressed interest as IIO maintainer. Unfortunately I am not going
 to make it to the KS this year.  The obvious IIO person for any discussions
 on this is Lars-Peter Clausen (he gets about!)

Sorry Mauro, this is something I would very much have like to hear more on/get
 more involved with. Just a spot of unfortunate timing!

>
>The goal of this tech topic is to present the MC next generation
>concepts and how the patches to support MC was written, showing some
>pipeline examples. 
>
>The next gen support patches were written in August, with some 
>additional patches written after that, and it has support for DVB
>and for one ALSA driver (snd-usb-audio).
>
>The patches are not merged yet at the media development tree and
>at -next, as one of the core developers of the media controller
>is missing time to review patches. So, while it was originally
>targeted to be merged on Kernel 4.4, it is likely that this will be 
>merged only for Kernel 4.5, in order to give him more time to
>review the patchset.
>
>PS.: I send already a [TECH TOPIC] about that on Aug, 6, and some
>people seemed to be interested.
>
>
>_______________________________________________
>Ksummit-discuss mailing list
>Ksummit-discuss@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Liam Girdwood]

On Mon, 2015-10-19 at 14:53 +0100, Mark Brown wrote:
> On Mon, Oct 19, 2015 at 10:33:04AM -0200, Mauro Carvalho Chehab wrote:
> 
> > We did a Media Controller Summit in July. During the summit, it was
> > pointed that other subsystems like IIO (Linux Industrial I/O) have
> > similar needs and also need to track complex pipelines. 
> 
> > The goal of this tech topic is to present the MC next generation
> > concepts and how the patches to support MC was written, showing some
> > pipeline examples. 
> 
> > The next gen support patches were written in August, with some 
> > additional patches written after that, and it has support for DVB
> > and for one ALSA driver (snd-usb-audio).
> 
> > The patches are not merged yet at the media development tree and
> > at -next, as one of the core developers of the media controller
> > is missing time to review patches. So, while it was originally
> > targeted to be merged on Kernel 4.4, it is likely that this will be 
> > merged only for Kernel 4.5, in order to give him more time to
> > review the patchset.
> 
> One fun thing on this that came up at the audio meeting we had in Dublin
> after ELC-E is that there is some desire to export the internal topology
> of audio devices to userspace using the same format that we're using to 
> load topology information for DSP firmwares (see include/sound/soc-topoloy.h).
> If we go ahead with that it'd create an alternative topology ABI, it
> seems like we should at least consider if it's worth trying to share
> things here.
> 
> I've not had a chance to look at the new media controller work yet, I've
> CCed Lars and Liam who have more knowledge in this area.  Unfortunately
> I don't think any of the people working directly on this will be at KS
> this year.

Just to give a little more background (for any non audio folks), there
are many audio DSPs today that can load their topology and other
capabilities at runtime depending on the target device (phone, laptop,
PC, etc) and the audio use cases.

Our intention is to also have a single audio driver per DSP family (i.e.
single skylake audio DSP driver to cover all skylake based devices). The
DSP driver would load it's topology data alongside the DSP firmware so
that the driver topology (i.e. graph, controls, capabilities) would be
aligned with the DSP firmware topology.

The process for creating the topology data involves either compiling a
text topology file to the binary topology file (used by the kernel) or
using a new ALSA C API to generate the binary topology file (as part of
a firmware toolchain). The topology text compiler and C API are both
upstream.

We are currently implementing de-compiler support to the userspace
compiler in order to convert the binary topology files into text files
for debug and development purposes.

Ideally I'd like to be able to dump the topology data using the same
format that it used for topology loading. That way we could easily feed
them into the de-compiler for development/debug.

Having a simple mechanism for dumping topology data is important as we
will need to be able to easily dump this data on Android and Chrome
alongside regular Linux for development and debug purposes. i.e.
cat /sys/some/dump/file > audio_topology

I'm also supportive of having a higher level and more elegant topology
query interface for non kernel/firmware developers using media
controller.

What I'd like to propose is that we support both mechanisms for dumping
the audio topology data. :-

1) Simple file dump using same format that topology is loaded. Used by
kernel/firmware developers only when media controller userspace not
available. Enabled by kernel Kconfig debug option.

2) Media controller API used by everyone else.

Liam

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]

On Mon, Oct 19, 2015 at 10:33:04AM -0200, Mauro Carvalho Chehab wrote:

> We did a Media Controller Summit in July. During the summit, it was
> pointed that other subsystems like IIO (Linux Industrial I/O) have
> similar needs and also need to track complex pipelines. 

> The goal of this tech topic is to present the MC next generation
> concepts and how the patches to support MC was written, showing some
> pipeline examples. 

> The next gen support patches were written in August, with some 
> additional patches written after that, and it has support for DVB
> and for one ALSA driver (snd-usb-audio).

> The patches are not merged yet at the media development tree and
> at -next, as one of the core developers of the media controller
> is missing time to review patches. So, while it was originally
> targeted to be merged on Kernel 4.4, it is likely that this will be 
> merged only for Kernel 4.5, in order to give him more time to
> review the patchset.

One fun thing on this that came up at the audio meeting we had in Dublin
after ELC-E is that there is some desire to export the internal topology
of audio devices to userspace using the same format that we're using to 
load topology information for DSP firmwares (see include/sound/soc-topoloy.h).
If we go ahead with that it'd create an alternative topology ABI, it
seems like we should at least consider if it's worth trying to share
things here.

I've not had a chance to look at the new media controller work yet, I've
CCed Lars and Liam who have more knowledge in this area.  Unfortunately
I don't think any of the people working directly on this will be at KS
this year.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Mauro Carvalho Chehab]

Em Mon, 12 Oct 2015 15:01:37 -0400
Theodore Ts'o <tytso@mit.edu> escreveu:

> This is an initial draft for the upcoming kernel summit.
> 
> It is still very drafty; in particular, just because a topic has been
> listed, it may turn out that the topic has been resolved off-line, or
> otherwise overtaken by events, in which case we will drop it.  In
> addition, we're also in the process of sending queries to the proposed
> topic leaders to see if they are willing to kick off the discussion,
> and so that is subject to change as well.
> 
> I'd appreciate comments about any topics that you think might be
> missing and that would be worth our discussing.  In addition, if you
> have strong opinions moving a topic from the technical session day to
> the core day or vice versa, please make the case for the change.
> 
> There will be some TBD slots which can be scheduled at the last
> minute, but I'd like to get at least one full track of the technical
> sessions and most of the core sessions scheduled.
> 
> Many thanks,
> 
> 					- Ted
> 
> 
> 			  Kernel Summit Agenda
> 			   October 26-28, 2015
> 				 DRAFT
> 
> Web Version Agenda:		
> 
> * Monday: Workshops and break out sessions (overlap with Korea Linux Forum)
> * Tuesday: Dual-track technical sessions
> * Wednesday: Invite-only core attendees' plenary sessions
> 
> Dual-Track Technical sessions (Oct. 27th)
> =========================================
> 
> 9:00    - Welcome and agenda bashing
> 9:30	- Topic A1                   | Topic B1
> 10:00   - Topic A2                   | Topic B2
> 10:30   - Break
> 11:00	- Topic A3                   | Topic B3
> 11:30   - Topic A4                   | Topic B4
> 12:00   - Topic A5                   | Topic B5
> 12:30   - Lunch
> 1:30    - Topic A6                   | Topic B6
> 2:00    - Topic A7                   | Topic B7
> 2:30    - Break
> 3:00    - Topic A8                   | Topic B8
> 3:30    - Topic A9                   | Topic B9
> 4:00    - Topic A10                  | Topic B10
> 4:30    - Break
> 5:00    - Kernel Summit Tech Day -- What went well, what can we do better? 
> 5:30    - Group Photograph (for core day attendees)
> 6:30    - Dinner
> 
> Potential Tech topics
> =====================
> 
> 1. Mainline kernel on a cellphone (need someone to lead?)
> 2. Semantics of MMIO mapping attributes across archs (Benjamin Herrenschmidt)
> 3. GPIO API/ABI discussion (need someone to lead?)
> 4. System-wide interface to specify the level of PM tuning (Rafael J. Wysocki)
> 5. Giving freezer well-defined semantics (Jiri Kosina)
> 6. IRQ affinity (Christoph Hellwig)
> 7. benchmarking and performance trends (Chris Mason)
> 8. FPGAs and how to program them from kernel (need somone to lead?
> 9. Overlays and file(system) unioning issues (David Howells)
> 10. Firmware signing (David Howells)
> 11. Context tracking / nohz / RCU state (Andy Lutomirski)
> 12. userspace infrastructure services (Stephen Hemminger)
> 13. Kernel support for compute-offload devices (Joerg Roedel)
> 14. Improving Kernel Security 
> 15. Developer Workflow Security (Panel)

Could you please add a new topic:

16. The Next Generation of the Media Controller (Mauro Carvalho Chehab)

Along the years, we've been developing a mechanism at the Kernel to store
and present graphs to userspace, called Media Controller. The original
scope of the Media Controller were to store and represent pipeline
connections between hardware components on complex streaming devices,
like the ones that are used for webcams on cell phones, where there are
typically two camera sensors, and lots of processing units to enhance
the image and to convert it into different formats.

Since the beginning, we found that it would be useful to use it some day
on other subsystems, but we were too busy doing it at V4L2.

At the end of the last year, we added support for the Media Controller
on DVB, using the existing API, in order to represent hybrid TV devices
with radio, analog TV (video and audio) and digital TV.  However, as it
didn't fit quite well, the DVB MC support was marked as broken before
reaching upstream, and we designed and implemented a next generation of
the API, together with userspace applications to test it.

The ultimate goal will be to support the pipelines on a TV set and Set
Top Boxes. On such devices, the streaming data pipeline can cover camera
sensors, analog TV, digital TV, crypto/decrypto modules, audio and GPU.
Also, they may have network interfaces that may be provided via DVB
(with is very useful on Cable TV).

So, as we want/need to represent and control the full pipeline, the media
controller has to have support on different subsystems: V4L2, DVB, ALSA,
DRM and Network. It also needs a way to share a common struct between
those subsystems without making them depend on each other. So, it should
use devres.

We did a Media Controller Summit in July. During the summit, it was
pointed that other subsystems like IIO (Linux Industrial I/O) have
similar needs and also need to track complex pipelines. 

The goal of this tech topic is to present the MC next generation
concepts and how the patches to support MC was written, showing some
pipeline examples. 

The next gen support patches were written in August, with some 
additional patches written after that, and it has support for DVB
and for one ALSA driver (snd-usb-audio).

The patches are not merged yet at the media development tree and
at -next, as one of the core developers of the media controller
is missing time to review patches. So, while it was originally
targeted to be merged on Kernel 4.4, it is likely that this will be 
merged only for Kernel 4.5, in order to give him more time to
review the patchset.

PS.: I send already a [TECH TOPIC] about that on Aug, 6, and some
people seemed to be interested.

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Rob Herring]

On Fri, Oct 16, 2015 at 2:57 AM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> Rob,
>
> On Thu, Oct 15, 2015 at 07:41:15PM -0500, Rob Herring wrote:
>> - Gaps in driver subsystems:
>>   - WiFi - Android gaps: mode switching, P2P, Chromecast, roaming,
>> ePNO, Passpoint
>>   - DRM/Graphics
>>   - BT/GPS/NFC - proper kernel drivers for serial devices
> Could you elaborate by what you mean by "proper" drivers in that
> context?

Exactly what was discussed on the thread early for this topic.
Creating in kernel drivers for serial attached devices like BT to
handle all the chip and board specific bits rather than do this in
userspace.

Rob

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Linus Walleij]

On Fri, Oct 16, 2015 at 10:00 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Arnd:

>> My understanding is that MediaTek has improved much recently and their
>> mt76 wireless driver source is available and getting upstreamed (...)

> are sure that Mediatek got better? I am not convinced by that.
>
> I think there is also a large difference in their MiniPCI cards compared to
> their connectivity hub in their SoC. The Bluetooth side for example is
> largely copying existing drivers, hacking their vendor specific behavior
> in and then throwing it over the wall.

When discussing the sadly unsupported MT7630E MiniPCI card
which has both WiFi and Bluetooth Jakub Kicinski elaborated a bit
on the story there:
http://marc.info/?l=linux-wireless&m=143815707108278&w=2

It seems Mediatek got a bit of internal struggle, the kernel doing
three different drivers sharing aspects of the same chip(s)
and general mishmash due to a cocktail of factors: organizational,
company consolidation etc, but also due to a few chips,
especially MT7630E, ending up in a technical middle-ground
between two families of chips.

The person writing the MT7630E driver was obviously intending
to upstream it, I can see the beginnings of an upstream attempt
in the source code, but was apparently removed from that task
before s/he could complete it.

Sadly there is a bunch of users stuck with this card. They
(including my daughter) survive by using a forwardport of the
code drop from Mediatek, but who knows how long that thing
will even compile.

Linus Walleij

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

On Thu, Oct 15, 2015 at 07:41:15PM -0500, Rob Herring wrote:
> On Mon, Oct 12, 2015 at 2:01 PM, Theodore Ts'o <tytso@mit.edu> wrote:

>   - Battery/charger issues

That's as much the whole situation with support for new USB standards as
anything specific to batteries, considerations around USB are what's
causing disrupton here.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Geert Uytterhoeven]

Hi Samuel,

On Fri, Oct 16, 2015 at 9:57 AM, Samuel Ortiz <sameo@linux.intel.com> wrote:
> On Thu, Oct 15, 2015 at 07:41:15PM -0500, Rob Herring wrote:
>> - Gaps in driver subsystems:
>>   - WiFi - Android gaps: mode switching, P2P, Chromecast, roaming,
>> ePNO, Passpoint
>>   - DRM/Graphics
>>   - BT/GPS/NFC - proper kernel drivers for serial devices
> Could you elaborate by what you mean by "proper" drivers in that
> context?

I think this is about the ongoing work to represent serial devices as a bus,
so serial slaves can connect to them using a standard API.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Arnd Bergmann]

On Friday 16 October 2015 10:00:18 Marcel Holtmann wrote:
> 
> >> On Thu, 2015-10-15 at 19:41 -0500, Rob Herring wrote:
> >> the unwillingness of chip
> >> vendors (hi Broadcom, Qualcomm, MediaTek) to have an upstream driver
> >> that they actually use (some of those do support an upstream driver,
> >> but don't ship that one and it doesn't nearly have the necessary
> >> features, while the actually used (still open source [1]) driver is a
> >> pile of spaghetti code that we'd probably never merge upstream...)
> >> 
> >> [1] except for MediaTek, I think, who seem to never be releasing source
> >> code for any of their kernels
> >> 
> > 
> > (getting offtopic here)
> > 
> > My understanding is that MediaTek has improved much recently and their
> > mt76 wireless driver source is available and getting upstreamed now
> > and integrated into openwrt now. OTOH, Broadcom apparently regressed and is
> > no longer releasing any source code to their newer softmac parts (bcm4360,
> > bcm4352) or patching brcmsmac to support them, while they on the other
> > hand got better at upstreaming their SoC support recently.
> 
> are sure that Mediatek got better? I am not convinced by that.
> 
> I think there is also a large difference in their MiniPCI cards compared
> to their connectivity hub in their SoC. The Bluetooth side for example
> is largely copying existing drivers, hacking their vendor specific
> behavior in and then throwing it over the wall.

It's of course a large company, and there are several business units that
are not all improving equally. There is however a big difference between
basically ignoring upstream as of a few years ago and now being as good
as any other SoC vendor that works with us on arm-soc.

The areas that I have observed improving most are:

- support for their wireless AP solutions (mtk76xx, formerly ralink) is
  getting much better. While this is mainly driven by OpenWRT on the
  upstream side, they are working together. All there is today is the
  MIPS based support, but I'm sure that the recently announced ARM
  based parts will get upstreamed quickly too as they are quite
  similar.

- Mobile phone/tablet SoC support is getting merged upstream for both
  ARM32 (mt65xx, mt81xx) and ARM64 (mt67xx, mt81xx too) in a good way.
  They are still doing groundwork at the moment, so I'm not surprised
  that the people that rewrite the code into upstreamable drivers
  have not arrived at bluetooth yet, but it seems likely that they
  will get there as they do one subsystem at a time.

The main concern that is still valid for all their SoCs is whether they
eventually get to the point where full support for any product is
in mainline by the time that it gets into user's hands, which is really
what our KS session is about.

	Arnd

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Christian Borntraeger]

Am 12.10.2015 um 21:01 schrieb Theodore Ts'o:
> This is an initial draft for the upcoming kernel summit.
> 
> It is still very drafty; in particular, just because a topic has been
> listed, it may turn out that the topic has been resolved off-line, or
> otherwise overtaken by events, in which case we will drop it.  In
> addition, we're also in the process of sending queries to the proposed
> topic leaders to see if they are willing to kick off the discussion,
> and so that is subject to change as well.
> 
> I'd appreciate comments about any topics that you think might be
> missing and that would be worth our discussing.  In addition, if you
> have strong opinions moving a topic from the technical session day to
> the core day or vice versa, please make the case for the change.
> 
> There will be some TBD slots which can be scheduled at the last
> minute, but I'd like to get at least one full track of the technical
> sessions and most of the core sessions scheduled.
> 
> Many thanks,
> 
> 					- Ted
> 
> 
> 			  Kernel Summit Agenda
> 			   October 26-28, 2015
> 				 DRAFT
> 
> Web Version Agenda:		
> 
> * Monday: Workshops and break out sessions (overlap with Korea Linux Forum)

Might be a dumb questions, but are the Monday workshops planned via the Korea
Linux Forum or do we have a separate list of planned workshops?

Christian

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Johannes Berg]

On Fri, 2015-10-16 at 09:55 +0200, Arnd Bergmann wrote:

> (getting offtopic here)
> 
> My understanding is that MediaTek has improved much recently and their
> mt76 wireless driver source is available and getting upstreamed now
> and integrated into openwrt now. 

Yes, mostly a community effort from what I can tell, although surely
they released something. However, it's a different product line as far
as I know.


johannes

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Marcel Holtmann]

Hi Arnd,

>> On Thu, 2015-10-15 at 19:41 -0500, Rob Herring wrote:
>> the unwillingness of chip
>> vendors (hi Broadcom, Qualcomm, MediaTek) to have an upstream driver
>> that they actually use (some of those do support an upstream driver,
>> but don't ship that one and it doesn't nearly have the necessary
>> features, while the actually used (still open source [1]) driver is a
>> pile of spaghetti code that we'd probably never merge upstream...)
>> 
>> [1] except for MediaTek, I think, who seem to never be releasing source
>> code for any of their kernels
>> 
> 
> (getting offtopic here)
> 
> My understanding is that MediaTek has improved much recently and their
> mt76 wireless driver source is available and getting upstreamed now
> and integrated into openwrt now. OTOH, Broadcom apparently regressed and is
> no longer releasing any source code to their newer softmac parts (bcm4360,
> bcm4352) or patching brcmsmac to support them, while they on the other
> hand got better at upstreaming their SoC support recently.

are sure that Mediatek got better? I am not convinced by that.

I think there is also a large difference in their MiniPCI cards compared to their connectivity hub in their SoC. The Bluetooth side for example is largely copying existing drivers, hacking their vendor specific behavior in and then throwing it over the wall.

Regards

Marcel

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Samuel Ortiz]

Rob,

On Thu, Oct 15, 2015 at 07:41:15PM -0500, Rob Herring wrote:
> - Gaps in driver subsystems:
>   - WiFi - Android gaps: mode switching, P2P, Chromecast, roaming,
> ePNO, Passpoint
>   - DRM/Graphics
>   - BT/GPS/NFC - proper kernel drivers for serial devices
Could you elaborate by what you mean by "proper" drivers in that
context?

Cheers,
Samuel.

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Arnd Bergmann]

On Friday 16 October 2015 08:52:37 Johannes Berg wrote:
> On Thu, 2015-10-15 at 19:41 -0500, Rob Herring wrote:
> the unwillingness of chip
> vendors (hi Broadcom, Qualcomm, MediaTek) to have an upstream driver
> that they actually use (some of those do support an upstream driver,
> but don't ship that one and it doesn't nearly have the necessary
> features, while the actually used (still open source [1]) driver is a
> pile of spaghetti code that we'd probably never merge upstream...)
> 
> [1] except for MediaTek, I think, who seem to never be releasing source
> code for any of their kernels
> 

(getting offtopic here)

My understanding is that MediaTek has improved much recently and their
mt76 wireless driver source is available and getting upstreamed now
and integrated into openwrt now. OTOH, Broadcom apparently regressed and is
no longer releasing any source code to their newer softmac parts (bcm4360,
bcm4352) or patching brcmsmac to support them, while they on the other
hand got better at upstreaming their SoC support recently.

	Arnd

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Johannes Berg]

On Thu, 2015-10-15 at 19:41 -0500, Rob Herring wrote:
> 
> - Gaps in driver subsystems:
>   - WiFi - Android gaps: mode switching, P2P, Chromecast, roaming,
> ePNO, Passpoint

I will be there, I can talk about this if desired, or you can poke me
on the hallway to talk about it :)

The overwhelming problem isn't our unwillingness to upstream this work
though, it's the unwillingness of Google to release requirements early
enough to make that possible, along with the unwillingness of chip
vendors (hi Broadcom, Qualcomm, MediaTek) to have an upstream driver
that they actually use (some of those do support an upstream driver,
but don't ship that one and it doesn't nearly have the necessary
features, while the actually used (still open source [1]) driver is a
pile of spaghetti code that we'd probably never merge upstream...)

[1] except for MediaTek, I think, who seem to never be releasing source
code for any of their kernels

johannes

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Rob Herring]

On Mon, Oct 12, 2015 at 2:01 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> This is an initial draft for the upcoming kernel summit.

[...]

> Dual-Track Technical sessions (Oct. 27th)
> =========================================
>
> 9:00    - Welcome and agenda bashing
> 9:30    - Topic A1                   | Topic B1
> 10:00   - Topic A2                   | Topic B2
> 10:30   - Break
> 11:00   - Topic A3                   | Topic B3
> 11:30   - Topic A4                   | Topic B4
> 12:00   - Topic A5                   | Topic B5
> 12:30   - Lunch
> 1:30    - Topic A6                   | Topic B6
> 2:00    - Topic A7                   | Topic B7
> 2:30    - Break
> 3:00    - Topic A8                   | Topic B8
> 3:30    - Topic A9                   | Topic B9
> 4:00    - Topic A10                  | Topic B10
> 4:30    - Break
> 5:00    - Kernel Summit Tech Day -- What went well, what can we do better?
> 5:30    - Group Photograph (for core day attendees)
> 6:30    - Dinner
>
> Potential Tech topics
> =====================
>
> 1. Mainline kernel on a cellphone (need someone to lead?)

I can lead this.

This is a kitchen sink of a topic though and something that's been
discussed several times recently at ELC and Plumbers. There's not much
point in rehashing the problem (go watch the conference videos), but
instead we should perhaps drill down into specific issues where we
have the right people present. Here's my list:

- Gaps in driver subsystems:
  - WiFi - Android gaps: mode switching, P2P, Chromecast, roaming,
ePNO, Passpoint
  - DRM/Graphics
  - BT/GPS/NFC - proper kernel drivers for serial devices
  - LEDs - tri-color support, defining roles (e.g. Android attention LED).
  - H/W video codecs
  - Camera
  - Battery/charger issues
- Android Memory management - What to do with ION?
- Power management - ?
- How to speed up mainlining process?

Other topics?


Rob

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Linus Walleij]

On Mon, Oct 12, 2015 at 9:01 PM, Theodore Ts'o <tytso@mit.edu> wrote:

> 3. GPIO API/ABI discussion (need someone to lead?)

Unfortunately I will not be at the KS, but I definately want to
know the outcome of this discussion for natural reasons.

Johan Hovold has been raising issues with the current
ABI on the list.

I am now trying to get a chardev prototype up for a richer/saner
userspace ABI for GPIO but other contributions and ideas
are welcome.

Yours,
Linus Walleij

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Josh Triplett]

On Mon, Oct 12, 2015 at 03:01:37PM -0400, Theodore Ts'o wrote:
> Dual-Track Technical sessions (Oct. 27th)
> =========================================
> 
> 9:00    - Welcome and agenda bashing
> 9:30	- Topic A1                   | Topic B1
> 10:00   - Topic A2                   | Topic B2
> 10:30   - Break
> 11:00	- Topic A3                   | Topic B3
> 11:30   - Topic A4                   | Topic B4
> 12:00   - Topic A5                   | Topic B5
> 12:30   - Lunch
> 1:30    - Topic A6                   | Topic B6
> 2:00    - Topic A7                   | Topic B7
> 2:30    - Break
> 3:00    - Topic A8                   | Topic B8
> 3:30    - Topic A9                   | Topic B9
> 4:00    - Topic A10                  | Topic B10
> 4:30    - Break
> 5:00    - Kernel Summit Tech Day -- What went well, what can we do better? 
> 5:30    - Group Photograph (for core day attendees)

Should this say "for tech day attendees"?

- Josh Triplett

[Ksummit-discuss] Draft agenda for the kernel summit

[Theodore Ts'o]

This is an initial draft for the upcoming kernel summit.

It is still very drafty; in particular, just because a topic has been
listed, it may turn out that the topic has been resolved off-line, or
otherwise overtaken by events, in which case we will drop it.  In
addition, we're also in the process of sending queries to the proposed
topic leaders to see if they are willing to kick off the discussion,
and so that is subject to change as well.

I'd appreciate comments about any topics that you think might be
missing and that would be worth our discussing.  In addition, if you
have strong opinions moving a topic from the technical session day to
the core day or vice versa, please make the case for the change.

There will be some TBD slots which can be scheduled at the last
minute, but I'd like to get at least one full track of the technical
sessions and most of the core sessions scheduled.

Many thanks,

					- Ted


			  Kernel Summit Agenda
			   October 26-28, 2015
				 DRAFT

Web Version Agenda:		

* Monday: Workshops and break out sessions (overlap with Korea Linux Forum)
* Tuesday: Dual-track technical sessions
* Wednesday: Invite-only core attendees' plenary sessions

Dual-Track Technical sessions (Oct. 27th)
=========================================

9:00    - Welcome and agenda bashing
9:30	- Topic A1                   | Topic B1
10:00   - Topic A2                   | Topic B2
10:30   - Break
11:00	- Topic A3                   | Topic B3
11:30   - Topic A4                   | Topic B4
12:00   - Topic A5                   | Topic B5
12:30   - Lunch
1:30    - Topic A6                   | Topic B6
2:00    - Topic A7                   | Topic B7
2:30    - Break
3:00    - Topic A8                   | Topic B8
3:30    - Topic A9                   | Topic B9
4:00    - Topic A10                  | Topic B10
4:30    - Break
5:00    - Kernel Summit Tech Day -- What went well, what can we do better? 
5:30    - Group Photograph (for core day attendees)
6:30    - Dinner

Potential Tech topics
=====================

1. Mainline kernel on a cellphone (need someone to lead?)
2. Semantics of MMIO mapping attributes across archs (Benjamin Herrenschmidt)
3. GPIO API/ABI discussion (need someone to lead?)
4. System-wide interface to specify the level of PM tuning (Rafael J. Wysocki)
5. Giving freezer well-defined semantics (Jiri Kosina)
6. IRQ affinity (Christoph Hellwig)
7. benchmarking and performance trends (Chris Mason)
8. FPGAs and how to program them from kernel (need somone to lead?
9. Overlays and file(system) unioning issues (David Howells)
10. Firmware signing (David Howells)
11. Context tracking / nohz / RCU state (Andy Lutomirski)
12. userspace infrastructure services (Stephen Hemminger)
13. Kernel support for compute-offload devices (Joerg Roedel)
14. Improving Kernel Security 
15. Developer Workflow Security (Panel)

Core Day (Oct. 28th)
====================

9:00    - Welcome and agenda bashing
9:30	- Live patching (still needed?)
10:00   - Testing (Masahami, Shuah)
10:30   - Break
11:00	- Kernel Security - Readout and further discussion
11:30   - Recruitment; Outreach Programmes (Greg K-H)
12:00   - Lightweight per-cpu locks / restartable sequences (Andy Lutomirski)
12:30   - Lunch
1:30    - TBD
2:00    - TBD
2:30    - Break
3:00    - Kernel Development Process (Is Linus happy?)
3:30    - Issues with stable process (Sasha Levin)
4:00    - TBD
4:30    - Break
5:00    - Kernel Summit Core Day -- What went well, what can we do better? 
5:30    - Group Photograph (for core day attendees)
6:30    - Dinner

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Theodore Ts'o]

On Fri, Aug 15, 2014 at 05:27:31PM -0700, Darren Vincent Hart wrote:
> I would very much like to see a slot in the unconference to discuss this
> with the group. But failing that, perhaps this can serve as a starting
> point for a hallway conversation.

So the way to schedule a slot in the unconference track is to make a
comment in the Google doc spreadsheet suggesting a time, and starting
a thread on the ksummit-discuss list.  :-) 

If we start running low on slots we may need to apply some additional
criteria such as seeing sufficient interest on the mailing list of
people who would be interested in attending that session.  Right now,
though the criteria is fairly relaxed since we're not seeing a huge
rush of people wanting to propose topics --- although I suspect there
will be many more ideas for potential unconference sessions coming out
of the woodwork by Monday, during the core day, if not before.

Cheers,

						- Ted

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Darren Vincent Hart]

On Mon, 2014-08-11 at 18:45 -0400, Theodore Ts'o wrote:

OK, so my first time attending, hopefully this is the sort of feedback
you're looking for Ted:

> Unconference track:     http://goo.gl/xmeoSd
> 
> Possible unconference topics culled from discuss list
> 
> * Driver model/resources, ACPI/DT, etc. sigh

We had a good initial discussion on this. Since then, the ACPI 5.1
specification has been published, including the addition of the Device
Specific Properties mechanism (_DSD). An initial patch series in support
of this and the device_properties abstraction should hit the lists prior
(just barely) to kernel summit.

Beyond this specific patch series, there are some related SoC
configuration and enabling topics which came up that we could cover:
kernel and userspace pinconf control and SSDT overlays, for example.

I would very much like to see a slot in the unconference to discuss this
with the group. But failing that, perhaps this can serve as a starting
point for a hallway conversation.

Thanks,

Darren Hart

Re: [Ksummit-discuss] Draft agenda for the kernel summit

[Theodore Ts'o]

On Fri, Aug 15, 2014 at 08:15:55PM +0200, Julia Lawall wrote:
> > VIP Reception:
> >    Buses Leave at 6:15pm from the hotel
> >    Dinner at 6:30pm, at Bellwether (302 E. Illinois St, walking distance)
> 
> I'm not sure to understand this.  It looks like one block on the map.
> Have I misunderstood something?  The conference hotel is the one at  301 E
> North Water St, Chicago, IL 60611?

Sorry, that's my mistake.  There is no bus, since the conference hotel
is the one at 301 E. North Water St, and it's only a 3 minute walk to
the restaurant:

https://www.google.com/maps/dir/Sheraton+Chicago+Hotel+and+Towers,+301+E+North+Water+St,+Chicago,+IL+60611/Bellwether+Meeting+House+%26+Eatery,+302+E+Illinois+St,+Chicago,+IL+60611/@41.8904195,-87.6198161,17z/am=t/data=!3m1!4b1!4m16!4m15!1m5!1m1!1s0x880e2ca9ef45c823:0xba6bddb06ea558a1!2m2!1d-87.619314!2d41.889062!1m5!1m1!1s0x880e2caa3e3c6c55:0x9adfacec660b9a67!2m2!1d-87.619924!2d41.89113!2m1!6e4!3e2

I'll fix the agenda, thanks for pointing the bug!

     	     	     	    		 - Ted

[Ksummit-discuss] Draft agenda for the kernel summit

[Theodore Ts'o]

Hi,

Enclosed please find the draft agenda for the kernel summit next week.
Some of the talks haven't been confirmed yet, and there is still one,
maybe two TBD slots.

If you have any thoughts or comments about topics that you think that we
should absolutely cover, either from discussions on the ksummit-discuss
list (Paul McKenney put together a very nice summary here
https://www.kernel.org/pub/linux/kernel/people/paulmck/LKS/LKS2014Topics.html)
or which have come up more recently, please make any suggestions here on
this e-mail thread.

I'm also looking for feedback about whether there is anything left but
tattered horse hide from the "encouraging more reviewers" discussion.
As a program committee member observed to me privately, the problem is
still real, but it's not clear how much more we would get out of having
a face to face discussion that wasn't covered in the e-mail.

Thanks,

                                                - Ted


			  Kernel Summit Agenda
			   August 18-20, 2014
				 DRAFT

Sunday
======

VIP Reception:
   Buses Leave at 6:15pm from the hotel
   Dinner at 6:30pm, at Bellwether (302 E. Illinois St, walking distance)

Monday (core day)
======

8:00	- Breakfast 
9:00    - Welcome, Agenda Bashing
9:30	- IOMMU's and device drivers: error handling / reporting / isolation (David Woodhouse)
10:00   - Stable trees/workflow (Li Zefan, Greg K-H)
10:30   - Break
11:00	- Linux-next tree (Stephen Rothwell)
11:30   - Kernel tinification: shrinking the kernel and avoiding size
	  	 	       regressions (Josh Triplett)
12:00   - What makes Linus happy/unhappy regarding kernel development?
12:30   - Lunch
1:30    - Application Performance Regressions (Chris Mason)
2:00    - Kselftest
2:30    - Lightning Talks
3:00    - Break
3:30    - Reviewing new API/ABI (Andy Lutomirski, Michael Kerrisk)
4:00    - Encouraging more reviewers (*** anything left besides
	  	      badly flogged horseskin?)
4:30    - TBD
5:00    - Kernel Summit Core Day -- What went well, what can we do better? 
	  	 	(Theodore Ts'o)
5:45pm  - Group Photograph (for core day attendees)
6:00pm  - Dinner

Dinner at 6:00pm, Howell and Hood (435 North Michigan, walking distance)

Tuesday
=======

Workshops and Breakout sessions

Wireless:  http://goo.gl/btbKL6
Networking: 	http://goo.gl/Uyp4jL
Energy Aware Scheduling: http://goo.gl/rksyCj
Unconference track:	http://goo.gl/xmeoSd

Possible unconference topics culled from discuss list

* Driver model/resources, ACPI/DT, etc. sigh
* PM dependencies
* Metadata addendum to git commit
* printk softlockups

8:00    - Breakfast
10:30   - Break
12:30   - Lunch
3:00    - Break
4:45    - Group photograph
5:00    - LCNA First Timers Reception (all kernel developers are
                cordially invited)


Wednesday (open day / technical sessions)
=========

9:00    - LCNA Keynote: State of Linux (Jim Zemlin)
9:45    - LCNA Keynote: Linux kernel panel
10:30   - Break
11:15	- Common trends and bug patterns from static tools (Dave Jones,
		Dan Carpenter, Julia Lawall)
12:15   - Introduction to Smatch / Coccenille (Dan Carpenter / Julia Lawall)
1:05    - Lunch
2:30    - 2 factor authentication, Kernel.org update/discussion (Konstantin Ryabitsev)
3:30	- Runtime kernel checking: kmemleak, minimal lockdep, and others
	  	  (Caitlin Marinas, Li Zefan)
4:20    - Break
4:50    - Workshop report-outs (networking, wireless, energy-aware scheduling)
6:05    - Program end
6:30    - Buses depart for Evening Event

Dinner event (shared with LinuxConf NA)
Museum of Science and Industry, 7:00pm to 10:00pm