* Re: crypto API and IBM z990 hardware support
@ 2003-07-02 12:35 Thomas Spatzier
2003-07-02 16:57 ` James Morris
0 siblings, 1 reply; 22+ messages in thread
From: Thomas Spatzier @ 2003-07-02 12:35 UTC (permalink / raw)
To: James Morris; +Cc: linux-kernel
> Are there any details available on how all of this is implemented? Are
> these instructions synchronous?
Yes, the instructions are sunchronous.
> The plan is to provide crypto/arch/ subdirectories where arch optimized
> versions of the crypto algorithms are implemented, and built
automatically
> (via configuration defaults) instead of the generic C versions.
>
> So, there might be:
>
> crypto/aes.c
> crypto/arch/i386/aes.s
>
> where on i386, aes.s would be built into aes.o and aes.c would not be
> built.
>
> The simple solution for you might be something like:
>
> crypto/aes.c -> aes.o
> crypto/arch/s390/aes_z990.c -> aes_z990.o
>
> and the administrator of the system could configure modprobe.conf to
alias
> aes to aes_z990 if the latter is supported in hardware.
I agree on having arch-specific implementations in crypto/arch directories.
However, I've got some problems with having this kind of 'static' aliasing
in modules.conf. In my case I do not know beforehand, whether a specific
crypto instruction is enabled. I query some processor status flags during
runime. If the check fails, I'd like to switch back to the original
software implementation.
I read in your autoconf.c file that a more sophisticated version of
crypto_alg_autoload is planned. I would suggest first trying to load the
arch-specific aes_z990.ko in crypto_alg_autoload. In my init_module
function i could query the processor. If init_module for my implementation
fails -> request_module fails -> load the standard module aes.ko.
Something similar to this:
#ifndef CRYPTO_ARCH //defined in arch makefile as "_z990"
#define CRYPTO_ARCH ""
#endif
void crypto_alg_autoload(const char *name)
{
if (request_module("%s%s", name, CRYPTO_ARCH) != 0){
request_module("%s", name);
}
}
Regards,
Thomas Spatzier
--------------------------------------------------
+49-7031-16-1219
TSPAT@de.ibm.com
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: crypto API and IBM z990 hardware support
2003-07-02 12:35 crypto API and IBM z990 hardware support Thomas Spatzier
@ 2003-07-02 16:57 ` James Morris
2003-07-07 7:11 ` Christoph Hellwig
0 siblings, 1 reply; 22+ messages in thread
From: James Morris @ 2003-07-02 16:57 UTC (permalink / raw)
To: Thomas Spatzier; +Cc: linux-kernel
On Wed, 2 Jul 2003, Thomas Spatzier wrote:
> I agree on having arch-specific implementations in crypto/arch directories.
> However, I've got some problems with having this kind of 'static' aliasing
> in modules.conf. In my case I do not know beforehand, whether a specific
> crypto instruction is enabled. I query some processor status flags during
> runime. If the check fails, I'd like to switch back to the original
> software implementation.
I did say it was the simple solution :-)
> I read in your autoconf.c file that a more sophisticated version of
> crypto_alg_autoload is planned. I would suggest first trying to load the
> arch-specific aes_z990.ko in crypto_alg_autoload. In my init_module
> function i could query the processor. If init_module for my implementation
> fails -> request_module fails -> load the standard module aes.ko.
> Something similar to this:
>
> #ifndef CRYPTO_ARCH //defined in arch makefile as "_z990"
> #define CRYPTO_ARCH ""
> #endif
>
> void crypto_alg_autoload(const char *name)
> {
> if (request_module("%s%s", name, CRYPTO_ARCH) != 0){
> request_module("%s", name);
> }
> }
I'd like to avoid these kind of macros, and make it a general case
solution (e.g. which can be used for various hardware implementations).
One possibility would be to allow registration with an alias list in
crypto API with attributes indicating whether the module is hardware,
arch-specific etc.
So, during init, the s390 arch could register an alias like:
name .= "aes_z990"
algorithm .= "aes"
attributes .= CRYPTO_ATTR_ARCH|CRYPTO_ATTR_HW
Then, when a caller specifies "aes", crypto_alg_autoload() would first
check the alias list, giving preference to CRYPTO_ALG_ARCH by default.
In this case, it would find aes_z990 and try and load it. If this fails,
it continues along the alias list then ultimately falls back to the
current behavior.
This would allow subsystems and hardware drivers to dynamically provide
information to the API. Callers of crypto_alloc_tfm() could then pass
flags specifying preferences for algorithm implementations e.g. generic
sw, arch sw, arch hw, misc hw.
This would also need to take into account modprobe.conf configuration and
compiled in modules.
- James
--
James Morris
<jmorris@intercode.com.au>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: crypto API and IBM z990 hardware support
2003-07-02 16:57 ` James Morris
@ 2003-07-07 7:11 ` Christoph Hellwig
2003-07-07 10:27 ` James Morris
0 siblings, 1 reply; 22+ messages in thread
From: Christoph Hellwig @ 2003-07-07 7:11 UTC (permalink / raw)
To: James Morris; +Cc: Thomas Spatzier, linux-kernel
On Thu, Jul 03, 2003 at 02:57:30AM +1000, James Morris wrote:
> Then, when a caller specifies "aes", crypto_alg_autoload() would first
> check the alias list, giving preference to CRYPTO_ALG_ARCH by default.
> In this case, it would find aes_z990 and try and load it. If this fails,
> it continues along the alias list then ultimately falls back to the
> current behavior.
This sounds like the right way to do it. The question is just whether we
want to put that complicated policy into the kernel or into some userspace
helper.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: crypto API and IBM z990 hardware support
2003-07-07 7:11 ` Christoph Hellwig
@ 2003-07-07 10:27 ` James Morris
0 siblings, 0 replies; 22+ messages in thread
From: James Morris @ 2003-07-07 10:27 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Thomas Spatzier, linux-kernel
On Mon, 7 Jul 2003, Christoph Hellwig wrote:
> This sounds like the right way to do it. The question is just whether we
> want to put that complicated policy into the kernel or into some userspace
> helper.
A userspace helper sounds interesting, as we also need a way to allow
unprivileged users to invoke kernel crypto, which may require modules to
be loaded.
- James
--
James Morris
<jmorris@intercode.com.au>
^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <4P45.5YN.11@gated-at.bofh.it>]
* Re: crypto API and IBM z990 hardware support
@ 2003-07-02 20:23 Ulrich Weigand
0 siblings, 0 replies; 22+ messages in thread
From: Ulrich Weigand @ 2003-07-02 20:23 UTC (permalink / raw)
To: jmorris; +Cc: linux-kernel, tspat
James Morris wrote:
>Are there any details available on how all of this is implemented? Are
>these instructions synchronous?
FYI, the relevant instructions are documented in the z/Architecture
Principles of Operation, available on the Web at:
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dz9zr002
Check Chapter 7 for the instructions:
CHIPER MESSAGE (KM)
CHIPER MESSAGE WITH CHAINING (KMC)
COMPUTE INTERMEDIATE MESSAGE DIGEST (KIMD)
COMPUTE LAST MESSAGE DIGEST (KLMD)
COMPUTE MESSAGE AUTHENTICATION CODE (KMAC)
Bye,
Ulrich
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
^ permalink raw reply [flat|nested] 22+ messages in thread
* crypto API and IBM z990 hardware support
@ 2003-07-02 7:07 Thomas Spatzier
2003-07-02 9:35 ` James Morris
0 siblings, 1 reply; 22+ messages in thread
From: Thomas Spatzier @ 2003-07-02 7:07 UTC (permalink / raw)
To: jmorris; +Cc: linux-kernel
Hello James,
I'm currently looking at the crypto API and considering adding support for
new hardware instructions implemented in the IBM z990 architecture. Since I
found your name in most of the files I find it appropriate to ask for your
opinion on how to integrate the new code (from a design point of view).
z990 provides hardware support for AES, DES and SHA. The problem is, that
the respective instructions might not be implemented on all z990 systems
(export restrictions etc). Hence, a check must be run to test whether the
instruction set is present, and if not, a fall-back to the current software
implementation must be taken. I basically have two solutions in mind: (1)
to integrate the new code into the current crypto files; add some #ifdef s
to prevent the code from being compiled when building a non-z990 kernel;
add some ifs for runtime check. (2) include the new code into an
arch/s390/crypto directory.
The advantage of (1) is that there are no seperate crypto directories, the
code doesn't drift apart. Furthermore, it's probably the best solution with
respect to the kernel module loader. On the other hand, the hardware
support is very arch-specific, which would fit in option (2). (2) however
has the disadvantage that there are multiple crypto modules; the user has
to select one to load -> must have different names for one algorithm.
What is your opinion on this subject?
Regards,
Thomas Spatzier
--------------------------------------------------
+49-7031-16-1219
TSPAT@de.ibm.com
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: crypto API and IBM z990 hardware support
2003-07-02 7:07 Thomas Spatzier
@ 2003-07-02 9:35 ` James Morris
2003-07-07 7:09 ` Christoph Hellwig
0 siblings, 1 reply; 22+ messages in thread
From: James Morris @ 2003-07-02 9:35 UTC (permalink / raw)
To: Thomas Spatzier; +Cc: linux-kernel, David S. Miller
On Wed, 2 Jul 2003, Thomas Spatzier wrote:
> Hello James,
>
> I'm currently looking at the crypto API and considering adding support for
> new hardware instructions implemented in the IBM z990 architecture. Since I
> found your name in most of the files I find it appropriate to ask for your
> opinion on how to integrate the new code (from a design point of view).
> z990 provides hardware support for AES, DES and SHA. The problem is, that
> the respective instructions might not be implemented on all z990 systems
> (export restrictions etc). Hence, a check must be run to test whether the
> instruction set is present, and if not, a fall-back to the current software
> implementation must be taken.
Are there any details available on how all of this is implemented? Are
these instructions synchronous?
> I basically have two solutions in mind: (1)
> to integrate the new code into the current crypto files; add some #ifdef s
> to prevent the code from being compiled when building a non-z990 kernel;
> add some ifs for runtime check.
No, the core crypto code should not be altered with #ifdefs to handle some
arch specific issue.
> (2) include the new code into an arch/s390/crypto directory. The
> advantage of (1) is that there are no seperate crypto directories, the
> code doesn't drift apart. Furthermore, it's probably the best solution
> with respect to the kernel module loader. On the other hand, the
> hardware support is very arch-specific, which would fit in option (2).
> (2) however has the disadvantage that there are multiple crypto modules;
> the user has to select one to load -> must have different names for one
> algorithm. What is your opinion on this subject?
The plan is to provide crypto/arch/ subdirectories where arch optimized
versions of the crypto algorithms are implemented, and built automatically
(via configuration defaults) instead of the generic C versions.
So, there might be:
crypto/aes.c
crypto/arch/i386/aes.s
where on i386, aes.s would be built into aes.o and aes.c would not be
built.
The simple solution for you might be something like:
crypto/aes.c -> aes.o
crypto/arch/s390/aes_z990.c -> aes_z990.o
and the administrator of the system could configure modprobe.conf to alias
aes to aes_z990 if the latter is supported in hardware.
- James
--
James Morris
<jmorris@intercode.com.au>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: crypto API and IBM z990 hardware support
2003-07-02 9:35 ` James Morris
@ 2003-07-07 7:09 ` Christoph Hellwig
2003-07-08 2:53 ` David S. Miller
0 siblings, 1 reply; 22+ messages in thread
From: Christoph Hellwig @ 2003-07-07 7:09 UTC (permalink / raw)
To: James Morris; +Cc: Thomas Spatzier, linux-kernel, David S. Miller
On Wed, Jul 02, 2003 at 07:35:16PM +1000, James Morris wrote:
> The plan is to provide crypto/arch/ subdirectories where arch optimized
> versions of the crypto algorithms are implemented, and built automatically
> (via configuration defaults) instead of the generic C versions.
>
> So, there might be:
>
> crypto/aes.c
> crypto/arch/i386/aes.s
crypto/arch/ sounds like a bad idea. We really should avoid arch code
outside arch/ and include/asm*. So arch/<foo>/crypto/ as suggested by
Thomas is much better.
> where on i386, aes.s would be built into aes.o and aes.c would not be
> built.
That's a really bad idea. Think of a i586/i686 optimized assembler
implementaion e.g. using MMX or SSE or whatever. You'll always need
the generic version as fallback.
> The simple solution for you might be something like:
>
> crypto/aes.c -> aes.o
> crypto/arch/s390/aes_z990.c -> aes_z990.o
>
> and the administrator of the system could configure modprobe.conf to alias
> aes to aes_z990 if the latter is supported in hardware.
Right. And IMHO this should happen with all optimized version - putting
policy in the kernel to select them sounds like a bad idea, especially
as it could get rather complicated when it involves multiple optimized
and / or hardware implementations.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: crypto API and IBM z990 hardware support
2003-07-07 7:09 ` Christoph Hellwig
@ 2003-07-08 2:53 ` David S. Miller
2003-07-08 3:37 ` Roland Dreier
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: David S. Miller @ 2003-07-08 2:53 UTC (permalink / raw)
To: hch; +Cc: jmorris, TSPAT, linux-kernel
From: Christoph Hellwig <hch@infradead.org>
Date: Mon, 7 Jul 2003 08:09:29 +0100
On Wed, Jul 02, 2003 at 07:35:16PM +1000, James Morris wrote:
> So, there might be:
>
> crypto/aes.c
> crypto/arch/i386/aes.s
crypto/arch/ sounds like a bad idea. We really should avoid arch code
outside arch/ and include/asm*. So arch/<foo>/crypto/ as suggested by
Thomas is much better.
I totally disagree. I think the way we do things today is _STUPID_.
We put arch code far away from the generic version which makes finding
stuff very difficult for people inspecting the code for the first time.
For example, the fact that I have to go groveling in
arch/foo/lib/whoknowswhatfile.whoknowswhatextension to look at
the memcpy/checksum/whatever implementation is completely busted.
So, I totally support making crypto/arch/ directories.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: crypto API and IBM z990 hardware support
2003-07-08 2:53 ` David S. Miller
@ 2003-07-08 3:37 ` Roland Dreier
2003-07-08 3:35 ` David S. Miller
2003-07-10 1:08 ` Werner Almesberger
[not found] ` <mailman.1057799700.15422.linux-kernel2news@redhat.com>
2 siblings, 1 reply; 22+ messages in thread
From: Roland Dreier @ 2003-07-08 3:37 UTC (permalink / raw)
To: David S. Miller; +Cc: hch, jmorris, TSPAT, linux-kernel
Christoph> crypto/arch/ sounds like a bad idea. We really should
Christoph> avoid arch code outside arch/ and include/asm*. So
Christoph> arch/<foo>/crypto/ as suggested by Thomas is much
Christoph> better.
David> I totally disagree. I think the way we do things today is
David> _STUPID_. We put arch code far away from the generic
David> version which makes finding stuff very difficult for people
David> inspecting the code for the first time.
David> For example, the fact that I have to go groveling in
David> arch/foo/lib/whoknowswhatfile.whoknowswhatextension to look
David> at the memcpy/checksum/whatever implementation is
David> completely busted.
I see your point. Still, I think there is a lot to be said for
keeping arch code in arch/xxx and include/asm-xxx. It means that
someone working on a new port (I don't necessarily mean a totally new
arch, but also adding support for some new CPU model or platform) has
a well-defined set of directories to look at.
It's also nice that the xxx-arch maintainers can say "we are the rulers
of arch/xxx and include/asm-xxx" and know that any changes outside of
those directories have to go through lkml.
By the way, I agree that it would be good if <asm/string.h> had
something like
/* See arch-xxx/lib/string.S for implementation of these */
Still, I don't think I would like it if we had
alpha/ arm/ arm26/ cris/ h8300/ i386/ ia64/ m68k/ m68knommu/
mips/ mips64/ parisc ppc/ ppc64/ s390/ sh/ sparc/ sparc64/ um/
v850/ x86_64/ generic/
directories scattered all over the source tree.
- Roland
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: crypto API and IBM z990 hardware support
2003-07-08 3:37 ` Roland Dreier
@ 2003-07-08 3:35 ` David S. Miller
0 siblings, 0 replies; 22+ messages in thread
From: David S. Miller @ 2003-07-08 3:35 UTC (permalink / raw)
To: roland; +Cc: hch, jmorris, TSPAT, linux-kernel
From: Roland Dreier <roland@topspin.com>
Date: 07 Jul 2003 20:37:09 -0700
Still, I think there is a lot to be said for keeping arch code in
arch/xxx and include/asm-xxx. It means that someone working on a
new port (I don't necessarily mean a totally new arch, but also
adding support for some new CPU model or platform) has a
well-defined set of directories to look at.
I again disagree. We're talking about things here where
the default you get is _working_.
Only if you want to enhance or _optimize_ your port do you
need to modify any of this crap.
In this way it's fundamentally different from things that
one normally finds under arch/foo and include/asm-foo
It's also nice that the xxx-arch maintainers can say "we are the rulers
of arch/xxx and include/asm-xxx" and know that any changes outside of
those directories have to go through lkml.
This isn't nice, it's rather bad for this case.
I think it'd be great that the "crypto maintainer" can be the one
by which "crypto changes" need to go through. So again, I totally
disagree with your assesment.
Still, I don't think I would like it if we had
alpha/ arm/ arm26/ cris/ h8300/ i386/ ia64/ m68k/ m68knommu/
mips/ mips64/ parisc ppc/ ppc64/ s390/ sh/ sparc/ sparc64/ um/
v850/ x86_64/ generic/
directories scattered all over the source tree.
I see no problem with this at all. In fact, I wish we had a much
higher directory to file ratio in the kernel tree.
And hey, if I went "find crypto -type d -name sparc" I'd know if there
are sparc optimizations for the crypto library. How might you do this
with the current "everything and it's mother under arch/" scheme?
Answer: you can't.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: crypto API and IBM z990 hardware support
2003-07-08 2:53 ` David S. Miller
2003-07-08 3:37 ` Roland Dreier
@ 2003-07-10 1:08 ` Werner Almesberger
2003-07-10 1:08 ` David S. Miller
[not found] ` <mailman.1057799700.15422.linux-kernel2news@redhat.com>
2 siblings, 1 reply; 22+ messages in thread
From: Werner Almesberger @ 2003-07-10 1:08 UTC (permalink / raw)
To: David S. Miller; +Cc: hch, jmorris, TSPAT, linux-kernel
David S. Miller wrote:
> I totally disagree. I think the way we do things today is _STUPID_.
> We put arch code far away from the generic version which makes finding
> stuff very difficult for people inspecting the code for the first time.
>
> For example, the fact that I have to go groveling in
> arch/foo/lib/whoknowswhatfile.whoknowswhatextension to look at
> the memcpy/checksum/whatever implementation is completely busted.
Hear ! Hear ! Maybe I could also get you interested in the idea
of moving headers with inline functions to the only spot where
they are actually used ?
E.g. most of include/net/tcp.h pretty much only matters for
net/ipv4/. It would be so nice if a grep -w thing *.[ch] in
net/ipv4/ would really find all uses of "thing".
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: crypto API and IBM z990 hardware support
2003-07-10 1:08 ` Werner Almesberger
@ 2003-07-10 1:08 ` David S. Miller
2003-07-10 2:06 ` Werner Almesberger
0 siblings, 1 reply; 22+ messages in thread
From: David S. Miller @ 2003-07-10 1:08 UTC (permalink / raw)
To: wa; +Cc: hch, jmorris, TSPAT, linux-kernel
From: Werner Almesberger <wa@almesberger.net>
Date: Wed, 9 Jul 2003 22:08:25 -0300
E.g. most of include/net/tcp.h pretty much only matters for
net/ipv4/. It would be so nice if a grep -w thing *.[ch] in
net/ipv4/ would really find all uses of "thing".
Bad example, I'd say that %65 of that file is used in net/ipv6/*.c
files too.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: crypto API and IBM z990 hardware support
2003-07-10 1:08 ` David S. Miller
@ 2003-07-10 2:06 ` Werner Almesberger
2003-07-10 2:06 ` David S. Miller
0 siblings, 1 reply; 22+ messages in thread
From: Werner Almesberger @ 2003-07-10 2:06 UTC (permalink / raw)
To: David S. Miller; +Cc: hch, jmorris, TSPAT, linux-kernel
David S. Miller wrote:
> Bad example, I'd say that %65 of that file is used in net/ipv6/*.c
> files too.
Considering only inline functions, 64 of the 89 functions my script
below finds in my 2.5.72 tree are only used in net/ipv4 (or tcp.h
itself). That's almost 72%. Only 22 of the functions (25%) are used
in net/ipv6.
A lot of the code there is basically an extension of net/ipv4/tcp*.c,
so it seems odd to put it at a completely different location, only
because it happens to be inlined.
#!/bin/sh
SRC=include/net/tcp.h
for n in `sed '/^.*inline.* \([a-zA-Z_0-9]*\)([^;]*$/s//\1/p;d' <$SRC`; do
echo -n "$n: "
echo `find . -name '*.[ch]' | fgrep -vx ./$SRC | xargs grep -lrw $n`
done
File is "out":
wc -l out
89 out
sed 's|\./net/ipv4/[^/]*\>||g' <out | fgrep -v . | wc -l
64
sed 's|\./net/ipv4/[^/]*\>||g' <out | grep -c net/ipv6
22
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: crypto API and IBM z990 hardware support
2003-07-10 2:06 ` Werner Almesberger
@ 2003-07-10 2:06 ` David S. Miller
2003-07-10 2:37 ` Werner Almesberger
0 siblings, 1 reply; 22+ messages in thread
From: David S. Miller @ 2003-07-10 2:06 UTC (permalink / raw)
To: wa; +Cc: hch, jmorris, TSPAT, linux-kernel
From: Werner Almesberger <wa@almesberger.net>
Date: Wed, 9 Jul 2003 23:06:37 -0300
Considering only inline functions, 64 of the 89 functions my script
below finds in my 2.5.72 tree are only used in net/ipv4 (or tcp.h
itself). That's almost 72%. Only 22 of the functions (25%) are used
in net/ipv6.
I was considering structure definitions, macros, and whatnot
as well.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: crypto API and IBM z990 hardware support
2003-07-10 2:06 ` David S. Miller
@ 2003-07-10 2:37 ` Werner Almesberger
2003-07-11 0:02 ` David S. Miller
0 siblings, 1 reply; 22+ messages in thread
From: Werner Almesberger @ 2003-07-10 2:37 UTC (permalink / raw)
To: David S. Miller; +Cc: hch, jmorris, TSPAT, linux-kernel
David S. Miller wrote:
> I was considering structure definitions, macros, and whatnot
> as well.
Yes, structure definitions and the like are fine. Sorry, I wasn't
quite clear: it's the code living in include/* for apparently no
good reason (i.e. it's only used at one place, is unlikely to be
used by modules, and doesn't define an interface) that I find
irritating.
BTW, even of the macros with arguments, about 66% seem to be of
the "local use only" type.
#!/bin/sh
SRC=include/net/tcp.h
for n in `sed '/^# *define[^!-~]*\([a-zA-Z_0-9]*\)(.*/s//\1/p;d' \
<$SRC | sort | uniq`; do
echo -n "$n: "
echo `find . -name '*.[ch]' | fgrep -vx ./$SRC | xargs grep -lrw $n`
done
wc -l out2
21 out2
sed 's|\./net/ipv4/[^/]*\>||g' <out2 | fgrep -v . | wc -l
14
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: crypto API and IBM z990 hardware support
2003-07-10 2:37 ` Werner Almesberger
@ 2003-07-11 0:02 ` David S. Miller
0 siblings, 0 replies; 22+ messages in thread
From: David S. Miller @ 2003-07-11 0:02 UTC (permalink / raw)
To: wa; +Cc: hch, jmorris, TSPAT, linux-kernel
From: Werner Almesberger <wa@almesberger.net>
Date: Wed, 9 Jul 2003 23:37:07 -0300
BTW, even of the macros with arguments, about 66% seem to be of
the "local use only" type.
Ok.
In the first stage, I'd be happy to take patches that extract out
inline functions that get used in only one TCP source file.
Those should be easy to find especially for all of the congestion
control etc. stuff going on in tcp_input.c
^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <mailman.1057799700.15422.linux-kernel2news@redhat.com>]
* Re: crypto API and IBM z990 hardware support
[not found] ` <mailman.1057799700.15422.linux-kernel2news@redhat.com>
@ 2003-07-10 5:55 ` Pete Zaitcev
0 siblings, 0 replies; 22+ messages in thread
From: Pete Zaitcev @ 2003-07-10 5:55 UTC (permalink / raw)
To: Werner Almesberger; +Cc: linux-kernel
>> I totally disagree. I think the way we do things today is _STUPID_.
>> We put arch code far away from the generic version which makes finding
>> stuff very difficult for people inspecting the code for the first time.
>>
>> For example, the fact that I have to go groveling in
>> arch/foo/lib/whoknowswhatfile.whoknowswhatextension to look at
>> the memcpy/checksum/whatever implementation is completely busted.
> E.g. most of include/net/tcp.h pretty much only matters for
> net/ipv4/. It would be so nice if a grep -w thing *.[ch] in
> net/ipv4/ would really find all uses of "thing".
I always do this:
cd linux
find . \( -name 'Make*' -o -name '*.[hcS]' \) > src.list
cat src.list| LANG=C xargs grep foo
It's only a CPU time, really.
-- Pete
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2003-07-10 23:57 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-02 12:35 crypto API and IBM z990 hardware support Thomas Spatzier
2003-07-02 16:57 ` James Morris
2003-07-07 7:11 ` Christoph Hellwig
2003-07-07 10:27 ` James Morris
[not found] <4P45.5YN.11@gated-at.bofh.it>
[not found] ` <4T81.24d.41@gated-at.bofh.it>
2003-07-02 22:06 ` Arnd Bergmann
2003-07-06 14:08 ` James Morris
2003-07-06 17:46 ` Arnd Bergmann
2003-07-07 7:14 ` Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2003-07-02 20:23 Ulrich Weigand
2003-07-02 7:07 Thomas Spatzier
2003-07-02 9:35 ` James Morris
2003-07-07 7:09 ` Christoph Hellwig
2003-07-08 2:53 ` David S. Miller
2003-07-08 3:37 ` Roland Dreier
2003-07-08 3:35 ` David S. Miller
2003-07-10 1:08 ` Werner Almesberger
2003-07-10 1:08 ` David S. Miller
2003-07-10 2:06 ` Werner Almesberger
2003-07-10 2:06 ` David S. Miller
2003-07-10 2:37 ` Werner Almesberger
2003-07-11 0:02 ` David S. Miller
[not found] ` <mailman.1057799700.15422.linux-kernel2news@redhat.com>
2003-07-10 5:55 ` Pete Zaitcev
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).