linux-kernel - Re: [PATCH] move omap_udc's probe function to .devinit.text

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200907120230.38293.david-b@pacbell.net>
Date:	Sun, 12 Jul 2009 02:30:37 -0700
From:	David Brownell <david-b@...bell.net>
To:	Russell King <rmk+lkml@....linux.org.uk>,
	"Uwe Kleine-König" 
	<u.kleine-koenig@...gutronix.de>
Cc:	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	Philipp Zabel <philipp.zabel@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tony Lindgren <tony@...mide.com>,
	Dmitry Baryshkov <dbaryshkov@...il.com>
Subject: Re: [PATCH] move omap_udc's probe function to .devinit.text

On Sunday 12 July 2009, Russell King wrote:
> Your approach is perfectly fine, and safe.  You're not adding any
> additional bloat which isn't already there.

He is most certainly increasing the runtime footprint needessly.
Runtime footprint which previously was *NOT* present.

That's known as "bloat".

And also known as "adding".

> If it were adding any 
> bloat (which it isn't), it certainly is not "in chunks of up to a
> page per patch".

Oddly, the init section of the $SUBJECT driver is about 3600 bytes.
That's what ... almost a (4K) page, wouldn't you say?

It's got a lot of one-time hardware init that was explicitly pushed
into the init section so it would stay out of the runtime image.

> Overall, this patch is an improvement, so all these get my ack, and
> they should be applied as is.

The $SUBJECT patch is most certainly NOT an improvement.

It still has a solid NAK, since it's adding almost a page of bloat.

> Using platform_driver_probe() does allow you to reduce the kernel
> footprint still further, but that requires knowledge of the platforms
> affected (knowing that the platform devices are present before the
> drivers get probed.)

And as I've pointed out before ... that's exactly how platform
drivers work on most platforms.  Very specifically, I've pointed
out previously to Uwe, it's how the OMAP code works.

So it's kind of perplexing to still see patches sent along which
make the situation worse.

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