linux-kernel - Re: [patch 2.6.19-rc6] fix hotplug for legacy platform drivers

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:	Tue, 5 Dec 2006 22:08:02 -0800
From:	Greg KH <gregkh@...e.de>
To:	David Brownell <david-b@...bell.net>
Cc:	Marco d'Itri <md@...ux.IT>, Kay Sievers <kay.sievers@...y.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 2.6.19-rc6] fix hotplug for legacy platform drivers

On Tue, Dec 05, 2006 at 04:03:08PM -0800, David Brownell wrote:
> On Tuesday 05 December 2006 2:01 am, Marco d'Itri wrote:
> > On Dec 05, David Brownell <david-b@...bell.net> wrote:
> > 
> > > The pushback on $SUBJECT patch.  Which amounts to wanting to break hotplug
> > > for several busses, unless someone (NOT the folk promoting the breakage!)
> >
> > Please explain in more details how hotplugging would be broken, possibly
> > with examples.
> 
> First, for reference, I refer to hotplugging using the trivial ASH scripts
> from [1], updated by removing no-longer-needed special cases for platform_bus
> (that original logic didn't work sometimes) and pcmcia.  See the (short)
> contemporary thread [2] discussing platform_bus support, and some of issues
> related to why its hotplug support works the way it does now.  (Looks like
> some messages are not archived, but the key points are there.)
> 
> Those scripts have supported hotplug and coldplug on several embedded boards
> for some time now.  The ancient "runs on 2.4" scripts would have been way
> too slow to justify using hotplug and udev to replace devfs, and also needed
> all sorts of extra crap that's regularly not found with embedded Linuxes.
> Plus of course they never understood platform_bus, which is the main way
> those PCI-less systems are hooked together.

Ah, so for the platform devices, doing a
	modprobe /sys/devices/platform/*
would load all of the proper modules for the specific platform devices
that are already present due to the MODULE_ALIAS() stuff?

Interesting, I didn't know that.

> Second, note that you're asking me to construct a straw man for you and
> then break it down, since nobody arguing with the $SUBJECT patch has ever
> provided a complete counter-proposal (much less respond to the points
> I've made about legacy driver bugginess -- which is suggestive).

Well, no, I just thought the patch in $SUBJECT was very ugly, and hence,
didn't like it :)

> That said, the common thread in that pushback is that $MODALIAS (and also
> modalias files) "should" have some value other than platform_device.name ...
> which name is conventionaly also the name of the driver's module.  That goes
> along with a (weak) rationale that requires spi_bus and KMOD to change, plus
> (presumably, pending a code audit) other kernel subsystems.
> 
> 
> That should make it clear how accepting that pushback would break hotplug:
> "modprobe $MODALIAS" would no longer load the right module.  Likewise
> the more significant case of coldplug; "modprobe $(cat modalias)" would
> likewise no longer work.

But, I don't understand why a module would have an alias with the same
name as itself?  What is that achieving here?  Shouldn't redundancy like
that be eliminated?

> The $SUBJECT patch makes those legacy drivers NOT use the $MODALIAS
> mechanism ... you seem to be overlooking that.

No, I'm not overlooking that, I think it's a good thing.  I'm just
wondering if it could be done a different way.  Perhaps in the platform
device itself instead of the driver core code?

> And "udev" was from day one supposed to solve  a different problem
> than "loading modules".  There was to be a clear and strong separation
> of roles between hotplug (load modules, don't rely on sysfs, use other
> components for the rest of device setup) and udev (make /dev nodes,
> ok to rely on sysfs).  That is, "udev" wouldn't do any loading.

Well, things evolve and change over time.  In the beginning, Linux was
only supposed to run on one CPU type and merely display ABABABAB on a
console properly :)

thanks,

greg k-h
-
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/