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

From: Andreas Happe
Date: Tue Sep 28 2004 - 07:37:47 EST


Michal Ludvig <michal@xxxxxxxx> [040927 11:32]:
BTW In http://lists.logix.cz/pipermail/cryptoapi/2004/000088.html I
described a concept of "preferences" that was done for the current
cryptoapi. How to do something similar with your patch applied?

The class - objects are used just for display use.. your patch should
apply (sans offsets) without problems.. I don't think that the two
different algorithms would be displayed in sysfs as i use the cra_name
as directory name (which should be aes for aes and aes-i586).

If I'd finally have two or more modules for the same algorithm loaded, how
should the /sys subtree look like?

good one.

If there are lots of different implementation for a given algorithm it
could be worthwhile to create a algorithm and a implementation -
directory e.g.

ls /sysfs/class/crypto/implementations would list:
aes-i586 aes-c4 md5 sha1 sha256-c4

and: ls /sysfs/class/crypto/algorithms
aes

with ls /sysfs/class/crypto/algorithms/aes
name type implementations

where implementations is a directory with links to the given
implementations in /sysfs/class/crypto/implementations.

Seems like a lot of work if there are only few implementations (like aes
and aes-i586).

the same could be done without the implementations - directory. If a new
algorithm tries to register itself with a already registered name (and
the module name isn't known) it is added to the
/sysfs/class/crypto/<cra-name>/implementations - directory as
<module-name>. All Algorithm - specific data would be displayed in the
<cra-name> directory, the rest in the implementations/<module-name> -
directory.

I'm moving to vienna the day after tomorrow so don't expect too fast
response times from me.

--Andreas
-
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/