Messages in this thread | | | Date | Sun, 5 Sep 2004 17:04:46 -0700 | From | Greg KH <> | Subject | Re: [cryptoapi/sysfs] display cipher details in sysfs |
| |
On Wed, Sep 01, 2004 at 10:28:19AM +0200, Andreas Happe wrote: > Hi, > > following-up to: James Morris <jmorris@redhat.com> [040901 09:35]: > >This looks potentially useful, although I'm not sure yet whether the > >userland crypto API should be exposed via sysfs or a separate filesystem. > > > >I suggest you post the patch to linux-kernel and the crypto API list at: > >http://lists.logix.cz/pipermail/cryptoapi as an RFC, for wider feedback. > > the attached patch creates a /sys/cryptoapi/<cipher-name>/ hierarchie > which includes all information which is currently offered by > /proc/crypto. This was done by embedding a kobject in struct crypto_alg > (include/linux/crypto.h) and using a kset/subsystem instead of the > currently used list (crypto_alg->cra_list was removed, as it shouldn't > be needed anymore). crypto/proc.c was converted to use the subsystem > internal rwlock/list for its iteration of ciphers. > > I think that the place for the cryptoapi-tree in sysfs is wrong (but the > others (block, module, bus, class, etc.) seemed worse). But the effort > to change this should be neglectable (and centered at syfs.c).
Why not use a class instead of a raw kobject? Wouldn't a struct class_device make things easier for you? That would also put the stuff into /sys/class/cryptoapi which I think makes a bit more sense than /sys/cryptoapi.
Or how about just /sys/class/crypto ?
Other than that, I like this move, /proc/crypto isn't the best thing to have in a proc filesystem :)
thanks,
greg k-h - 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/
| |