From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759154AbZEGVk1 (ORCPT ); Thu, 7 May 2009 17:40:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751378AbZEGVkP (ORCPT ); Thu, 7 May 2009 17:40:15 -0400 Received: from mail-bw0-f222.google.com ([209.85.218.222]:44958 "EHLO mail-bw0-f222.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751298AbZEGVkO convert rfc822-to-8bit (ORCPT ); Thu, 7 May 2009 17:40:14 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Kay Sievers Date: Thu, 7 May 2009 23:39:53 +0200 Message-ID: Subject: Re: usbfs, claiming entire usb devices To: Alan Stern Cc: Kernel development list , Pantelis Koukousoulas , USB list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 7, 2009 at 23:18, Alan Stern wrote: > On Thu, 7 May 2009, Kay Sievers wrote: >> On Thu, May 7, 2009 at 21:55, Alan Stern wrote: >> > There is a proposal afoot to give user programs the ability to claim >> > ownership of an entire USB device, rather than just individual >> > interfaces.  In fact, we'd like processes to be able to own whatever >> > device gets plugged into a particular port on a particular hub. >> > >> > The question is how the API should work.  A simple approach is to have >> > a sysfs or usbfs file correspond to each port; when a process opens the >> > file it would be granted ownership of any device plugged into that >> > port.  Since the file is automatically closed when the process ends, we >> > wouldn't have to worry about ownership never getting released. >> > >> > But there's a snag.  When a process goes to open the usbfs file for a >> > device, the kernel needs to know whether or not the process owns that >> > device.  In other words, we need to figure out whether or not the >> > process has opened the corresponding port file. >> > >> > Is there a simple way to do this?  Is it reasonable to search through >> > all the process's fd's, looking for one that matches a particular >> > inode? >> > >> > Or would a completely different API approach be better? >> >> You have one file per device, and that file has normal unix file >> permissions. Userspace can grant access to that file by ownership or >> by adding an ACL. What else do we need? > > We need the ability to prevent the kernel from automatically > configuring a device.  We need the ability to prevent kernel drivers > from binding to a device before userspace programs get a chance. > >>  Why would the kernel care who >> opened the file, when the one was able to get through the normal file >> access check? > > Access checks can't be used, because programs want to stake their claim > to the device (and its file) even before the device has been plugged > in.  So there's no file and no ACL to set. I see. Can't userspace just unbind a possible driver, which is supported by libusub? Other such use-cases do that, like the UPS userspace drivers, which just unbind the device from a possible in-kernel driver to take it over. Or is that a specific requirement where things would go wrong when the kernel binds to a device first? Kay