Re: [PATCH] error-injection: Add prompt for function error injection

[Jiri Kosina]

On Thu, 1 Dec 2022, Linus Torvalds wrote:

> > Anyway, I believe [1] that ERROR_INJECTION has been designed as a
> > debugging feature in the first place, and should stay so. After figuring
> > out now that HID-BPF actually has hard dependence on it, I fully agree [2]
> > that the series should be ditched for 6.2 and will work with Benjamin to
> > have it removed from current hid.git#for-next.
> 
> I do think that it is interesting to have a "let's have a bpf
> insertion hook here", so I'm not against the _concept_ of HID doing
> that.

Absolutely, me neither, quite the contrary -- I am quite happy to see 
HID-BPF happening, because it'll actually make life easier for everybody: 
for people with quirky hardware (trivial testing of fixes), for kernel 
developers (trivial testing of fixes), and for distributions (trivial 
distribution of fixes).

> It's not so different from user-mode drivers, after all, which we also 
> have. A kind of half-way state where we have a kernel driver, but one 
> that may need custom site-specific (or machine-specific) tweaks.

Indeed. The whole rationale from Benjamin, explaining quite nicely why 
HID-BPF is a good thing, can be found in the very original, initial 
ancient cover letter:

	https://lore.kernel.org/lkml/20220224110828.2168231-1-benjamin.tissoires@xxxxxxxxxx/

> So I don't want to come across as being against having bpf used for 
> tuning some HID issue (and I can imagine it making sense in other places 
> that have machine-specific tweaks - I'm thinking of all the thermal 
> probe or pincontrol mess where sometimes you have GPIO's or motherboard 
> thermal sensors etc that are literally "user connected it to X").
> 
> But the notion that we'd use some error injection framework for it,
> and that you'd mix those concepts up - *that* I really think is just
> horrendous.

Fully agreed. I unfortunately missed that particular aspect during review, 
and it popped up only after HID-BPF appeared in linux-next.

-- 
Jiri Kosina
SUSE Labs