linux-kernel - Re: [PATCH 3/3] PNP cleanups - Version 2 - Pass struct pnp_dev to pnp_clean_resource

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] [day] [month] [year] [list]

Message-Id: <1195686357.3760.28.camel@queen.suse.de>
Date:	Thu, 22 Nov 2007 00:05:57 +0100
From:	Thomas Renninger <trenn@...e.de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Rene Herman <rene.herman@...access.nl>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	akpm <akpm@...ux-foundation.org>,
	Bjorn Helgaas <bjorn.helgaas@...com>,
	"Li, Shaohua" <shaohua.li@...el.com>,
	"yakui.zhao" <yakui.zhao@...el.com>
Subject: Re: [PATCH 3/3] PNP cleanups - Version 2 - Pass struct pnp_dev to
	pnp_clean_resource_table for cleanup reasons

On Wed, 2007-11-21 at 18:13 +0000, Alan Cox wrote:
> > > in the pnp_dev. That is, the resources are tied to the device, with struct 
> > > pnp_resource_table being no more than a handy container to group them under 
> > > a single name.
> > Putting the count into struct resource does not make sense.
> 
> Can you explain that claim ?
The additional variable would only make sense for the pnp layer, or only
for the pnp resource table in the pnp layer, but struct resource is used
at much more places...
It is meant for System Memory and IO port resources in general, why
waste bytes and an additional name at all places it is used, just for
the pnp resource table?

> > The idea is to not rely on the exact pnp resource table structure and
> > abstracting this to macros. If krealloc approach works,
> > dev->res.port_resource[i].start would even still work, if not, it's
> > easier to alter the pnp resource table and the macros internally.
> 
> Externally in drivers yes. Internally in code no - it makes the code
> harder to work with.
> 
> > > Yes, I dont know how he intends to deal with this (nor, in fact, just how 
> > > dynamic things are supposed to end up to begin with) so over to Thomas.
> > Krealloc should only get used at early pnp init time, when the BIOS
> > structures are parsed. The devices shouldn't be active then...
> > A bit of a problem, as said, could be the sysfs interfaces, there it
> > must be insured krealloc is not used anymore.
> 
> I don't think its that simple but that can be dealt with one the changes
> are in place if the objects are sensibly laid out.

I hope it is, stay tuned there will come something soon...
If it's not that easy, another structure would be needed and every
dev->res.port_resource[i].start and friends need to be touched (I don't
see how this could still be resolved in a simple array then...).

    Thomas

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