Re: [cryptoapi/sysfs] display cipher details in sysfs

[Michal Ludvig]

On Wed, 29 Sep 2004, Andreas Happe wrote:

> just took a glance at preferences for algorithms yesterday. came up with
> the attached code (does compile, don't think that it will boot, just
> attached to illustrade my thinkings).

I'll give it a try and read something more about kobjects and ksets as
well ;-)

> I inserted a cra_family list into cra_alg which stores all algorithms
> which share the same name but different module names. When selecting an
> algorithm the preference is looked after (it should be made a writeable
> sysfs attribute - would make runtime user selection of prefered
> algorithm very intuitive).

For now it could be a module option or even hardcoded in the .ko. It won't
be user-writable anyway, only root-writable. And if root wouldn't want to
use the most preferred module, he could simply not load it...

The reason why I wanted the cra_preference is a situation where a given
functionality is non-modular and compiled into the kernel and requires an
algorithm thet in turn will have to be compiled in as well. Distributors
would of course select the pure software implementation for this. But then
you install a cryptocard - without preferences you couldn't load a module
with driver for it.

> Main problems are removal of algorithms (havn't covered that yet) and
> the display of different algorithms with same names in sysfs as cra_name
> is the name of the directory (not module_name(alg->cra_module)).
>
> Creating a hierarchie cra_alg <>- cra_implementation would be the most
> clean solution. Just add a kset with the different cra_implementations
> (which would contain a kobject, preference, module pointer) to any
> given algorithm (which would contain all blocksize, blah data).

Michal Ludvig
-- 
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/