linux-kernel - Re: Platform device id

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:	Sat, 8 Sep 2007 10:55:34 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	David Brownell <david-b@...bell.net>, linux-kernel@...r.kernel.org,
	gregkh@...e.de, dmitry.torokhov@...il.com
Subject: Re: Platform device id

On Sat, 8 Sep 2007 00:50:22 -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 07 Sep 2007, David Brownell wrote:
> > > I don't feel like drivers like hdaps, thinkpad-acpi, dock, bay,
> > > and many others really belong in the platform bus.  But that's
> > > what happens right now.
> > 
> > As a rule, there needs to be a Good Reason to create a new bus
> > type.  A "feel" is a pretty weak reason...
> 
> The "feel" is there because:
> 
> 1. Comments about how what we do is wrong for the platform bus (i.e.  adding
>    the devices and the driver in the same module). Even the documentation
>    for platform devices make it quite clear we are abusing it.  There was
>    one of those comments in this very thread.

This more general than just the platform bus. It's how the Linux 2.6
device driver model is designed.

There are alternatives to the way hdaps and thinkpad_acpi instantiate
their devices:

* These drivers use DMI to find out whether they run on supported
hardware. The same detection code could be moved to a separate driver
(possibly the same one for all DMI-detected devices) and that separate
driver would instantiate the devices as needed. Then the usual
hotplug/coldplug rules apply.

* Detection could be moved to user-space entirely, then we would only
need a way to instantiate these specific devices from user-space. This
exists in other areas (scsi, network) for quite some times already so
it shouldn't be too difficult.

> 2. The fact that a module that has a number of different devices has to
>    register itself a number of times as a driver, if it wants to name the
>    devices something different...

Sounds like you have a design issue here to start with. Supporting
several significantly different devices in the same module is not
something that we do usually.

-- 
Jean Delvare
-
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/