On Wed, 25 Feb 2009, Herbert Xu wrote:
> On Mon, Feb 23, 2009 at 06:32:19PM +0100, Geert Uytterhoeven wrote:
> >
> > Is the below (on top of my last patch series) what you have in mind?
>
> Looks great to me!
OK.
> > Notes:
> > - I had to drop the `const' from the `params' pointers of
> >
On Mon, Feb 23, 2009 at 06:32:19PM +0100, Geert Uytterhoeven wrote:
>
> Is the below (on top of my last patch series) what you have in mind?
Looks great to me!
> Notes:
> - I had to drop the `const' from the `params' pointers of
> pcomp_alg.{,de}compress_setup().
> Trying to make nla_pa
Hi Herbert,
On Thu, 19 Feb 2009, Herbert Xu wrote:
> On Thu, Feb 19, 2009 at 10:12:18AM +0100, Geert Uytterhoeven wrote:
> > IIUC, my setup() routines should decode the parameters using nla_parse()?
>
> Right.
>
> > And the caller of a setup() routine should encode the data. But how? All
On Thu, Feb 19, 2009 at 10:12:18AM +0100, Geert Uytterhoeven wrote:
>
> IIUC, my setup() routines should decode the parameters using nla_parse()?
Right.
> And the caller of a setup() routine should encode the data. But how? All the
> nla_put*() routines seem to be targeted at skb's.
The callers
On Thu, 19 Feb 2009, Herbert Xu wrote:
> On Thu, Feb 12, 2009 at 04:19:40PM +0100, Geert Uytterhoeven wrote:
> > On Tue, 10 Feb 2009, Herbert Xu wrote:
> > > On Thu, Feb 05, 2009 at 05:24:51PM +0100, Geert Uytterhoeven wrote:
> > > > > Well with the netlink parameters these can have variable length
On Thu, Feb 12, 2009 at 04:19:40PM +0100, Geert Uytterhoeven wrote:
> On Tue, 10 Feb 2009, Herbert Xu wrote:
> > On Thu, Feb 05, 2009 at 05:24:51PM +0100, Geert Uytterhoeven wrote:
> > > > Well with the netlink parameters these can have variable lengths
> > > > depending on how many parameters the
On Tue, 10 Feb 2009, Herbert Xu wrote:
> On Thu, Feb 05, 2009 at 05:24:51PM +0100, Geert Uytterhoeven wrote:
> > > Well with the netlink parameters these can have variable lengths
> > > depending on how many parameters the user supplies.
> >
> > How can this be exported to userspace?
> > How does
On Thu, Feb 05, 2009 at 05:24:51PM +0100, Geert Uytterhoeven wrote:
>
> > Well with the netlink parameters these can have variable lengths
> > depending on how many parameters the user supplies.
>
> How can this be exported to userspace?
> How does this variable length parameter passing work? Do y
Hi Herbert,
On Thu, 15 Jan 2009, Herbert Xu wrote:
> On Wed, Jan 14, 2009 at 04:01:34PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 14 Jan 2009, Herbert Xu wrote:
> > > Also, this is something that we'll potentially export to user-space,
> > > so we need to ensure that it is invariant to
On Thu, Jan 15, 2009 at 11:54:53AM +0100, Geert Uytterhoeven wrote:
>
> But there are pr_debug()s ;-)
Well they must've turned invisible in the copy I received :)
> By "both alloc function", do you mean the .setup_comp() and .setup_decomp()
> functions? If yes, then I understand.
Yes.
> (Yester
Hi Herbert,
On Thu, 15 Jan 2009, Herbert Xu wrote:
> On Wed, Jan 14, 2009 at 04:01:34PM +0100, Geert Uytterhoeven wrote:
> > It's used by the pr_*() macros in .
> >
> > Since commit d091c2f58ba32029495a933b721e8e02fbd12caa ("Add 'pr_fmt()'
> > format
> > modifier to pr_xyz macros."), thi
On Wed, Jan 14, 2009 at 04:01:34PM +0100, Geert Uytterhoeven wrote:
>
> It's used by the pr_*() macros in .
>
> Since commit d091c2f58ba32029495a933b721e8e02fbd12caa ("Add 'pr_fmt()' format
> modifier to pr_xyz macros."), this is the new way to have a common prefix in
> all printed output.
But yo
On Wed, Jan 14, 2009 at 10:24 PM, Geert Uytterhoeven
wrote:
> On Wed, 14 Jan 2009, Jaswinder Singh Rajput wrote:
>> On Tue, Jan 13, 2009 at 9:29 PM, Geert Uytterhoeven
>> wrote:
>> > +static inline struct pcomp_alg *crypto_pcomp_alg(struct crypto_pcomp *tfm)
>> > +{
>> > + return __crypto_p
On Wed, 14 Jan 2009, Jaswinder Singh Rajput wrote:
> On Tue, Jan 13, 2009 at 9:29 PM, Geert Uytterhoeven
> wrote:
> > +static inline struct pcomp_alg *crypto_pcomp_alg(struct crypto_pcomp *tfm)
> > +{
> > + return __crypto_pcomp_alg(crypto_pcomp_tfm(tfm)->__crt_alg);
> > +}
> > +
> > +static
On Tue, Jan 13, 2009 at 9:29 PM, Geert Uytterhoeven
wrote:
> +static inline struct pcomp_alg *crypto_pcomp_alg(struct crypto_pcomp *tfm)
> +{
> + return __crypto_pcomp_alg(crypto_pcomp_tfm(tfm)->__crt_alg);
> +}
> +
> +static inline int crypto_pcomp_setup(struct crypto_pcomp *tfm,
> +
Hi Herbert,
On Wed, 14 Jan 2009, Herbert Xu wrote:
> On Tue, Jan 13, 2009 at 04:59:40PM +0100, Geert Uytterhoeven wrote:
> > The current "comp" crypto interface supports one-shot (de)compression only,
> > i.e. the whole data buffer to be (de)compressed must be passed at once, and
> > the w
Hi Geert:
On Tue, Jan 13, 2009 at 04:59:40PM +0100, Geert Uytterhoeven wrote:
> The current "comp" crypto interface supports one-shot (de)compression only,
> i.e. the whole data buffer to be (de)compressed must be passed at once, and
> the whole (de)compressed data buffer will be received at once.
The current "comp" crypto interface supports one-shot (de)compression only,
i.e. the whole data buffer to be (de)compressed must be passed at once, and
the whole (de)compressed data buffer will be received at once.
In several use-cases (e.g. compressed file systems that store files in big
compresse
18 matches
Mail list logo
