linux-kernel - Re: Class device namespaces

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:	Sun, 26 Apr 2009 15:42:25 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	Michael E Brown <Michael_E_Brown@...l.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-kernel@...r.kernel.org,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	Matt Domsch <Matt_Domsch@...l.com>
Subject: Re: Class device namespaces

On Sun, Apr 26, 2009 at 08:54, Jean Delvare <khali@...ux-fr.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/