linux-api scope (Re: [PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers)

4 messages, 3 authors, 2016-02-04 · open the first message on its own page

linux-api scope (Re: [PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers)

From: Andy Lutomirski <luto@kernel.org>
Date: 2016-02-04 04:51:42

[cc list heavily trimmed]

On Wed, Feb 3, 2016 at 8:03 PM, Shuah Khan [off-list ref] wrote:
Change dvb frontend to check if tuner is free when
device opened in RW mode. Call to enable_source
handler either returns with an active pipeline to
tuner or error if tuner is busy. Tuner is released
when frontend is released calling the disable_source
handler.
As an actual subscriber to linux-api, I prefer for the linux-api list
to be lowish-volume and mostly limited to API-related things.  Is this
API related?  Do people think that these series should be sent to
linux-api?

Thanks,
Andy

Re: linux-api scope (Re: [PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers)

From: Michael Kerrisk (man-pages) <hidden>
Date: 2016-02-04 14:05:11

[expanding the CC a little]

Hi Andy, (and Shuah)

On 4 February 2016 at 05:51, Andy Lutomirski [off-list ref] wrote:
[cc list heavily trimmed]

On Wed, Feb 3, 2016 at 8:03 PM, Shuah Khan [off-list ref] wrote:
quoted
Change dvb frontend to check if tuner is free when
device opened in RW mode. Call to enable_source
handler either returns with an active pipeline to
tuner or error if tuner is busy. Tuner is released
when frontend is released calling the disable_source
handler.
As an actual subscriber to linux-api, I prefer for the linux-api list
to be lowish-volume and mostly limited to API-related things.  Is this
API related?  Do people think that these series should be sent to
linux-api?
I think not, and I'd like to stem the flood of mail to the list.
There's two things that we could do:

1. Shuah, I know we talked about this in the past, and it made some
sense to me at the time for kselftest to use linux-api@, but maybe
it's time to create a dedicated list, and move the traffic there? It'd
help focus the traffic of linux-api more on its original purpose.

2. However, I think the bigger cause of the flood is the change made
to MAINTAINERS by Josh's commit
ea8f8fc8631d9f890580a94d57a18bfeb827fa2e:

+ABI/API
+L:     linux-api@vger.kernel.org
+F:     Documentation/ABI/
+F:     include/linux/syscalls.h
+F:     include/uapi/
+F:     kernel/sys_ni.c

The change was well-intentioned (I Acked it), but folk run
scripts/get-maintainers.pl without thinking too much about its output
and add all of the resulting lists and CCs to their patch submissions.
This means we get a lot of useless noise relating to drivers and
unrelated Documentation changes, and actually miss some of the really
important changes (e.g., extensions of system calls; and new /proc
entries tend to get lost in the noise). Furthermore, people doing
things such as adding new system calls often don't tun
scripts/get-maintainers.pl it seems. Certainly, I have to often enough
remind peple to CC linux-api when adding new system calls.

I'll craft a patch to trim the MAINTAINERS entry.

Cheers,

Michael



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


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: linux-api scope (Re: [PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers)

From: Shuah Khan <hidden>
Date: 2016-02-04 14:36:06

On 02/04/2016 07:04 AM, Michael Kerrisk (man-pages) wrote:
[expanding the CC a little]

Hi Andy, (and Shuah)

On 4 February 2016 at 05:51, Andy Lutomirski [off-list ref] wrote:
quoted
[cc list heavily trimmed]

On Wed, Feb 3, 2016 at 8:03 PM, Shuah Khan [off-list ref] wrote:
quoted
Change dvb frontend to check if tuner is free when
device opened in RW mode. Call to enable_source
handler either returns with an active pipeline to
tuner or error if tuner is busy. Tuner is released
when frontend is released calling the disable_source
handler.
As an actual subscriber to linux-api, I prefer for the linux-api list
to be lowish-volume and mostly limited to API-related things.  Is this
API related?  Do people think that these series should be sent to
linux-api?
I think not, and I'd like to stem the flood of mail to the list.
There's two things that we could do:
I simply followed the getmaintainers generate3d list.
A bit surprised to see linux-api, but didn't want to
leave it out.
1. Shuah, I know we talked about this in the past, and it made some
sense to me at the time for kselftest to use linux-api@, but maybe
it's time to create a dedicated list, and move the traffic there? It'd
help focus the traffic of linux-api more on its original purpose.
Yes that is a good plan - I will request a new mailing list and
send in a patch to Kselftest MAINTIANER's entry.
2. However, I think the bigger cause of the flood is the change made
to MAINTAINERS by Josh's commit
ea8f8fc8631d9f890580a94d57a18bfeb827fa2e:

+ABI/API
+L:     linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+F:     Documentation/ABI/
+F:     include/linux/syscalls.h
+F:     include/uapi/
+F:     kernel/sys_ni.c

The change was well-intentioned (I Acked it), but folk run
scripts/get-maintainers.pl without thinking too much about its output
and add all of the resulting lists and CCs to their patch submissions.
This means we get a lot of useless noise relating to drivers and
unrelated Documentation changes, and actually miss some of the really
important changes (e.g., extensions of system calls; and new /proc
entries tend to get lost in the noise). Furthermore, people doing
things such as adding new system calls often don't tun
scripts/get-maintainers.pl it seems. Certainly, I have to often enough
remind peple to CC linux-api when adding new system calls.

I'll craft a patch to trim the MAINTAINERS entry.
Thanks for doing this,
-- Shuah



-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978

Re: linux-api scope (Re: [PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers)

From: Michael Kerrisk (man-pages) <hidden>
Date: 2016-02-04 19:49:13

Hi Shuah,

On 4 February 2016 at 15:35, Shuah Khan [off-list ref] wrote:
On 02/04/2016 07:04 AM, Michael Kerrisk (man-pages) wrote:
quoted
[expanding the CC a little]

Hi Andy, (and Shuah)

On 4 February 2016 at 05:51, Andy Lutomirski [off-list ref] wrote:
quoted
[cc list heavily trimmed]

On Wed, Feb 3, 2016 at 8:03 PM, Shuah Khan [off-list ref] wrote:
quoted
Change dvb frontend to check if tuner is free when
device opened in RW mode. Call to enable_source
handler either returns with an active pipeline to
tuner or error if tuner is busy. Tuner is released
when frontend is released calling the disable_source
handler.
As an actual subscriber to linux-api, I prefer for the linux-api list
to be lowish-volume and mostly limited to API-related things.  Is this
API related?  Do people think that these series should be sent to
linux-api?
I think not, and I'd like to stem the flood of mail to the list.
There's two things that we could do:
I simply followed the getmaintainers generate3d list.
A bit surprised to see linux-api, but didn't want to
leave it out.
Yep -- you and many others. That's the problem with automated solutions ;-).
quoted
1. Shuah, I know we talked about this in the past, and it made some
sense to me at the time for kselftest to use linux-api@, but maybe
it's time to create a dedicated list, and move the traffic there? It'd
help focus the traffic of linux-api more on its original purpose.
Yes that is a good plan - I will request a new mailing list and
send in a patch to Kselftest MAINTIANER's entry.
Thanks, and sorry for the inconvenience. I guess a prominent mail onto
linux-api@ advertising the new list, once it has been created, would
not go amiss.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help