From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763161AbZEGUfk (ORCPT ); Thu, 7 May 2009 16:35:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754258AbZEGUf3 (ORCPT ); Thu, 7 May 2009 16:35:29 -0400 Received: from mail-fx0-f158.google.com ([209.85.220.158]:45917 "EHLO mail-fx0-f158.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752875AbZEGUf2 convert rfc822-to-8bit (ORCPT ); Thu, 7 May 2009 16:35:28 -0400 MIME-Version: 1.0 In-Reply-To: References: <1295ed070905071015n5a604f93je366faf55b695e47@mail.gmail.com> From: Kay Sievers Date: Thu, 7 May 2009 22:35:07 +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 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? Why would the kernel care who opened the file, when the one was able to get through the normal file access check? Or did you mean some magic for an entire tree of devices below some port? Like some sort of permission inheritance in the kernel? Kay