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] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 23 Jan 2016 08:39:34 -0800
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Michal Malý <madcatxster@...oid-pointer.net>
Cc:	Bjørn Mork <bjorn@...k.no>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	dmitry.torokhov@...il.com, jikos@...nel.org, elias.vds@...il.com,
	edwin@...ds.nl, simon@...gewell.org
Subject: Re: [PATCH 0/2] Add a skeleton module to perform a basic
 initialization on certain USB devices

On Sat, Jan 23, 2016 at 04:56:27PM +0100, Michal Malý wrote:
> On sobota 23. ledna 2016 13:46:32 CET Bjørn Mork wrote:
> > Michal Malý <madcatxster@...oid-pointer.net> writes:
> > > This mini series adds a simple skeleton module whose only purpose is to
> > > bring devices that at first appear as a generic USB device into another
> > > mode that can be handled by a more specific subsystem.
> > > 
> > > This patch was originally requested by Dmitry, reasoning that loading the
> > > entire xpad module just to switch a Logitech G920 wheel into HID mode is
> > > excessive and does not make much sense.
> > > 
> > > The module can be extended to handle any other USB device that might
> > > require such a switch.
> > 
> > Can this switching be done in userspace? That's what we normally do, ref
> > usb_modeswitch.
> 
> I briefly considered leaving the switch up to the userspace and handling the 
> device in the kernel only once it's been switched. I am however uncertain how 
> to advertise this to the users. Writing a tiny app that would currently handle 
> just one device seems like an overkill,

Writing a kernel driver that can be done in userspace is also overkill :)

> abusing usb_modeswitch seems counter-
> intuitive as it's purpose is to handle various USB modems. Having a tiny 
> module in the kernel looks like the most straightforward thing to do as far as 
> user experience is concerned.
> 
> I would not object to deferring the switch to userspace as long as there is an 
> easy way how to communicate the need for a small switching tool to the users.

Have your program install a udev rule to make it run automatically when
the device is plugged in, and then just file a bug with the different
distros to have them pick up your program and add it to their releases.
With free services like Github to host the code, and OBS to build
packages for every different distro out there, there has never been an
easier time to get programs to distros.

So please just do this in userspace, we don't like to take kernel
drivers for functions that can be done in userspace.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ