* Re: [PATCH 5/5] kselftest: Add exit code defines
From: Michael Ellerman @ 2015-03-29 23:44 UTC (permalink / raw)
To: Darren Hart
Cc: Linux Kernel Mailing List, Shuah Khan,
linux-api-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, Peter Zijlstra,
Thomas Gleixner, Davidlohr Bueso, KOSAKI Motohiro
In-Reply-To: <5515E323.1070800-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On Fri, 2015-03-27 at 16:09 -0700, Darren Hart wrote:
>
> On 3/27/15 3:59 PM, Michael Ellerman wrote:
> > On Fri, 2015-03-27 at 15:17 -0700, Darren Hart wrote:
> >> Define the exit codes with KSFT_PASS and similar so tests can use these
> >> directly if they choose. Also enable harnesses and other tooling to use
> >> the defines instead of hardcoding the return codes.
> >
> > +1
> >
> >> diff --git a/tools/testing/selftests/kselftest.h b/tools/testing/selftests/kselftest.h
> >> index 572c888..ef1c80d 100644
> >> --- a/tools/testing/selftests/kselftest.h
> >> +++ b/tools/testing/selftests/kselftest.h
> >> @@ -13,6 +13,13 @@
> >> #include <stdlib.h>
> >> #include <unistd.h>
> >>
> >> +/* define kselftest exit codes */
> >> +#define KSFT_PASS 0
> >> +#define KSFT_FAIL 1
> >> +#define KSFT_XFAIL 2
> >> +#define KSFT_XPASS 3
> >> +#define KSFT_SKIP 4
> >> +
> >> /* counters */
> >> struct ksft_count {
> >> unsigned int ksft_pass;
> >> @@ -40,23 +47,23 @@ static inline void ksft_print_cnts(void)
> >>
> >> static inline int ksft_exit_pass(void)
> >> {
> >> - exit(0);
> >> + exit(KSFT_PASS);
> >> }
> >
> > Am I the only person who's bothered by the fact that these don't actually
> > return int?
>
> That bothered me to, but I couldn't be bothered to go read the manuals
> apparently to come up with a compelling argument :-)
Yeah, obviously the compiler accepts it, but it's still a bit weird.
> I also think the ksft_exit* routines should go ahead and increment the
> counters (at least optionally) so we don't have to call two functions.
But the ksft_exit_*() routines exit, so there's no point incrementing the
counters. Unless they *also* print the counters before exiting?
To be honest I think we need to decide if the selftests are going to speak TAP
or xUnit or whatever, and then switch to that. In their current form these
helpers don't help much.
cheers
^ permalink raw reply
* Re: [PATCH 2/5] selftest/futex: Update Makefile to use lib.mk
From: Michael Ellerman @ 2015-03-29 23:49 UTC (permalink / raw)
To: Darren Hart
Cc: Linux Kernel Mailing List, Shuah Khan,
linux-api-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, Peter Zijlstra,
Thomas Gleixner, Davidlohr Bueso, KOSAKI Motohiro
In-Reply-To: <95d599bc531666252f8e3f4e467d5f94af2a7ad2.1427493640.git.dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On Fri, 2015-03-27 at 15:17 -0700, Darren Hart wrote:
> Adapt the futextest Makefiles to use lib.mk macros for RUN_TESTS and
> EMIT_TESTS. For now, we reuse the run.sh mechanism provided by
> futextest. This doesn't provide the standard selftests: [PASS|FAIL]
> format, but the tests provide very similar output already.
>
> This results in the run_kselftest.sh script for futexes including a
> single line: ./run.sh
>
> Cc: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
> Cc: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
> Cc: Davidlohr Bueso <dave-h16yJtLeMjHk1uMJSBkQmQ@public.gmane.org>
> Cc: KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
> Signed-off-by: Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> ---
> tools/testing/selftests/futex/Makefile | 21 +++++++++++++++++++++
> tools/testing/selftests/futex/functional/Makefile | 4 ++++
> 2 files changed, 25 insertions(+)
>
> diff --git a/tools/testing/selftests/futex/Makefile b/tools/testing/selftests/futex/Makefile
> index 8629187..6a17529 100644
> --- a/tools/testing/selftests/futex/Makefile
> +++ b/tools/testing/selftests/futex/Makefile
> @@ -1,8 +1,29 @@
> SUBDIRS := functional
>
> +TEST_PROGS := run.sh
> +
> .PHONY: all clean
lib.mk defines all & clean as PHONY for you.
> all:
> for DIR in $(SUBDIRS); do $(MAKE) -C $$DIR $@ ; done
>
> +include ../lib.mk
> +
> +override define RUN_TESTS
> + ./run.sh
> +endef
Do you need to do this override? The standard logic should work AFAICS, or do
you not want the echo logic?
> +override define INSTALL_RULE
> + mkdir -p $(INSTALL_PATH)
> + install -t $(INSTALL_PATH) $(TEST_PROGS) $(TEST_PROGS_EXTENDED) $(TEST_FILES)
> +
> + @for SUBDIR in $(SUBDIRS); do \
> + $(MAKE) -C $$SUBDIR INSTALL_PATH=$(INSTALL_PATH)/$$SUBDIR install; \
> + done;
> +endef
> +
> +override define EMIT_TESTS
> + echo "./run.sh"
> +endef
Ditto.
cheers
^ permalink raw reply
* Re: [PATCH v11 tip 6/9] samples: bpf: simple non-portable kprobe filter example
From: Jovi Zhangwei @ 2015-03-30 0:34 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Ingo Molnar, Steven Rostedt, Namhyung Kim,
Arnaldo Carvalho de Melo, Jiri Olsa, Masami Hiramatsu,
David S. Miller, Daniel Borkmann, Peter Zijlstra, linux-api,
netdev, LKML
In-Reply-To: <1427312966-8434-7-git-send-email-ast@plumgrid.com>
On Wed, Mar 25, 2015 at 12:49 PM, Alexei Starovoitov <ast@plumgrid.com> wrote:
> tracex1_kern.c - C program compiled into BPF.
> It attaches to kprobe:netif_receive_skb
> When skb->dev->name == "lo", it prints sample debug message into trace_pipe
> via bpf_trace_printk() helper function.
>
> tracex1_user.c - corresponding user space component that:
> - loads bpf program via bpf() syscall
> - opens kprobes:netif_receive_skb event via perf_event_open() syscall
> - attaches the program to event via ioctl(event_fd, PERF_EVENT_IOC_SET_BPF, prog_fd);
> - prints from trace_pipe
>
> Note, this bpf program is non-portable. It must be recompiled with current
> kernel headers. kprobe is not a stable ABI and bpf+kprobe scripts
> may no longer be meaningful when kernel internals change.
>
> No matter in what way the kernel changes, neither the kprobe, nor the bpf
> program can ever crash or corrupt the kernel, assuming the kprobes, perf and
> bpf subsystem has no bugs.
>
> The verifier will detect that the program is using bpf_trace_printk() and
> the kernel will print 'this is a DEBUG kernel' warning banner, which means that
> bpf_trace_printk() should be used for debugging of the bpf program only.
>
> Usage:
> $ sudo tracex1
> ping-19826 [000] d.s2 63103.382648: : skb ffff880466b1ca00 len 84
> ping-19826 [000] d.s2 63103.382684: : skb ffff880466b1d300 len 84
>
> ping-19826 [000] d.s2 63104.382533: : skb ffff880466b1ca00 len 84
> ping-19826 [000] d.s2 63104.382594: : skb ffff880466b1d300 len 84
>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
> ---
> samples/bpf/Makefile | 4 ++
> samples/bpf/bpf_helpers.h | 6 +++
> samples/bpf/bpf_load.c | 125 ++++++++++++++++++++++++++++++++++++++++---
> samples/bpf/bpf_load.h | 3 ++
> samples/bpf/libbpf.c | 14 ++++-
> samples/bpf/libbpf.h | 5 +-
> samples/bpf/sock_example.c | 2 +-
> samples/bpf/test_verifier.c | 2 +-
> samples/bpf/tracex1_kern.c | 50 +++++++++++++++++
> samples/bpf/tracex1_user.c | 25 +++++++++
> 10 files changed, 224 insertions(+), 12 deletions(-)
> create mode 100644 samples/bpf/tracex1_kern.c
> create mode 100644 samples/bpf/tracex1_user.c
>
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index b5b3600dcdf5..51f6f01e5a3a 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -6,23 +6,27 @@ hostprogs-y := test_verifier test_maps
> hostprogs-y += sock_example
> hostprogs-y += sockex1
> hostprogs-y += sockex2
> +hostprogs-y += tracex1
>
> test_verifier-objs := test_verifier.o libbpf.o
> test_maps-objs := test_maps.o libbpf.o
> sock_example-objs := sock_example.o libbpf.o
> sockex1-objs := bpf_load.o libbpf.o sockex1_user.o
> sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
> +tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
>
> # Tell kbuild to always build the programs
> always := $(hostprogs-y)
> always += sockex1_kern.o
> always += sockex2_kern.o
> +always += tracex1_kern.o
>
> HOSTCFLAGS += -I$(objtree)/usr/include
>
> HOSTCFLAGS_bpf_load.o += -I$(objtree)/usr/include -Wno-unused-variable
> HOSTLOADLIBES_sockex1 += -lelf
> HOSTLOADLIBES_sockex2 += -lelf
> +HOSTLOADLIBES_tracex1 += -lelf
>
> # point this to your LLVM backend with bpf support
> LLC=$(srctree)/tools/bpf/llvm/bld/Debug+Asserts/bin/llc
> diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
> index ca0333146006..1c872bcf5a80 100644
> --- a/samples/bpf/bpf_helpers.h
> +++ b/samples/bpf/bpf_helpers.h
> @@ -15,6 +15,12 @@ static int (*bpf_map_update_elem)(void *map, void *key, void *value,
> (void *) BPF_FUNC_map_update_elem;
> static int (*bpf_map_delete_elem)(void *map, void *key) =
> (void *) BPF_FUNC_map_delete_elem;
> +static int (*bpf_probe_read)(void *dst, int size, void *unsafe_ptr) =
> + (void *) BPF_FUNC_probe_read;
> +static unsigned long long (*bpf_ktime_get_ns)(void) =
> + (void *) BPF_FUNC_ktime_get_ns;
> +static int (*bpf_trace_printk)(const char *fmt, int fmt_size, ...) =
> + (void *) BPF_FUNC_trace_printk;
>
> /* llvm builtin functions that eBPF C program may use to
> * emit BPF_LD_ABS and BPF_LD_IND instructions
> diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
> index 1831d236382b..38dac5a53b51 100644
> --- a/samples/bpf/bpf_load.c
> +++ b/samples/bpf/bpf_load.c
> @@ -8,29 +8,70 @@
> #include <unistd.h>
> #include <string.h>
> #include <stdbool.h>
> +#include <stdlib.h>
> #include <linux/bpf.h>
> #include <linux/filter.h>
> +#include <linux/perf_event.h>
> +#include <sys/syscall.h>
> +#include <sys/ioctl.h>
> +#include <sys/mman.h>
> +#include <poll.h>
> #include "libbpf.h"
> #include "bpf_helpers.h"
> #include "bpf_load.h"
>
> +#define DEBUGFS "/sys/kernel/debug/tracing/"
> +
> static char license[128];
> +static int kern_version;
> static bool processed_sec[128];
> int map_fd[MAX_MAPS];
> int prog_fd[MAX_PROGS];
> +int event_fd[MAX_PROGS];
> int prog_cnt;
>
> static int load_and_attach(const char *event, struct bpf_insn *prog, int size)
> {
> - int fd;
> bool is_socket = strncmp(event, "socket", 6) == 0;
> -
> - if (!is_socket)
> - /* tracing events tbd */
> + bool is_kprobe = strncmp(event, "kprobe/", 7) == 0;
> + bool is_kretprobe = strncmp(event, "kretprobe/", 10) == 0;
> + enum bpf_prog_type prog_type;
> + char buf[256];
> + int fd, efd, err, id;
> + struct perf_event_attr attr = {};
> +
> + attr.type = PERF_TYPE_TRACEPOINT;
> + attr.sample_type = PERF_SAMPLE_RAW;
> + attr.sample_period = 1;
> + attr.wakeup_events = 1;
> +
> + if (is_socket) {
> + prog_type = BPF_PROG_TYPE_SOCKET_FILTER;
> + } else if (is_kprobe || is_kretprobe) {
> + prog_type = BPF_PROG_TYPE_KPROBE;
> + } else {
> + printf("Unknown event '%s'\n", event);
> return -1;
> + }
> +
> + if (is_kprobe || is_kretprobe) {
> + if (is_kprobe)
> + event += 7;
> + else
> + event += 10;
> +
> + snprintf(buf, sizeof(buf),
> + "echo '%c:%s %s' >> /sys/kernel/debug/tracing/kprobe_events",
> + is_kprobe ? 'p' : 'r', event, event);
> + err = system(buf);
Maybe we need to remember cleanup the kprobe_events in debugfs?
^ permalink raw reply
* Re: [PATCH net-next] tc: bpf: generalize pedit action
From: Jamal Hadi Salim @ 2015-03-30 0:52 UTC (permalink / raw)
To: Alexei Starovoitov, David S. Miller
Cc: Daniel Borkmann, Jiri Pirko, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1427424837-7757-1-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
On 03/26/15 22:53, Alexei Starovoitov wrote:
> existing TC action 'pedit' can munge any bits of the packet.
> Generalize it for use in bpf programs attached as cls_bpf and act_bpf via
> bpf_skb_store_bytes() helper function.
>
> Signed-off-by: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
> ---
>
> pedit is limited to 32-bit masked rewrites. Here let it be flexible.
>
> ptr = skb_header_pointer(skb, offset, len, buf);
> memcpy(ptr, from, len);
> if (ptr == buf)
> skb_store_bits(skb, offset, ptr, len);
>
> ^^ logic is the same as in pedit.
> shifts, mask, invert style of rewrite is easily done by the program.
> Just like arbitrary parsing of the packet and applying rewrites on demand.
>
Alexei/Daniel - I am backlogged on email; however, i didn quiet follow:
Is there another patch to pedit that help achieve the above?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v11 tip 6/9] samples: bpf: simple non-portable kprobe filter example
From: Alexei Starovoitov @ 2015-03-30 0:59 UTC (permalink / raw)
To: Jovi Zhangwei
Cc: Ingo Molnar, Steven Rostedt, Namhyung Kim,
Arnaldo Carvalho de Melo, Jiri Olsa, Masami Hiramatsu,
David S. Miller, Daniel Borkmann, Peter Zijlstra,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
LKML
In-Reply-To: <CAGdX0WESZ8kb7R3U38ciJambE_qBPnf3MiKiKa2wR-50H6_NyQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 3/29/15 5:34 PM, Jovi Zhangwei wrote:
>> + snprintf(buf, sizeof(buf),
>> + "echo '%c:%s %s' >> /sys/kernel/debug/tracing/kprobe_events",
>> + is_kprobe ? 'p' : 'r', event, event);
>> + err = system(buf);
>
> Maybe we need to remember cleanup the kprobe_events in debugfs?
the real tracing tool should be cleaning it up. This is sample code.
I didn't want to overcomplicate it with a chain of ctrl-c handlers.
Notice patch 7 is simply doing signal(SIGINT, int_exit) and prints
histogram when process is terminated. The kprobe cleaning logic would
have interfere with this and overall would have made these samples
unnecessary complex.
^ permalink raw reply
* Re: [PATCH net-next] tc: bpf: generalize pedit action
From: Alexei Starovoitov @ 2015-03-30 1:18 UTC (permalink / raw)
To: Jamal Hadi Salim, David S. Miller
Cc: Daniel Borkmann, Jiri Pirko, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <55189E5F.3050302-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>
On 3/29/15 5:52 PM, Jamal Hadi Salim wrote:
> On 03/26/15 22:53, Alexei Starovoitov wrote:
>> existing TC action 'pedit' can munge any bits of the packet.
>> Generalize it for use in bpf programs attached as cls_bpf and act_bpf via
>> bpf_skb_store_bytes() helper function.
>>
>> Signed-off-by: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
>> ---
>>
>> pedit is limited to 32-bit masked rewrites. Here let it be flexible.
>>
>> ptr = skb_header_pointer(skb, offset, len, buf);
>> memcpy(ptr, from, len);
>> if (ptr == buf)
>> skb_store_bits(skb, offset, ptr, len);
>>
>> ^^ logic is the same as in pedit.
>> shifts, mask, invert style of rewrite is easily done by the program.
>> Just like arbitrary parsing of the packet and applying rewrites on
>> demand.
>>
>
> Alexei/Daniel - I am backlogged on email; however, i didn quiet follow:
> Is there another patch to pedit that help achieve the above?
not really. If you meant adding 'array of bytes' attribute to pedit, it
won't be sufficient from program point of view. Programs are deciding
what and when to write, whereas pedit is static.
I'm working on csum helper patch and a set of examples that will
demonstrate the possibilities. I believe Daniel is preparing examples
as well for different use cases.
^ permalink raw reply
* [PATCH v2 3/3] Documentation/ABI: Update sysfs-driver-toshiba_acpi entry
From: Azael Avalos @ 2015-03-30 1:26 UTC (permalink / raw)
To: Darren Hart, platform-driver-x86-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
Cc: Azael Avalos
This patch updates the sysfs-driver-toshiba_acpi entry, adding the
missing entries for USB Sleep functions.
And also, while at the neighborhood, fix some typos and add a note
that some features require a reboot.
Signed-off-by: Azael Avalos <coproscefalo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
.../ABI/testing/sysfs-driver-toshiba_acpi | 93 +++++++++++++++++++---
1 file changed, 80 insertions(+), 13 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-toshiba_acpi b/Documentation/ABI/testing/sysfs-driver-toshiba_acpi
index ca9c71a..eed922e 100644
--- a/Documentation/ABI/testing/sysfs-driver-toshiba_acpi
+++ b/Documentation/ABI/testing/sysfs-driver-toshiba_acpi
@@ -8,9 +8,11 @@ Description: This file controls the keyboard backlight operation mode, valid
* 0x2 -> AUTO (also called TIMER)
* 0x8 -> ON
* 0x10 -> OFF
- Note that the kernel 3.16 onwards this file accepts all listed
+ Note that from kernel 3.16 onwards this file accepts all listed
parameters, kernel 3.15 only accepts the first two (FN-Z and
AUTO).
+ Also note that toggling this value on type 1 devices, requires
+ a reboot for changes to take effect.
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_backlight_timeout
@@ -67,15 +69,72 @@ Description: This file shows the current keyboard backlight type,
* 2 -> Type 2, supporting modes TIMER, ON and OFF
Users: KToshiba
+What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_sleep_charge
+Date: January 23, 2015
+KernelVersion: 4.0
+Contact: Azael Avalos <coproscefalo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+Description: This file controls the USB Sleep & Charge charging mode, which
+ can be:
+ * 0 -> Disabled (0x00)
+ * 1 -> Alternate (0x09)
+ * 2 -> Auto (0x21)
+ * 3 -> Typical (0x11)
+ Note that from kernel 4.1 onwards this file accepts all listed
+ values, kernel 4.0 only supports the first three.
+ Note that this feature only works when connected to power, if
+ you want to use it under battery, see the entry named
+ "sleep_functions_on_battery"
+Users: KToshiba
+
+What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/sleep_functions_on_battery
+Date: January 23, 2015
+KernelVersion: 4.0
+Contact: Azael Avalos <coproscefalo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+Description: This file controls the USB Sleep Functions under battery, and
+ set the level at which point they will be disabled, accepted
+ values can be:
+ * 0 -> Disabled
+ * 1-100 -> Battery level to disable sleep functions
+ Currently it prints two values, the first one indicates if the
+ feature is enabled or disabled, while the second one shows the
+ current battery level set.
+ Note that when the value is set to disabled, the sleep function
+ will only work when connected to power.
+Users: KToshiba
+
+What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_rapid_charge
+Date: January 23, 2015
+KernelVersion: 4.0
+Contact: Azael Avalos <coproscefalo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+Description: This file controls the USB Rapid Charge state, which can be:
+ * 0 -> Disabled
+ * 1 -> Enabled
+ Note that toggling this value requires a reboot for changes to
+ take effect.
+Users: KToshiba
+
+What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_sleep_music
+Date: January 23, 2015
+KernelVersion: 4.0
+Contact: Azael Avalos <coproscefalo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+Description: This file controls the Sleep & Music state, which values can be:
+ * 0 -> Disabled
+ * 1 -> Enabled
+ Note that this feature only works when connected to power, if
+ you want to use it under battery, see the entry named
+ "sleep_functions_on_battery"
+Users: KToshiba
+
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/version
-Date: February, 2015
-KernelVersion: 3.20
+Date: February 12, 2015
+KernelVersion: 4.0
Contact: Azael Avalos <coproscefalo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Description: This file shows the current version of the driver
+Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/fan
-Date: February, 2015
-KernelVersion: 3.20
+Date: February 12, 2015
+KernelVersion: 4.0
Contact: Azael Avalos <coproscefalo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Description: This file controls the state of the internal fan, valid
values are:
@@ -83,8 +142,8 @@ Description: This file controls the state of the internal fan, valid
* 1 -> ON
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_function_keys
-Date: February, 2015
-KernelVersion: 3.20
+Date: February 12, 2015
+KernelVersion: 4.0
Contact: Azael Avalos <coproscefalo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Description: This file controls the Special Functions (hotkeys) operation
mode, valid values are:
@@ -94,21 +153,29 @@ Description: This file controls the Special Functions (hotkeys) operation
and the hotkeys are accessed via FN-F{1-12}.
In the "Special Functions" mode, the F{1-12} keys trigger the
hotkey and the F{1-12} keys are accessed via FN-F{1-12}.
+ Note that toggling this value requires a reboot for changes to
+ take effect.
+Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/panel_power_on
-Date: February, 2015
-KernelVersion: 3.20
+Date: February 12, 2015
+KernelVersion: 4.0
Contact: Azael Avalos <coproscefalo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Description: This file controls whether the laptop should turn ON whenever
the LID is opened, valid values are:
* 0 -> Disabled
* 1 -> Enabled
+ Note that toggling this value requires a reboot for changes to
+ take effect.
+Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_three
-Date: February, 2015
-KernelVersion: 3.20
+Date: February 12, 2015
+KernelVersion: 4.0
Contact: Azael Avalos <coproscefalo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
-Description: This file controls whether the USB 3 functionality, valid
- values are:
+Description: This file controls the USB 3 functionality, valid values are:
* 0 -> Disabled (Acts as a regular USB 2)
* 1 -> Enabled (Full USB 3 functionality)
+ Note that toggling this value requires a reboot for changes to
+ take effect.
+Users: KToshiba
--
2.2.2
^ permalink raw reply related
* Re: [patch 1/2] mm, doc: cleanup and clarify munmap behavior for hugetlb memory
From: Hugh Dickins @ 2015-03-30 1:35 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Jonathan Corbet, Davide Libenzi, Luiz Capitulino,
Shuah Khan, Hugh Dickins, Andrea Arcangeli, Joern Engel,
Jianguo Wu, Eric B Munson, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.DEB.2.10.1503261621570.20009-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
On Thu, 26 Mar 2015, David Rientjes wrote:
> munmap(2) of hugetlb memory requires a length that is hugepage aligned,
> otherwise it may fail. Add this to the documentation.
Thanks for taking this on, David. But although munmap(2) is the one
Davide called out, it goes beyond that, doesn't it? To mprotect and
madvise and ...
I don't want to work out the list myself: is_vm_hugetlb_page() is
special-cased all over, and different syscalls react differently.
Which is another reason why, like you, I much prefer not to interfere
with the long established behavior: it would be very easy to introduce
bugs and worse inconsistencies.
And mprotect(2) is a good example of why we should not mess around
with the long established API here: changing an mprotect from failing
on a particular size to acting on a larger size is not a safe change.
Eric, I apologize for bringing you in to the discussion, and then
ignoring your input. I understand that you would like MAP_HUGETLB
to behave more understandably. We can all agree that the existing
behavior is unsatisfying. But it's many years too late now to
change it around - and I suspect that a full exercise to do so would
actually discover some good reasons why the original choices were made.
>
> This also cleans up the documentation and separates it into logical
> units: one part refers to MAP_HUGETLB and another part refers to
> requirements for shared memory segments.
>
> Signed-off-by: David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> ---
> Documentation/vm/hugetlbpage.txt | 21 +++++++++++++--------
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt
> --- a/Documentation/vm/hugetlbpage.txt
> +++ b/Documentation/vm/hugetlbpage.txt
> @@ -289,15 +289,20 @@ file systems, write system calls are not.
> Regular chown, chgrp, and chmod commands (with right permissions) could be
> used to change the file attributes on hugetlbfs.
>
> -Also, it is important to note that no such mount command is required if the
> +Also, it is important to note that no such mount command is required if
> applications are going to use only shmat/shmget system calls or mmap with
> -MAP_HUGETLB. Users who wish to use hugetlb page via shared memory segment
> -should be a member of a supplementary group and system admin needs to
> -configure that gid into /proc/sys/vm/hugetlb_shm_group. It is possible for
> -same or different applications to use any combination of mmaps and shm*
> -calls, though the mount of filesystem will be required for using mmap calls
> -without MAP_HUGETLB. For an example of how to use mmap with MAP_HUGETLB see
> -map_hugetlb.c.
> +MAP_HUGETLB. For an example of how to use mmap with MAP_HUGETLB see map_hugetlb
> +below.
> +
> +Users who wish to use hugetlb memory via shared memory segment should be a
> +member of a supplementary group and system admin needs to configure that gid
> +into /proc/sys/vm/hugetlb_shm_group. It is possible for same or different
> +applications to use any combination of mmaps and shm* calls, though the mount of
> +filesystem will be required for using mmap calls without MAP_HUGETLB.
> +
> +When using munmap(2) to unmap hugetlb memory, the length specified must be
> +hugepage aligned, otherwise it will fail with errno set to EINVAL.
Perhaps just adding something like "The same is true for mprotect(2)
and other such memory system calls." is good enough for here.
> +
>
> Examples
> ========
^ permalink raw reply
* Re: [PATCH 01/86] pci: export pci_ids.h
From: Michael S. Tsirkin @ 2015-03-30 6:48 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, Bjorn Helgaas, Jonathan Corbet, David S. Miller,
Hans Verkuil, Mauro Carvalho Chehab, Alexei Starovoitov,
stephen hemminger, Masahiro Yamada, Andy Shevchenko,
Andy Lutomirski, Rasmus Villemoes, Stephane Eranian, Huang Rui,
Peter Neubauer, linux-pci, linux-doc, linux-api
In-Reply-To: <20150329204047.GA5902@kroah.com>
On Sun, Mar 29, 2015 at 10:40:47PM +0200, Greg KH wrote:
> On Sun, Mar 29, 2015 at 03:37:01PM +0200, Michael S. Tsirkin wrote:
> > The macros in pci_ids.h are pretty useful for userspace
> > using the pci sysfs interface.
> > At the moment userspace is forced to duplicate these macros
> > (e.g. QEMU does this), it is better to expose them in
> > /usr/include/linux/pci_ids.h so everyone can just include
> > this header.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > include/linux/pci_ids.h | 2998 +-----------------------------------------
> > include/uapi/linux/pci_ids.h | 2997 +++++++++++++++++++++++++++++++++++++++++
>
> No, please use the pci ids file from the upstream pci id database
> instead.
> We shouldn't be putting these all in one file,
pci.txt says:
Please add PCI_VENDOR_ID_xxx for vendors
You want to change this policy, and get rid of
vendor ids in pci_ids.h completely?
Bjorn, what do you think of this?
> and pulling
> them out of drivers isn't ok.
This patchset is not pulling any files out of drivers fwiw.
> Userspace shouldn't need to know any of these, use libpci.
Unless I'm mistaken, libpci does not export a header with defines. It
has a text file pci.ids, but parsing that when all I want is e.g. locate
all intel devices is just too much overhead. No one wants that, so
people just duplicate headers.
Standard class IDs are even sillier to duplicate.
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH 86/86] usb/dwc3: move ids to pci_ids.h
From: Michael S. Tsirkin @ 2015-03-30 6:50 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Felipe Balbi, Bjorn Helgaas,
Thomas Gleixner, Andy Shevchenko, Andy Lutomirski, Peter Neubauer,
Huang Rui, Jean Delvare, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150329204200.GB5902-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Sun, Mar 29, 2015 at 10:42:00PM +0200, Greg Kroah-Hartman wrote:
> On Sun, Mar 29, 2015 at 03:43:40PM +0200, Michael S. Tsirkin wrote:
> > Comment says IDs should move to pci_ids.h, let's do it.
>
> No, please remove the comment, it's not needed in pci_ids.h at all.
vendor ID does belong in pci_ids.h though, so says
Documentation/PCI/pci.txt
^ permalink raw reply
* Re: [Intel-gfx] [PATCH] drm/i915: fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl
From: Daniel Vetter @ 2015-03-30 6:54 UTC (permalink / raw)
To: Jesse Barnes
Cc: Daniel Vetter, Jani Nikula, Tommi Rantala, Daniel Vetter,
David Airlie, linux-api-u79uwXL29TY76Z2rM5mHXA,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <551574C4.6000804-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On Fri, Mar 27, 2015 at 08:18:28AM -0700, Jesse Barnes wrote:
> On 03/27/2015 01:04 AM, Daniel Vetter wrote:
> > On Fri, Mar 27, 2015 at 08:39:56AM +0200, Jani Nikula wrote:
> >> On Thu, 26 Mar 2015, Tommi Rantala <tt.rantala-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>> Fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl, so that it
> >>> is different from the DRM_IOCTL_I915_SET_SPRITE_COLORKEY ioctl.
> >>>
> >>> Signed-off-by: Tommi Rantala <tt.rantala-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >>
> >> Whoa. Broken since its introduction in
> >>
> >> commit 8ea30864229e54b01ac0e9fe88c4b733a940ec4e
> >> Author: Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>
> >> Date: Tue Jan 3 08:05:39 2012 -0800
> >>
> >> drm/i915: add color key support v4
> >>
> >> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >
> > Nope, we'll just rip it out and replace it all with the drm_noop ioctl. At
> > least I didn't find any userspace anywhere and only broken definitions.
> > Proof enough this isn't useful.
> >
> > Even more so since that means we don't have to convert the get ioctl over
> > to atomic, yay! I'll send patches.
>
> Can we just skip the noop part and delete it altogether? It was only
> added speculatively and obviously never used at all...
The table is indexed, we need a dummy entry. I guess we could do a
drm_invalid_ioctl function too for these, but then whether you get an
error or not doesn't really matter for unused ioctls. Hence I've stuck
with drm_noop for all these removed ioctl (except when we need a more
tailore-made lie to keep userspace happy).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH 01/86] pci: export pci_ids.h
From: Greg KH @ 2015-03-30 6:55 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Bjorn Helgaas, Jonathan Corbet, David S. Miller,
Hans Verkuil, Mauro Carvalho Chehab, Alexei Starovoitov,
stephen hemminger, Masahiro Yamada, Andy Shevchenko,
Andy Lutomirski, Rasmus Villemoes, Stephane Eranian, Huang Rui,
Peter Neubauer, linux-pci, linux-doc, linux-api
In-Reply-To: <20150330083707-mutt-send-email-mst@redhat.com>
On Mon, Mar 30, 2015 at 08:48:44AM +0200, Michael S. Tsirkin wrote:
> On Sun, Mar 29, 2015 at 10:40:47PM +0200, Greg KH wrote:
> > On Sun, Mar 29, 2015 at 03:37:01PM +0200, Michael S. Tsirkin wrote:
> > > The macros in pci_ids.h are pretty useful for userspace
> > > using the pci sysfs interface.
> > > At the moment userspace is forced to duplicate these macros
> > > (e.g. QEMU does this), it is better to expose them in
> > > /usr/include/linux/pci_ids.h so everyone can just include
> > > this header.
> > >
> > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > ---
> > > include/linux/pci_ids.h | 2998 +-----------------------------------------
> > > include/uapi/linux/pci_ids.h | 2997 +++++++++++++++++++++++++++++++++++++++++
> >
> > No, please use the pci ids file from the upstream pci id database
> > instead.
>
>
> > We shouldn't be putting these all in one file,
>
> pci.txt says:
> Please add PCI_VENDOR_ID_xxx for vendors
> You want to change this policy, and get rid of
> vendor ids in pci_ids.h completely?
Please read the top of pci_ids.h. It hasn't had new ids added to it in
a long time.
> Bjorn, what do you think of this?
>
> > and pulling
> > them out of drivers isn't ok.
>
> This patchset is not pulling any files out of drivers fwiw.
It did for the USB gadget driver patch that I commented on.
> > Userspace shouldn't need to know any of these, use libpci.
>
> Unless I'm mistaken, libpci does not export a header with defines. It
> has a text file pci.ids, but parsing that when all I want is e.g. locate
> all intel devices is just too much overhead. No one wants that, so
> people just duplicate headers.
Why would userspace need the pci id of anything? Again, just use
libpci, isn't it fast enough? Don't duplicate existing logic.
Or use the hw database that libudev exports, which is already on your
machine and exports all of the pci ids from libpci directly.
> Standard class IDs are even sillier to duplicate.
Again, why does userspace need this?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 86/86] usb/dwc3: move ids to pci_ids.h
From: Greg Kroah-Hartman @ 2015-03-30 6:58 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Felipe Balbi, Bjorn Helgaas, Thomas Gleixner,
Andy Shevchenko, Andy Lutomirski, Peter Neubauer, Huang Rui,
Jean Delvare, linux-usb, linux-omap, linux-api
In-Reply-To: <20150330085001-mutt-send-email-mst@redhat.com>
On Mon, Mar 30, 2015 at 08:50:34AM +0200, Michael S. Tsirkin wrote:
> On Sun, Mar 29, 2015 at 10:42:00PM +0200, Greg Kroah-Hartman wrote:
> > On Sun, Mar 29, 2015 at 03:43:40PM +0200, Michael S. Tsirkin wrote:
> > > Comment says IDs should move to pci_ids.h, let's do it.
> >
> > No, please remove the comment, it's not needed in pci_ids.h at all.
>
> vendor ID does belong in pci_ids.h though, so says
> Documentation/PCI/pci.txt
Read the top of pci_ids.h please.
^ permalink raw reply
* Re: [PATCH 01/86] pci: export pci_ids.h
From: Michael S. Tsirkin @ 2015-03-30 7:15 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, Bjorn Helgaas, Jonathan Corbet, David S. Miller,
Hans Verkuil, Mauro Carvalho Chehab, Alexei Starovoitov,
stephen hemminger, Masahiro Yamada, Andy Shevchenko,
Andy Lutomirski, Rasmus Villemoes, Stephane Eranian, Huang Rui,
Peter Neubauer, linux-pci, linux-doc, linux-api
In-Reply-To: <20150330065522.GA10105@kroah.com>
On Mon, Mar 30, 2015 at 08:55:22AM +0200, Greg KH wrote:
> On Mon, Mar 30, 2015 at 08:48:44AM +0200, Michael S. Tsirkin wrote:
> > On Sun, Mar 29, 2015 at 10:40:47PM +0200, Greg KH wrote:
> > > On Sun, Mar 29, 2015 at 03:37:01PM +0200, Michael S. Tsirkin wrote:
> > > > The macros in pci_ids.h are pretty useful for userspace
> > > > using the pci sysfs interface.
> > > > At the moment userspace is forced to duplicate these macros
> > > > (e.g. QEMU does this), it is better to expose them in
> > > > /usr/include/linux/pci_ids.h so everyone can just include
> > > > this header.
> > > >
> > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > ---
> > > > include/linux/pci_ids.h | 2998 +-----------------------------------------
> > > > include/uapi/linux/pci_ids.h | 2997 +++++++++++++++++++++++++++++++++++++++++
> > >
> > > No, please use the pci ids file from the upstream pci id database
> > > instead.
> >
> >
> > > We shouldn't be putting these all in one file,
> >
> > pci.txt says:
> > Please add PCI_VENDOR_ID_xxx for vendors
> > You want to change this policy, and get rid of
> > vendor ids in pci_ids.h completely?
>
> Please read the top of pci_ids.h. It hasn't had new ids added to it in
> a long time.
OK, looks like pci.txt should be fixed then.
> > Bjorn, what do you think of this?
> >
> > > and pulling
> > > them out of drivers isn't ok.
> >
> > This patchset is not pulling any files out of drivers fwiw.
>
> It did for the USB gadget driver patch that I commented on.
>
> > > Userspace shouldn't need to know any of these, use libpci.
> >
> > Unless I'm mistaken, libpci does not export a header with defines. It
> > has a text file pci.ids, but parsing that when all I want is e.g. locate
> > all intel devices is just too much overhead. No one wants that, so
> > people just duplicate headers.
>
> Why would userspace need the pci id of anything?
Look at how they are used e.g. by QEMU, seabios, gpxe.
People want to say e.g. "find all network class devices".
> Again, just use
> libpci, isn't it fast enough? Don't duplicate existing logic.
This really depends on whether you want something else that
libpci provides. But if I just want e.g. standard class IDs,
I don't want to depend on libpci.
> Or use the hw database that libudev exports, which is already on your
> machine and exports all of the pci ids from libpci directly.
Same argument really.
> > Standard class IDs are even sillier to duplicate.
>
> Again, why does userspace need this?
>
> thanks,
>
> greg k-h
Mostly because it has a userspace driver, or is emulating
a hardware device.
For example, the VFIO driver uses the PCI hardware formats
as it's userspace/kernel interface. This means I need
a ton of PCI constants in userspace. Most of them are
already in pci_regs.h, and so exported. No problem here.
However class and prog interface IDs are not, they
are in pci_ids.h
Would you support splitting pci_ids.h to
include/uapi/linux/pci_ids.h with standard headers
and include/linux/pci_ids.h with device/vendor
specific ones?
--
MST
^ permalink raw reply
* Re: [PATCH 86/86] usb/dwc3: move ids to pci_ids.h
From: Michael S. Tsirkin @ 2015-03-30 7:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Felipe Balbi, Bjorn Helgaas,
Thomas Gleixner, Andy Shevchenko, Andy Lutomirski, Peter Neubauer,
Huang Rui, Jean Delvare, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150330065810.GA10508-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Mon, Mar 30, 2015 at 08:58:10AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Mar 30, 2015 at 08:50:34AM +0200, Michael S. Tsirkin wrote:
> > On Sun, Mar 29, 2015 at 10:42:00PM +0200, Greg Kroah-Hartman wrote:
> > > On Sun, Mar 29, 2015 at 03:43:40PM +0200, Michael S. Tsirkin wrote:
> > > > Comment says IDs should move to pci_ids.h, let's do it.
> > >
> > > No, please remove the comment, it's not needed in pci_ids.h at all.
> >
> > vendor ID does belong in pci_ids.h though, so says
> > Documentation/PCI/pci.txt
>
> Read the top of pci_ids.h please.
Thanks for pointing this out, looks like Documentation/PCI/pci.txt
should be improved.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Add preadv2/pwritev2 documentation.
From: Christoph Hellwig @ 2015-03-30 7:33 UTC (permalink / raw)
To: Andrew Morton
Cc: Milosz Tanski, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Christoph Hellwig, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-aio-Bw31MaZKKs3YtjvyW6yDsg, Mel Gorman, Volker Lendecke,
Tejun Heo, Jeff Moyer, Theodore Ts'o, Al Viro,
linux-api-u79uwXL29TY76Z2rM5mHXA, Michael Kerrisk,
linux-arch-u79uwXL29TY76Z2rM5mHXA, Dave Chinner
In-Reply-To: <20150327094932.31b5c9fc.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
On Fri, Mar 27, 2015 at 09:49:32AM -0700, Andrew Morton wrote:
> And let's have a think about EAGAIN vs EWOULDBLOCK.
Do you want a sentence saying they are always the same in Linux?
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Christoph Hellwig @ 2015-03-30 7:36 UTC (permalink / raw)
To: Jeremy Allison
Cc: Andrew Morton, Christoph Hellwig, Milosz Tanski, linux-kernel,
linux-fsdevel, linux-aio, Mel Gorman, Volker Lendecke, Tejun Heo,
Jeff Moyer, Theodore Ts'o, Al Viro, linux-api,
Michael Kerrisk, linux-arch, Dave Chinner
In-Reply-To: <20150327155854.GA5548@samba2>
On Fri, Mar 27, 2015 at 08:58:54AM -0700, Jeremy Allison wrote:
> The problem with the above is that we can't tell the difference
> between pread2() returning a short read because the pages are not
> in cache, or because someone truncated the file. So we need some
> way to differentiate this.
Is a race vs truncate really that time critical that you can't
wait for the thread pool to do the second read to notice it?
> My preference from userspace would be for pread2() to return
> EAGAIN if *all* the data requested is not available (where
> 'all' can be less than the size requested if the file has
> been truncated in the meantime).
That is easily implementable, but I can see that for example web apps
would be happy to get as much as possible. So if Samba can be ok
with short reads and only detecting the truncated case in the slow
path that would make life simpler. Otherwise we might indeed need two
flags.
^ permalink raw reply
* Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
From: Christoph Hellwig @ 2015-03-30 7:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Milosz Tanski, LKML, Christoph Hellwig,
linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, Mel Gorman,
Volker Lendecke, Tejun Heo, Jeff Moyer, Theodore Ts'o,
Al Viro, Linux API, Michael Kerrisk, linux-arch, Dave Chinner
In-Reply-To: <20150327100411.6823b9d7.akpm@linux-foundation.org>
On Fri, Mar 27, 2015 at 10:04:11AM -0700, Andrew Morton wrote:
> mm... I don't think we should be adding placeholders to the kernel API
> to support code which hasn't been written, tested, reviewed, merged,
> etc. It's possible none of this will ever happen and we end up with a
> syscall nobody needs or uses. Plus it's always possible that during
> this development we decide the pwrite2() interface needs alteration but
> it's too late.
>
> What would be the downside of deferring pwrite2() until it's all
> implemented?
It _is_ implemented. I just decided to submit it separately as Miklos
already has to deal with enough bikeshedding for his feature that I
don't want to put the burden of dealing with the BS for the one I wrote
on him.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH 01/86] pci: export pci_ids.h
From: Greg KH @ 2015-03-30 7:53 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Bjorn Helgaas, Jonathan Corbet, David S. Miller,
Hans Verkuil, Mauro Carvalho Chehab, Alexei Starovoitov,
stephen hemminger, Masahiro Yamada, Andy Shevchenko,
Andy Lutomirski, Rasmus Villemoes, Stephane Eranian, Huang Rui,
Peter Neubauer, linux-pci, linux-doc, linux-api
In-Reply-To: <20150330085617-mutt-send-email-mst@redhat.com>
On Mon, Mar 30, 2015 at 09:15:26AM +0200, Michael S. Tsirkin wrote:
> On Mon, Mar 30, 2015 at 08:55:22AM +0200, Greg KH wrote:
> > On Mon, Mar 30, 2015 at 08:48:44AM +0200, Michael S. Tsirkin wrote:
> > > On Sun, Mar 29, 2015 at 10:40:47PM +0200, Greg KH wrote:
> > > > On Sun, Mar 29, 2015 at 03:37:01PM +0200, Michael S. Tsirkin wrote:
> > > > > The macros in pci_ids.h are pretty useful for userspace
> > > > > using the pci sysfs interface.
> > > > > At the moment userspace is forced to duplicate these macros
> > > > > (e.g. QEMU does this), it is better to expose them in
> > > > > /usr/include/linux/pci_ids.h so everyone can just include
> > > > > this header.
> > > > >
> > > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > > ---
> > > > > include/linux/pci_ids.h | 2998 +-----------------------------------------
> > > > > include/uapi/linux/pci_ids.h | 2997 +++++++++++++++++++++++++++++++++++++++++
> > > >
> > > > No, please use the pci ids file from the upstream pci id database
> > > > instead.
> > >
> > >
> > > > We shouldn't be putting these all in one file,
> > >
> > > pci.txt says:
> > > Please add PCI_VENDOR_ID_xxx for vendors
> > > You want to change this policy, and get rid of
> > > vendor ids in pci_ids.h completely?
> >
> > Please read the top of pci_ids.h. It hasn't had new ids added to it in
> > a long time.
>
> OK, looks like pci.txt should be fixed then.
Please send a patch. As the original PCI kernel maintainer, I don't
think I ever noticed pci.txt. It was last "updated" in 2006...
> > Why would userspace need the pci id of anything?
>
> Look at how they are used e.g. by QEMU, seabios, gpxe.
> People want to say e.g. "find all network class devices".
Then use libpci.
> > Again, just use
> > libpci, isn't it fast enough? Don't duplicate existing logic.
>
> This really depends on whether you want something else that
> libpci provides. But if I just want e.g. standard class IDs,
> I don't want to depend on libpci.
Why not? Don't duplicate things that already are there just for this
very use.
Don't make us do kernel changes just because you don't want to depend on
either of the two different userspace packages that provide this
information in a standard way for userspace. Your system will have one
of those two packages in it, depending on it isn't a "burden" at all.
> > Or use the hw database that libudev exports, which is already on your
> > machine and exports all of the pci ids from libpci directly.
>
> Same argument really.
Because you don't want to depend on existing packages, doesn't mean we
have to accept kernel changes and maintain them for forever, as you are
now creating a new api that we will have to keep up to date and correct
for all time.
Again, depend on the packages that are already doing this work please.
> > > Standard class IDs are even sillier to duplicate.
> >
> > Again, why does userspace need this?
> >
> > thanks,
> >
> > greg k-h
>
> Mostly because it has a userspace driver, or is emulating
> a hardware device.
>
> For example, the VFIO driver uses the PCI hardware formats
> as it's userspace/kernel interface. This means I need
> a ton of PCI constants in userspace. Most of them are
> already in pci_regs.h, and so exported. No problem here.
>
> However class and prog interface IDs are not, they
> are in pci_ids.h
>
> Would you support splitting pci_ids.h to
> include/uapi/linux/pci_ids.h with standard headers
> and include/linux/pci_ids.h with device/vendor
> specific ones?
No, again, please use the "standard" Linux apis for these, don't
duplicate work and make people do more work over the long-term than is
needed.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] drm/i915: fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl
From: Ville Syrjälä @ 2015-03-30 8:00 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-api, intel-gfx, Jesse Barnes, dri-devel, Daniel Vetter
In-Reply-To: <20150330065455.GG23521@phenom.ffwll.local>
On Mon, Mar 30, 2015 at 08:54:55AM +0200, Daniel Vetter wrote:
> On Fri, Mar 27, 2015 at 08:18:28AM -0700, Jesse Barnes wrote:
> > On 03/27/2015 01:04 AM, Daniel Vetter wrote:
> > > On Fri, Mar 27, 2015 at 08:39:56AM +0200, Jani Nikula wrote:
> > >> On Thu, 26 Mar 2015, Tommi Rantala <tt.rantala@gmail.com> wrote:
> > >>> Fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl, so that it
> > >>> is different from the DRM_IOCTL_I915_SET_SPRITE_COLORKEY ioctl.
> > >>>
> > >>> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
> > >>
> > >> Whoa. Broken since its introduction in
> > >>
> > >> commit 8ea30864229e54b01ac0e9fe88c4b733a940ec4e
> > >> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> > >> Date: Tue Jan 3 08:05:39 2012 -0800
> > >>
> > >> drm/i915: add color key support v4
> > >>
> > >> Cc: stable@vger.kernel.org
> > >
> > > Nope, we'll just rip it out and replace it all with the drm_noop ioctl. At
> > > least I didn't find any userspace anywhere and only broken definitions.
> > > Proof enough this isn't useful.
> > >
> > > Even more so since that means we don't have to convert the get ioctl over
> > > to atomic, yay! I'll send patches.
> >
> > Can we just skip the noop part and delete it altogether? It was only
> > added speculatively and obviously never used at all...
>
> The table is indexed, we need a dummy entry.
We shouldn't need any dummies. Any missing entry in the table will
be zeroed, so we should simply return -EINVAL due to ioctl->func==NULL.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 01/86] pci: export pci_ids.h
From: Michael S. Tsirkin @ 2015-03-30 8:31 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Bjorn Helgaas,
Jonathan Corbet, David S. Miller, Hans Verkuil,
Mauro Carvalho Chehab, Alexei Starovoitov, stephen hemminger,
Masahiro Yamada, Andy Shevchenko, Andy Lutomirski,
Rasmus Villemoes, Stephane Eranian, Huang Rui, Peter Neubauer,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150330075331.GA17823-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Mon, Mar 30, 2015 at 09:53:31AM +0200, Greg KH wrote:
> On Mon, Mar 30, 2015 at 09:15:26AM +0200, Michael S. Tsirkin wrote:
> > On Mon, Mar 30, 2015 at 08:55:22AM +0200, Greg KH wrote:
> > > On Mon, Mar 30, 2015 at 08:48:44AM +0200, Michael S. Tsirkin wrote:
> > > > On Sun, Mar 29, 2015 at 10:40:47PM +0200, Greg KH wrote:
> > > > > On Sun, Mar 29, 2015 at 03:37:01PM +0200, Michael S. Tsirkin wrote:
> > > > > > The macros in pci_ids.h are pretty useful for userspace
> > > > > > using the pci sysfs interface.
> > > > > > At the moment userspace is forced to duplicate these macros
> > > > > > (e.g. QEMU does this), it is better to expose them in
> > > > > > /usr/include/linux/pci_ids.h so everyone can just include
> > > > > > this header.
> > > > > >
> > > > > > Signed-off-by: Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > > > > > ---
> > > > > > include/linux/pci_ids.h | 2998 +-----------------------------------------
> > > > > > include/uapi/linux/pci_ids.h | 2997 +++++++++++++++++++++++++++++++++++++++++
> > > > >
> > > > > No, please use the pci ids file from the upstream pci id database
> > > > > instead.
> > > >
> > > >
> > > > > We shouldn't be putting these all in one file,
> > > >
> > > > pci.txt says:
> > > > Please add PCI_VENDOR_ID_xxx for vendors
> > > > You want to change this policy, and get rid of
> > > > vendor ids in pci_ids.h completely?
> > >
> > > Please read the top of pci_ids.h. It hasn't had new ids added to it in
> > > a long time.
> >
> > OK, looks like pci.txt should be fixed then.
>
> Please send a patch. As the original PCI kernel maintainer, I don't
> think I ever noticed pci.txt. It was last "updated" in 2006...
>
> > > Why would userspace need the pci id of anything?
> >
> > Look at how they are used e.g. by QEMU, seabios, gpxe.
> > People want to say e.g. "find all network class devices".
>
> Then use libpci.
>
> > > Again, just use
> > > libpci, isn't it fast enough? Don't duplicate existing logic.
> >
> > This really depends on whether you want something else that
> > libpci provides. But if I just want e.g. standard class IDs,
> > I don't want to depend on libpci.
>
> Why not? Don't duplicate things that already are there just for this
> very use.
>
> Don't make us do kernel changes just because you don't want to depend on
> either of the two different userspace packages that provide this
> information in a standard way for userspace. Your system will have one
> of those two packages in it, depending on it isn't a "burden" at all.
>
> > > Or use the hw database that libudev exports, which is already on your
> > > machine and exports all of the pci ids from libpci directly.
> >
> > Same argument really.
>
> Because you don't want to depend on existing packages, doesn't mean we
> have to accept kernel changes and maintain them for forever, as you are
> now creating a new api that we will have to keep up to date and correct
> for all time.
>
> Again, depend on the packages that are already doing this work please.
>
Maintaining correct class IDs is more or less a requirement
for kernel to work properly, isn't it?
Wouldn't the same thing apply to pci_regs.h?
Why does it make sense to export PCI_CLASS_REVISION
so I know where to read the class value from
configuration, but not what the values are?
> > > > Standard class IDs are even sillier to duplicate.
> > >
> > > Again, why does userspace need this?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Mostly because it has a userspace driver, or is emulating
> > a hardware device.
> >
> > For example, the VFIO driver uses the PCI hardware formats
> > as it's userspace/kernel interface. This means I need
> > a ton of PCI constants in userspace. Most of them are
> > already in pci_regs.h, and so exported. No problem here.
> >
> > However class and prog interface IDs are not, they
> > are in pci_ids.h
> >
> > Would you support splitting pci_ids.h to
> > include/uapi/linux/pci_ids.h with standard headers
> > and include/linux/pci_ids.h with device/vendor
> > specific ones?
>
> No, again, please use the "standard" Linux apis for these, don't
> duplicate work and make people do more work over the long-term than is
> needed.
>
> thanks,
>
> greg k-h
What's the work you refer to? This is just hardware description it
can't change and doesn't need to be maintained.
--
MST
^ permalink raw reply
* Re: [PATCH 01/86] pci: export pci_ids.h
From: Greg KH @ 2015-03-30 10:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Bjorn Helgaas,
Jonathan Corbet, David S. Miller, Hans Verkuil,
Mauro Carvalho Chehab, Alexei Starovoitov, stephen hemminger,
Masahiro Yamada, Andy Shevchenko, Andy Lutomirski,
Rasmus Villemoes, Stephane Eranian, Huang Rui, Peter Neubauer,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150330101830-mutt-send-email-mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Mon, Mar 30, 2015 at 10:31:54AM +0200, Michael S. Tsirkin wrote:
> On Mon, Mar 30, 2015 at 09:53:31AM +0200, Greg KH wrote:
> > On Mon, Mar 30, 2015 at 09:15:26AM +0200, Michael S. Tsirkin wrote:
> > > On Mon, Mar 30, 2015 at 08:55:22AM +0200, Greg KH wrote:
> > > > On Mon, Mar 30, 2015 at 08:48:44AM +0200, Michael S. Tsirkin wrote:
> > > > > On Sun, Mar 29, 2015 at 10:40:47PM +0200, Greg KH wrote:
> > > > > > On Sun, Mar 29, 2015 at 03:37:01PM +0200, Michael S. Tsirkin wrote:
> > > > > > > The macros in pci_ids.h are pretty useful for userspace
> > > > > > > using the pci sysfs interface.
> > > > > > > At the moment userspace is forced to duplicate these macros
> > > > > > > (e.g. QEMU does this), it is better to expose them in
> > > > > > > /usr/include/linux/pci_ids.h so everyone can just include
> > > > > > > this header.
> > > > > > >
> > > > > > > Signed-off-by: Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > > > > > > ---
> > > > > > > include/linux/pci_ids.h | 2998 +-----------------------------------------
> > > > > > > include/uapi/linux/pci_ids.h | 2997 +++++++++++++++++++++++++++++++++++++++++
> > > > > >
> > > > > > No, please use the pci ids file from the upstream pci id database
> > > > > > instead.
> > > > >
> > > > >
> > > > > > We shouldn't be putting these all in one file,
> > > > >
> > > > > pci.txt says:
> > > > > Please add PCI_VENDOR_ID_xxx for vendors
> > > > > You want to change this policy, and get rid of
> > > > > vendor ids in pci_ids.h completely?
> > > >
> > > > Please read the top of pci_ids.h. It hasn't had new ids added to it in
> > > > a long time.
> > >
> > > OK, looks like pci.txt should be fixed then.
> >
> > Please send a patch. As the original PCI kernel maintainer, I don't
> > think I ever noticed pci.txt. It was last "updated" in 2006...
> >
> > > > Why would userspace need the pci id of anything?
> > >
> > > Look at how they are used e.g. by QEMU, seabios, gpxe.
> > > People want to say e.g. "find all network class devices".
> >
> > Then use libpci.
> >
> > > > Again, just use
> > > > libpci, isn't it fast enough? Don't duplicate existing logic.
> > >
> > > This really depends on whether you want something else that
> > > libpci provides. But if I just want e.g. standard class IDs,
> > > I don't want to depend on libpci.
> >
> > Why not? Don't duplicate things that already are there just for this
> > very use.
> >
> > Don't make us do kernel changes just because you don't want to depend on
> > either of the two different userspace packages that provide this
> > information in a standard way for userspace. Your system will have one
> > of those two packages in it, depending on it isn't a "burden" at all.
> >
> > > > Or use the hw database that libudev exports, which is already on your
> > > > machine and exports all of the pci ids from libpci directly.
> > >
> > > Same argument really.
> >
> > Because you don't want to depend on existing packages, doesn't mean we
> > have to accept kernel changes and maintain them for forever, as you are
> > now creating a new api that we will have to keep up to date and correct
> > for all time.
> >
> > Again, depend on the packages that are already doing this work please.
> >
>
> Maintaining correct class IDs is more or less a requirement
> for kernel to work properly, isn't it?
Yes, but maintaining them internally, not externally.
> Wouldn't the same thing apply to pci_regs.h?
> Why does it make sense to export PCI_CLASS_REVISION
> so I know where to read the class value from
> configuration, but not what the values are?
That's just due to history, we made the mistake to export those a long
time ago, I wouldn't recommend doing any more, and again, instead rely
on the programs that properly maintain that for you.
> What's the work you refer to? This is just hardware description it
> can't change and doesn't need to be maintained.
Hardware descriptions always change over time and need to be
maintained...
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 01/86] pci: export pci_ids.h
From: Michael S. Tsirkin @ 2015-03-30 10:46 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, Bjorn Helgaas, Jonathan Corbet, David S. Miller,
Hans Verkuil, Mauro Carvalho Chehab, Alexei Starovoitov,
stephen hemminger, Masahiro Yamada, Andy Shevchenko,
Andy Lutomirski, Rasmus Villemoes, Stephane Eranian, Huang Rui,
Peter Neubauer, linux-pci, linux-doc, linux-api
In-Reply-To: <20150330100744.GA16291@kroah.com>
On Mon, Mar 30, 2015 at 12:07:44PM +0200, Greg KH wrote:
> On Mon, Mar 30, 2015 at 10:31:54AM +0200, Michael S. Tsirkin wrote:
> > On Mon, Mar 30, 2015 at 09:53:31AM +0200, Greg KH wrote:
> > > On Mon, Mar 30, 2015 at 09:15:26AM +0200, Michael S. Tsirkin wrote:
> > > > On Mon, Mar 30, 2015 at 08:55:22AM +0200, Greg KH wrote:
> > > > > On Mon, Mar 30, 2015 at 08:48:44AM +0200, Michael S. Tsirkin wrote:
> > > > > > On Sun, Mar 29, 2015 at 10:40:47PM +0200, Greg KH wrote:
> > > > > > > On Sun, Mar 29, 2015 at 03:37:01PM +0200, Michael S. Tsirkin wrote:
> > > > > > > > The macros in pci_ids.h are pretty useful for userspace
> > > > > > > > using the pci sysfs interface.
> > > > > > > > At the moment userspace is forced to duplicate these macros
> > > > > > > > (e.g. QEMU does this), it is better to expose them in
> > > > > > > > /usr/include/linux/pci_ids.h so everyone can just include
> > > > > > > > this header.
> > > > > > > >
> > > > > > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > > > > > ---
> > > > > > > > include/linux/pci_ids.h | 2998 +-----------------------------------------
> > > > > > > > include/uapi/linux/pci_ids.h | 2997 +++++++++++++++++++++++++++++++++++++++++
> > > > > > >
> > > > > > > No, please use the pci ids file from the upstream pci id database
> > > > > > > instead.
> > > > > >
> > > > > >
> > > > > > > We shouldn't be putting these all in one file,
> > > > > >
> > > > > > pci.txt says:
> > > > > > Please add PCI_VENDOR_ID_xxx for vendors
> > > > > > You want to change this policy, and get rid of
> > > > > > vendor ids in pci_ids.h completely?
> > > > >
> > > > > Please read the top of pci_ids.h. It hasn't had new ids added to it in
> > > > > a long time.
> > > >
> > > > OK, looks like pci.txt should be fixed then.
> > >
> > > Please send a patch. As the original PCI kernel maintainer, I don't
> > > think I ever noticed pci.txt. It was last "updated" in 2006...
> > >
> > > > > Why would userspace need the pci id of anything?
> > > >
> > > > Look at how they are used e.g. by QEMU, seabios, gpxe.
> > > > People want to say e.g. "find all network class devices".
> > >
> > > Then use libpci.
> > >
> > > > > Again, just use
> > > > > libpci, isn't it fast enough? Don't duplicate existing logic.
> > > >
> > > > This really depends on whether you want something else that
> > > > libpci provides. But if I just want e.g. standard class IDs,
> > > > I don't want to depend on libpci.
> > >
> > > Why not? Don't duplicate things that already are there just for this
> > > very use.
> > >
> > > Don't make us do kernel changes just because you don't want to depend on
> > > either of the two different userspace packages that provide this
> > > information in a standard way for userspace. Your system will have one
> > > of those two packages in it, depending on it isn't a "burden" at all.
> > >
> > > > > Or use the hw database that libudev exports, which is already on your
> > > > > machine and exports all of the pci ids from libpci directly.
> > > >
> > > > Same argument really.
> > >
> > > Because you don't want to depend on existing packages, doesn't mean we
> > > have to accept kernel changes and maintain them for forever, as you are
> > > now creating a new api that we will have to keep up to date and correct
> > > for all time.
> > >
> > > Again, depend on the packages that are already doing this work please.
> > >
> >
> > Maintaining correct class IDs is more or less a requirement
> > for kernel to work properly, isn't it?
>
> Yes, but maintaining them internally, not externally.
Sorry about keeping this thread alive, I'm just trying
to wrap my head around what you consider a sane API.
Linux used not to export headers automatically, generally.
It used to be "just use libc". Why is this header different?
These constants are required to use the interfaces
linux does export to userspace, including VFIO and sysfs.
No one maintains them really, though libpci has a copy
of these.
Some people believe headers are copyrighteable, for them, licensing is
also problematic: libpci is under plain GPL, Linux needs the exception
for user programs. Does not this mean that we can't depend on libpci to
provide parts of linux/userspace interface?
> > Wouldn't the same thing apply to pci_regs.h?
> > Why does it make sense to export PCI_CLASS_REVISION
> > so I know where to read the class value from
> > configuration, but not what the values are?
>
> That's just due to history, we made the mistake to export those a long
> time ago, I wouldn't recommend doing any more, and again, instead rely
> on the programs that properly maintain that for you.
So add libpci dependency just for the headers? No one wants to do this.
Case in point, Linux doesn't want to depend on libpci headers either, right?
Why not? why not make it a build dependency? I don't really propose this,
but exactly the same logic applies to gpxe or seabios.
People that don't link with libpci don't want to make it
a build dependency.
> > What's the work you refer to? This is just hardware description it
> > can't change and doesn't need to be maintained.
>
> Hardware descriptions always change over time and need to be
> maintained...
>
> thanks,
>
> greg k-h
I don't think class IDs or vendor IDs ever did or can change.
New stuff is added, we add it as we add Linux support.
Isn't this a good reason to include this? Will push
vendors to work with the community instead of
around it using userspace drivers.
--
MST
^ permalink raw reply
* Re: [PATCH 01/86] pci: export pci_ids.h
From: Greg KH @ 2015-03-30 10:57 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Bjorn Helgaas, Jonathan Corbet, David S. Miller,
Hans Verkuil, Mauro Carvalho Chehab, Alexei Starovoitov,
stephen hemminger, Masahiro Yamada, Andy Shevchenko,
Andy Lutomirski, Rasmus Villemoes, Stephane Eranian, Huang Rui,
Peter Neubauer, linux-pci, linux-doc, linux-api
In-Reply-To: <20150330123051-mutt-send-email-mst@redhat.com>
On Mon, Mar 30, 2015 at 12:46:36PM +0200, Michael S. Tsirkin wrote:
> Sorry about keeping this thread alive, I'm just trying
> to wrap my head around what you consider a sane API.
>
> Linux used not to export headers automatically, generally.
> It used to be "just use libc". Why is this header different?
You are now exporting things from the kernel that were not being
exported in the past. When you do that, you are now guaranteeing that
this api will be present for forever in the future.
> These constants are required to use the interfaces
> linux does export to userspace, including VFIO and sysfs.
> No one maintains them really, though libpci has a copy
> of these.
Also libudev, which takes them from the "master" copy that libpci pulls
from.
> Some people believe headers are copyrighteable, for them, licensing is
> also problematic: libpci is under plain GPL, Linux needs the exception
> for user programs. Does not this mean that we can't depend on libpci to
> provide parts of linux/userspace interface?
This makes no sense at all. If you have legal questions, ask a lawyer,
not a programmer. Would you ask me medical questions as well?
> > > Wouldn't the same thing apply to pci_regs.h?
> > > Why does it make sense to export PCI_CLASS_REVISION
> > > so I know where to read the class value from
> > > configuration, but not what the values are?
> >
> > That's just due to history, we made the mistake to export those a long
> > time ago, I wouldn't recommend doing any more, and again, instead rely
> > on the programs that properly maintain that for you.
>
> So add libpci dependency just for the headers? No one wants to do this.
> Case in point, Linux doesn't want to depend on libpci headers either, right?
The kernel is self-contained, and has to be, don't be foolish.
> I don't think class IDs or vendor IDs ever did or can change.
Then you haven't tracked what has happened over time. They do change,
they are sometimes incorrect, they are extended, and stuff is modified.
> New stuff is added, we add it as we add Linux support.
> Isn't this a good reason to include this? Will push
> vendors to work with the community instead of
> around it using userspace drivers.
This has nothing to do with "pushing vendors" to do anything.
Again, if you have a userspace program that needs these headers, then
use one of the _two_ different packages that userspace already provides
that has them, don't make the kernel become the third provider of the
same header information, that's major duplication of effort for no
reason at all.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 01/86] pci: export pci_ids.h
From: Michael S. Tsirkin @ 2015-03-30 11:19 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Bjorn Helgaas,
Jonathan Corbet, David S. Miller, Hans Verkuil,
Mauro Carvalho Chehab, Alexei Starovoitov, stephen hemminger,
Masahiro Yamada, Andy Shevchenko, Andy Lutomirski,
Rasmus Villemoes, Stephane Eranian, Huang Rui, Peter Neubauer,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150330105707.GA17979-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Mon, Mar 30, 2015 at 12:57:07PM +0200, Greg KH wrote:
> On Mon, Mar 30, 2015 at 12:46:36PM +0200, Michael S. Tsirkin wrote:
> > Sorry about keeping this thread alive, I'm just trying
> > to wrap my head around what you consider a sane API.
> >
> > Linux used not to export headers automatically, generally.
> > It used to be "just use libc". Why is this header different?
>
> You are now exporting things from the kernel that were not being
> exported in the past. When you do that, you are now guaranteeing that
> this api will be present for forever in the future.
We already guarantee this API, that's the point.
Look at this sysfs file:
/sys/bus/pci/devices/0000\:00\:00.0/class
It's a hex number. The values? They are in pci_ids.h
And so everyone who uses this file carries a copy
of the header.
> > These constants are required to use the interfaces
> > linux does export to userspace, including VFIO and sysfs.
> > No one maintains them really, though libpci has a copy
> > of these.
>
> Also libudev, which takes them from the "master" copy that libpci pulls
> from.
OK, so which is the master copy for this:
#define PCI_BASE_CLASS_NETWORK 0x02
> > Some people believe headers are copyrighteable, for them, licensing is
> > also problematic: libpci is under plain GPL, Linux needs the exception
> > for user programs. Does not this mean that we can't depend on libpci to
> > provide parts of linux/userspace interface?
>
> This makes no sense at all. If you have legal questions, ask a lawyer,
> not a programmer. Would you ask me medical questions as well?
>
> > > > Wouldn't the same thing apply to pci_regs.h?
> > > > Why does it make sense to export PCI_CLASS_REVISION
> > > > so I know where to read the class value from
> > > > configuration, but not what the values are?
> > >
> > > That's just due to history, we made the mistake to export those a long
> > > time ago, I wouldn't recommend doing any more, and again, instead rely
> > > on the programs that properly maintain that for you.
> >
> > So add libpci dependency just for the headers? No one wants to do this.
> > Case in point, Linux doesn't want to depend on libpci headers either, right?
>
> The kernel is self-contained, and has to be, don't be foolish.
I agree it is pretty contained but it's not 100%, and it does not have
to be. kernel build depends on perl, bash, make, etc etc.
We don't want a library header dependency because it's easier not to
have dependencies, not because we can't have it.
Same applies to others really.
> > I don't think class IDs or vendor IDs ever did or can change.
>
> Then you haven't tracked what has happened over time. They do change,
> they are sometimes incorrect, they are extended, and stuff is modified.
Sounds like a good reason to avoid duplication, have
provider of the interface document that constants used.
> > New stuff is added, we add it as we add Linux support.
> > Isn't this a good reason to include this? Will push
> > vendors to work with the community instead of
> > around it using userspace drivers.
>
> This has nothing to do with "pushing vendors" to do anything.
>
> Again, if you have a userspace program that needs these headers, then
> use one of the _two_ different packages that userspace already provides
> that has them, don't make the kernel become the third provider of the
> same header information, that's major duplication of effort for no
> reason at all.
>
> thanks,
>
> greg k-h
Why there much more that two packages, I can find
at least 5 copies in the wild. Why? I think it's because it's part of
linux ABI that doesn't have matching headers. People are asked to build
their own, so of course they copy each other.
Once linux exports these headers everyone can stop
duplicating each other and others, and just use linux headers too.
--
MST
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox