Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755321AbZDZNmv (ORCPT ); Sun, 26 Apr 2009 09:42:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750845AbZDZNmm (ORCPT ); Sun, 26 Apr 2009 09:42:42 -0400 Received: from mail-ew0-f176.google.com ([209.85.219.176]:60193 "EHLO mail-ew0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750710AbZDZNml (ORCPT ); Sun, 26 Apr 2009 09:42:41 -0400 MIME-Version: 1.0 In-Reply-To: <20090426085401.3788fc9c@hyperion.delvare> References: <20090329174836.6de797d6@hyperion.delvare> <20090330104952.26f03c13@hyperion.delvare> <20090426085401.3788fc9c@hyperion.delvare> From: Kay Sievers Date: Sun, 26 Apr 2009 15:42:25 +0200 Message-ID: Subject: Re: Class device namespaces To: Jean Delvare Cc: Michael E Brown , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Mauro Carvalho Chehab , Matt Domsch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2679 Lines: 66 On Sun, Apr 26, 2009 at 08:54, Jean Delvare wrote: > But anyway, this isn't going to happen quickly, and I still believe we > should solve the namespace problem I reported. I think the real namespace problem lives well inside the i2c devices, not in the core. :) Sure, the firmware class is pretty dumb with its naming, but the root case is the way i2c devices are created. First, i2c stacks class devices, which it should not do, it should use a bus not a class, if it has device <-> children relations between different types. Second, it names all the devices from different classes with the _same_ name, then puts them in a hierarchy, and the tries to mix-in a third class, the firmware class, which also uses the _same_ name. That just asks for trouble. :) > For firmware, it doesn't seem as legitimate, I can't really think of a > good reason to use the i2c-adapter as the parent for the firmware > device. Oh, I may miss something, I thought that is what you already do and causes the problem? I though you use the "adapter" to request the firmware? Otherwise I don't see how this can conflict. You have the "adapter" and the "device" stacked, right? /sys/devices/pci0000:00/0000:00:1f.3/i2c-adapter/i2c-0/i2c-0/ Then you use the adapter: /sys/devices/pci0000:00/0000:00:1f.3/i2c-adapter/i2c-0 to request the firmware, which will try to create: /sys/devices/pci0000:00/0000:00:1f.3/i2c-adapter/i2c-0/i2c-0/ I thought you could use the "device" and not the "adapter" to request the firmware? Then you would get a "nice" chain of devices with all the same names, like :) /sys/devices/pci0000:00/0000:00:1f.3/i2c-adapter/i2c-0/i2c-0/i2c-0/ I see the following options: - the i2c "device", not the "adapter" would request the firmware - the i2c-adapter converts to a bus, and is no longer a class - i2c "adapters" and "devices" don't get the same duplicated name - if "adapters" can only ever have a single "device", the both could just be merged to a single instance, and maybe compat symlinks created - the firmware class adds a firmware-% prefix in the case the requesting device is a class device, and not the common case which is a bus device - change the "glue dir" rules, which I would try to avoid, because we don't know who else might stack class devices of different classes, and might get surprised by this What do you think? Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/