public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Kristian Høgsberg" <krh@redhat.com>
To: Ben Collins <ben.collins@ubuntu.com>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	linux-kernel@vger.kernel.org,
	linux1394-devel@lists.sourceforge.net
Subject: Re: [PATCH 0/3] New firewire stack
Date: Wed, 06 Dec 2006 19:31:25 -0500	[thread overview]
Message-ID: <457760DD.5070601@redhat.com> (raw)
In-Reply-To: <1165416546.7443.111.camel@gullible>

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

  reply	other threads:[~2006-12-07  0:36 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-05  5:22 [PATCH 0/3] New firewire stack Kristian Høgsberg
2006-12-05  5:22 ` [PATCH 2/3] Import fw-ohci driver Kristian Høgsberg
2006-12-05  5:54   ` Pete Zaitcev
2006-12-05  5:58   ` Jeff Garzik
2006-12-05  6:09     ` Benjamin Herrenschmidt
2006-12-09  2:08     ` Kristian Høgsberg
2006-12-09  7:31       ` Stefan Richter
2006-12-10 21:47         ` Kristian Høgsberg
2006-12-10 22:59           ` Stefan Richter
2006-12-10 23:00             ` alignment and packing of struct types (was Re: [PATCH 2/3] Import fw-ohci driver.) Stefan Richter
2006-12-05  5:22 ` [PATCH 3/3] Import fw-sbp2 driver Kristian Høgsberg
2006-12-05  6:07   ` Jeff Garzik
2006-12-05 18:18     ` Stefan Richter
2006-12-14 20:48     ` Kristian Høgsberg
2006-12-14 21:40       ` Stefan Richter
2006-12-15 15:08         ` Kristian Høgsberg
2006-12-15 18:27           ` Stefan Richter
2006-12-05  5:42 ` [PATCH 0/3] New firewire stack Benjamin Herrenschmidt
2006-12-05  6:20   ` Kristian Høgsberg
2006-12-05 16:28     ` Ray Lee
2006-12-05 23:24       ` Kristian Høgsberg
2006-12-05  7:05   ` David Miller
2006-12-05 16:42     ` Kristian Høgsberg
2006-12-05 18:49       ` Stefan Richter
2006-12-05 21:41         ` Benjamin Herrenschmidt
2006-12-05 23:15           ` Stefan Richter
2006-12-05  8:46 ` Marcel Holtmann
2006-12-05 15:13   ` Kristian Høgsberg
2006-12-05 15:30     ` Marcel Holtmann
2006-12-06 16:21       ` Geert Uytterhoeven
2006-12-06 16:32         ` Stefan Richter
2006-12-05 16:05     ` Erik Mouw
2006-07-12 14:56       ` Pavel Machek
2006-12-08 15:09         ` Stefan Richter
2006-12-09 19:44           ` Kristian Høgsberg
2006-12-10 12:57             ` Stefan Richter
2006-12-10 22:17               ` Kristian Høgsberg
2006-12-10 23:21                 ` Stefan Richter
2006-12-09 21:51           ` Benjamin Herrenschmidt
2006-12-09 22:51             ` Stefan Richter
2006-12-05 16:53       ` Marcel Holtmann
2006-12-05 23:27         ` Kristian Høgsberg
2006-12-05 18:49 ` Alexey Dobriyan
2006-12-05 19:53   ` Stefan Richter
2006-12-05 23:21   ` Kristian Høgsberg
2006-12-06  5:35     ` Ben Collins
2006-12-06  8:56       ` Stefan Richter
2006-12-06 11:40         ` Alexander Neundorf
2006-12-06 12:38           ` Stefan Richter
2006-12-06 21:21             ` Kristian Høgsberg
2006-12-06 14:49         ` Ben Collins
2006-12-07  0:31           ` Kristian Høgsberg [this message]
2006-12-06  8:36     ` Stefan Richter
2006-12-06 22:27       ` Kristian Høgsberg
2006-12-06 23:55         ` Stefan Richter
2006-12-05 23:23 ` Olaf Hering

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=457760DD.5070601@redhat.com \
    --to=krh@redhat.com \
    --cc=adobriyan@gmail.com \
    --cc=ben.collins@ubuntu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=stefanr@s5r6.in-berlin.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox