lkml.org 
[lkml]   [2009]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] crypto: compress - Add pcomp interface
    	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 word length.
    > > >
    > > > So something like this would be good
    > > >
    > > > int (*setup_comp)(struct crypto_pcomp *tfm, const void *params,
    > > > unsigned int length);
    > > > int (*setup_decomp)(struct crypto_pcomp *tfm, const void *params,
    > > > unsigned int length);
    > >
    > > I assume "length" is the size of the passed params, so the algorithms can
    > > return -EINVAL if they're passed the wrong size?
    > >
    > > > The actual parameters should be formatted using the netlink helpers
    > > > (nla_*). So each parameter that you want to set should show up as
    > > > a netlink attribute. If a paramter is absent then you'd just use
    > > > the default, etc.
    >
    > > I assume "length" is the size of the passed params, so the algorithms can
    > > return -EINVAL if they're passed the wrong size?
    >
    > 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 you have an example?
    Nothing in crypto/ seems to already use nla_*?

    > Ah yes because crypto_comp is one of the original types that's
    > still built-in. Because there are so few compression users and
    > algorithms (exactly 3 if you include null compression), I think
    > we can dispense with the compatibility stuff altogether since
    > we'll likely rip out fairly soon anyway.
    >
    > So just create the new type, readd deflate using the new type
    > alongside the existing deflate algorithm. The system is capable
    > of supporting two algorithms of the same name with different types.

    While the core of the crypto system supports two algorithms of the same name
    with different types, the testmgr doesn't.

    As I removed the backwards-compatility layer at your request, I'll use "zlib"
    for the name of the new module. It's more flexible than the fixed "deflate"
    one anyway.

    Is this OK for you?

    Thanks!

    With kind regards,

    Geert Uytterhoeven
    Software Architect

    Sony Techsoft Centre Europe
    The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

    Phone: +32 (0)2 700 8453
    Fax: +32 (0)2 700 8622
    E-mail: Geert.Uytterhoeven@sonycom.com
    Internet: http://www.sony-europe.com/

    A division of Sony Europe (Belgium) N.V.
    VAT BE 0413.825.160 · RPR Brussels
    Fortis · BIC GEBABEBB · IBAN BE41293037680010
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2009-02-05 17:27    [W:8.981 / U:0.360 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site