From: Greg KH <greg@kroah.com>
To: Andreas Happe <andreashappe@flatline.ath.cx>
Cc: James Morris <jmorris@redhat.com>,
linux-kernel@vger.kernel.org, cryptoapi@lists.logix.cz
Subject: Re: [cryptoapi/sysfs] display cipher details in sysfs
Date: Sun, 5 Sep 2004 17:04:46 -0700 [thread overview]
Message-ID: <20040906000446.GA16840@kroah.com> (raw)
In-Reply-To: <20040901082819.GA2489@final-judgement.ath.cx>
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
next prev parent reply other threads:[~2004-09-06 3:01 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20040831175449.GA2946@final-judgement.ath.cx>
[not found] ` <Xine.LNX.4.44.0409010043020.30561-100000@thoron.boston.redhat.com>
2004-09-01 8:28 ` [cryptoapi/sysfs] display cipher details in sysfs Andreas Happe
2004-09-06 0:04 ` Greg KH [this message]
2004-09-07 16:37 ` James Morris
2004-09-07 16:45 ` Greg KH
2004-09-07 16:47 ` Michal Ludvig
2004-09-07 16:52 ` Greg KH
2004-09-06 18:49 ` Michal Ludvig
2004-09-07 14:35 ` Andreas Happe
2004-09-07 15:49 ` Michal Ludvig
2004-09-07 16:57 ` Andreas Happe
2004-09-10 11:21 ` Andreas Happe
2004-09-10 10:55 ` Andreas Happe
2004-09-27 8:41 ` Andreas Happe
2004-09-27 9:10 ` Michal Ludvig
2004-09-28 12:34 ` Andreas Happe
2004-09-29 9:36 ` Andreas Happe
2004-09-29 9:37 ` Andreas Happe
2004-09-29 14:13 ` Michal Ludvig
2004-09-29 13:13 ` Michal Ludvig
2004-09-27 15:53 ` James Morris
2004-09-28 12:21 ` [PATCH 2.6.9-rc2 1/2] cryptoapi: update sysfs-patch Andreas Happe
2004-09-28 12:23 ` [PATCH 2.6.9-rc2 2/2] cryptoapi: make /proc/crypto optional Andreas Happe
2004-09-28 14:32 ` Sven Schuster
2004-09-29 8:40 ` Andreas Happe
2004-09-07 16:36 ` [cryptoapi/sysfs] display cipher details in sysfs James Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040906000446.GA16840@kroah.com \
--to=greg@kroah.com \
--cc=andreashappe@flatline.ath.cx \
--cc=cryptoapi@lists.logix.cz \
--cc=jmorris@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.