linux-kernel - Re: [PATCH] ieee1394: remove usage of skb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 18 Mar 2007 22:34:27 -0400
From:	"Kristian Høgsberg" <krh@...planet.net>
To:	"Stefan Richter" <stefanr@...6.in-berlin.de>
Cc:	linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ieee1394: remove usage of skb_queue as packet queue

On 3/17/07, Stefan Richter <stefanr@...6.in-berlin.de> wrote:
> This considerably reduces the memory requirements for a packet and
> eliminates ieee1394's dependency on CONFIG_NET.

Nice work Stefan, the skb rewrite was one of the most pointless
rewrites in the history of the linux1394 stack.

> TODO:
>   - Double-check if there are any drivers whose packet complete routine
>     really needs process context. If there are none, get rid of khpsbpkt
>     and execute the complete routine in the low-level driver's bottom
>     half's context.

Yup, mandatory running in process context is braindead, since most
complete routines just need to complete a completion or schedule some
work.

>   - Check whether the complete packet really has to be zeroed when
>     allocated.
>   - Allocate small frequently used packets (e.g. quadlet read requests
>     and 4...8 bytes write requests) from a kmem_cache. Append separately
>     allocated data sections only if necessary.

Not sure if this is worth it, kmalloc is pretty fast these days.

Hehe, you're reverting the bad decisions that made me tune out from
linux1394 development a few years back.  But the question is, is it
worth it?  One of the primary reasons for me to write an alternative
stack was to be able to leave linux1394 in maintenence mode.  This way
I wont screw up existing functionality in the old stack, and will be
able to make big changes without worrying about porting over every
single driver.

Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/