[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1367463574.27102.207.camel@schen9-DESK>
Date: Wed, 01 May 2013 19:59:34 -0700
From: Tim Chen <tim.c.chen@...ux.intel.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: "H. Peter Anvin" <hpa@...or.com>,
"David S. Miller" <davem@...emloft.net>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
James Bottomley <James.Bottomley@...senPartnership.com>,
Matthew Wilcox <willy@...ux.intel.com>,
Jim Kukunas <james.t.kukunas@...ux.intel.com>,
Keith Busch <keith.busch@...el.com>,
Erdinc Ozturk <erdinc.ozturk@...el.com>,
Vinodh Gopal <vinodh.gopal@...el.com>,
James Guilford <james.guilford@...el.com>,
Wajdi Feghali <wajdi.k.feghali@...el.com>,
Jussi Kivilinna <jussi.kivilinna@....fi>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-crypto@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [PATCH v2 1/4] Wrap crc_t10dif function all to use crypto
transform framework
On Tue, 2013-04-30 at 11:27 +0800, Herbert Xu wrote:
> On Mon, Apr 29, 2013 at 01:40:30PM -0700, Tim Chen wrote:
> >
> > If I allocate the transform under the mod init instead, how can I make
> > sure that the fast version is already registered if I have it compiled
> > in? It is not clear to me how that's done looking at the libcrc32c
> > code.
>
> This is only an issue when everything is built-in to the kernel.
>
> In that case we could make the crc implementations register at a
> point earlier than device_initcall, but no earlier than subsys_initcall
> since that's where cryptomgr sits.
I've spun version 3 of this patch series to address the concerns about
version 2. The patches are sent separately.
Thanks.
Tim
--
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