linux-kernel - Re: [patch 0/2] add actuators support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20170717164836.GB1920@nanopsycho.orion>
Date:   Mon, 17 Jul 2017 18:48:36 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, davem@...emloft.net,
        mchehab@...nel.org, jikos@...nel.org
Subject: Re: [patch 0/2] add actuators support

Mon, Jul 17, 2017 at 06:40:06PM CEST, gregkh@...uxfoundation.org wrote:
>On Mon, Jul 17, 2017 at 06:34:58PM +0200, Jiri Pirko wrote:
>> Mon, Jul 17, 2017 at 06:28:38PM CEST, gregkh@...uxfoundation.org wrote:
>> >On Mon, Jul 17, 2017 at 06:19:12PM +0200, Jiri Pirko wrote:
>> >> From: Jiri Pirko <jiri@...lanox.com>
>> >> 
>> >> I am owner of height adjustable desk and naturally, as it has an USB
>> >> interface, I need to controll it from my computer. Started to think
>> >> about what would be the best way, I realized that I need to introduce
>> >> a new driver class in kernel. The reason is a need to have one API
>> >> for all possible kinds of actuator devices (USB, I2C, gpio, etc).
>> >
>> >Why does this have to be a kernel driver at all?  Your USB driver should
>> >really just be a simple userspace application (use libusb to have it
>> >work on all operating systems.)
>> 
>> Yeah, I was thinking about it as well. To have some kind of single
>> purpose app like sispmctl (control of surge protector). But that would
>> limit you only for this specific device. And for multiple devices you
>> would have to have multiple apps.
>> 
>> So it seems to me like a suitable solution to have this as a driver
>> class.
>
>For USB devices, especially ones as simple as this, we don't want them
>to have kernel drivers.  It's just overkill.
>
>And never create a class if you only have one type of device, otherwise
>you don't know if you really have it properly defined or not.  3 is a
>good number to start with.

You are making it hard for me :) Have to find other 2 then. And I thought
that this spare time quest is coming to an end... 


>
>sorry,
>
>greg k-h