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: <20120916002957.GB7028@quad.lixom.net>
Date:	Sat, 15 Sep 2012 17:29:57 -0700
From:	Olof Johansson <olof@...om.net>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Will Deacon <Will.Deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v2 07/31] arm64: Process management

On Fri, Sep 14, 2012 at 06:33:52PM +0100, Catalin Marinas wrote:
> On Wed, Aug 15, 2012 at 12:50:13AM +0100, Olof Johansson wrote:
> > On Tue, Aug 14, 2012 at 06:52:08PM +0100, Catalin Marinas wrote:
> > 
> > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > > new file mode 100644
> > > index 0000000..c4a4e1c
> > > --- /dev/null
> > > +++ b/arch/arm64/kernel/process.c
> > > @@ -0,0 +1,416 @@
> > 
> > [...]
> > > +/*
> > > + * Function pointers to optional machine specific functions
> > > + */
> > > +void (*pm_power_off)(void);
> > > +EXPORT_SYMBOL(pm_power_off);
> > > +
> > > +void (*pm_restart)(const char *cmd);
> > > +EXPORT_SYMBOL_GPL(pm_restart);
> > [...]
> > > +void (*pm_idle)(void) = default_idle;
> > > +EXPORT_SYMBOL(pm_idle);
> > 
> > Does it really make sense to export these to modules?
> 
> Changed them to _GPL now but we may still want them exported to modules.
> Who knows, we may just have the SoC code in a loadable module (from
> initramfs).

Ok, keeping the option open for that makes some sense.

> > I find the powerpc way of having a machine descriptor structure with these
> > (and other) function pointers in it a bit cleaner, since it gives you
> > one place to plug it all in. I'd recommend that you consider doing that
> > here as well, for these three and potentially other cases in the future.
> > 
> > (See arch/powerpc/include/asm/machdep.h, struct machdep_calls).
> 
> At some point we may add them but currently I want the SoC code to be
> minimal.

It's not about the size of the code, it's about having one place where
the SoC divergence is exposed instead of adding hooks here and there. But
agreed, it could be moved to over time.


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