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]
Message-ID: <20070908105534.2e8e7d8a@hyperion.delvare>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ