From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Mon, 03 Jun 2002 22:46:32 +0000 Subject: Re: Which node has the device been bound to? Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Tue, Jun 04, 2002 at 12:43:38AM +0200, Oliver Neukum wrote: > Am Montag, 3. Juni 2002 23:58 schrieb Greg KH: > > On Mon, Jun 03, 2002 at 11:09:36PM +0200, Oliver Neukum wrote: > > > > But what is the real problem here? What do you want to solve? > > > > Mapping of a /dev node to a physical device? Or mapping of a > > > > physical device to a /dev node? Or something else? > > > > > > The former. The latter has some principal problems. > > > To do the former you need to have an atomic operation on an > > > opened device. > > > Thus you need to have the device node open and you need > > > the ioctl to not return a pointer to a driverfs file. You either > > > return its content or an fd. > > > > Ok, I understand a bit better now (sorry, I'm slow today...). So what > > fd do you want returned in the ioctl()? driverfs implements a tree for > > every device, not a single file. Do you want a fd for the directory? > > No problem, I am dense at times, too. > There's a problem. You cannot open() based on a directory fd, > unless I am mistaken. I think you are correct, that's why I asked. > I can't come up with anything better than a set of ioctls that return > the contents of the individual files. And I know that this is ugly. > I don't claim that this is a good solution, just that it's the only > solution I have and that there's a race otherwise. > You simply cannot use names, thus parsing files for the name of the > node won't work. Or we could just drop the whole idea of using ioctl() and live with the "instability" of parsing a filesystem :) > I've thought about finding the device node to a physical device. > It really is problematic. Firstly there can be several nodes. > Secondly you'd need device nodes in driverfs, in effect merging it > with devfs. I saw a patch to driverfs that did this a while ago, but see Linus's comments on lkml about why this will probably never happen. thanks greg k-h _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel