linux-kernel - Re: [PATCH 0/3] New firewire stack

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 06 Dec 2006 19:31:25 -0500
From:	Kristian Høgsberg <krh@...hat.com>
To:	Ben Collins <ben.collins@...ntu.com>
CC:	Stefan Richter <stefanr@...6.in-berlin.de>,
	Alexey Dobriyan <adobriyan@...il.com>,
	linux-kernel@...r.kernel.org, linux1394-devel@...ts.sourceforge.net
Subject: Re: [PATCH 0/3] New firewire stack

Ben Collins wrote:
...
>> I would like to see new development efforts take cleanliness WRT host
>> byte order and 64bit architectures into account from the ground up. (I
>> understand though why Kristian made the announcement in this early
>> phase, and I agree with him that this kind of development has to go into
>> the open early.)
> 
> And yet endianness is not the focus from the ground up in Kristian's
> work. That was my point.

I don't know what you base this on, it's not true.  Everything outside 
fw-ohci.c is endian aware and I know the two things I need to look into for 
fw-ohci: DMA programs and IEEE1394 headers.  My plan was to develop the stack 
towards feature completeness and then test on big-endian and 64-bit platforms.

If you're thinking of the bitfield problem BenH pointed out, that doesn't 
imply I didn't have endianess in mind when writing the code.  As Stefan 
already mentioned, we use bitfields for wire data in the current stack.  We 
have to sets of structs, one for big endian architectures and one for little 
endian architectures.  My plan was to write big endian versions of these 
structs and then test on various architectures.

So my bitfield approach doesn't work and I haven't gotten around to doing the 
big-endian testing yet, but don't mistake that for lack of endianess 
awareness.  Of course, big endian and 64-bit architectures *must* work, but I 
contend that it can impact the overall design of the stack.  It's a detail 
that you need to get right, not a design principle.  But let's not argue this 
further, I'll post a new set of patches in a few days that work on big-endian 
and 64-bit.

cheers,
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/