Kristian Høgsberg announced that he is working on a new firewire stack to replace the stack currently in the Linux kernel. "I'm aiming to implement feature parity with the current firewire stack, but not necessarily interface compatibility," Kristian explained, "for now, I have the low-level OHCI driver done, the mid-level transaction logic done, and the SBP-2 (storage) driver is basically done." He went on to explain that he didn't initially intend to rewrite the entire firewire stack, "at first I just wanted to fix the OHCI driver. However any rewrite that addresses the problems in the driver will shift the code around enough to invalidate the quirks and workarounds there. And frankly, I don't trust most of the workarounds to begin with. So I decided to write the OHCI driver from scratch."

Ben Collins expressed some concerns about the decision to abandon the existing stack, "the tree is years old, and a lot of work has been put into it (lots of my work, I'll admit I'm being a little protective). I'm not sure that 'replacing' it is wise, or even needed. Fork it, clean it up, but rewriting just doesn't make sense." He went on to caution, "when I picked up ieee1394 maint myself, it was because it was not big-endian or 64-bit friendly. I spent the better part of 3 months getting this right on PPC and UltraSPARC. Not because it's hard to fix these issues, but because the hardware is not well defined for a lot of these cases." Kristian explained, "I'm not doing this lightheartedly. It's a lot of work and it will introduce regressions and instability for a little while. My main point about ohci1394 (the old stacks PCI driver) is, that if you really want to fix the issues with this driver, you have to shuffle the code around so much that you'll introduce as many regressions as a clean rewrite. The big problems in the ohci1394 drivers [are] the irq_handler, bus reset handling and config rom handling."

From: "Kristian Høgsberg" [email blocked]
To:  linux-kernel
Subject: [PATCH 0/3] New firewire stack
Date:	Tue, 05 Dec 2006 00:22:29 -0500

Hi,

I'm announcing an alternative firewire stack that I've been working on
the last few weeks.  I'm aiming to implement feature parity with the
current firewire stack, but not necessarily interface compatibility.
For now, I have the low-level OHCI driver done, the mid-level
transaction logic done, and the SBP-2 (storage) driver is basically
done.  What's missing is a streaming interface (in progress) to allow
reception and transmission of isochronous data and a userspace
interface for controlling devices (much like raw1394 or libusb for
usb).  I'm working out of this git repository:

  http://gitweb.freedesktop.org/?p=users/krh/juju.git

but I'll be sending 3 patches for review after this mail: first the
core subsystem, then the OHCI driver and finally the SBP-2 (SCSI over
firewire) driver.  For people who want to test this out, the easiest
approach right now is to clone the git repo and run make.  This
requires the kernel-devel RPM on Fedora Core; I'm sure other distros
have a similar package.

Now, I didn't set out to rewrite the entire firewire stack.  At first
I just wanted to fix the OHCI driver.  However any rewrite that
addresses the problems in the driver will shift the code around enough
to invalidate the quirks and workarounds there.  And frankly, I don't
trust most of the workarounds to begin with.  So I decided to write
the OHCI driver from scratch.

The rest of the stack has problems too, there's too many kernel
threads bouncing around, the nodemgr code is racy and doesn't really
consider issues such as hotplug during device probing.  And there is 5
different interfaces for doing isochronous streaming.

The new stack is more compact and I'd like to think it's easier to
follow the code.  Here are the sizes for the three patches that
follow:

[juju:linux-2.6]$ wc -l patches-juju/*.patch
  3983 patches-juju/fw-core.patch
  1510 patches-juju/fw-ohci.patch
  1114 patches-juju/fw-sbp2.patch
  6607 total

Compared to

[krh@dinky ieee1394]$ wc -l *.[ch]
 ...
 30431 total

The new stack can co-exists with the old stack, since it's sitting in
drivers/fw.  So users can pick which stack they want at compile time,
or maybe compile both and switch at run-time using a modprobe
blacklist file.  This allows a transition phase from the old stack to
the new one where interfaces will be awailable.

At this point I'm not proposing the stack for inclusion into mainline
yet, as I'm still developing the streaming interface and the userspace
control interface.  This is just a heads up for now, to announce the
effort and where I'd like to go with this.  It is basically useful
with the storage devices I have available here, though, and ready for
testing for that specific use case.  Once the remaining features land,
I'd like to see this in mainstream linux and I'm interested in hearing
how people feel about this.

cheers,
Kristian



From: Benjamin Herrenschmidt [email blocked]
Subject: Re: [PATCH 0/3] New firewire stack
Date:	Tue, 05 Dec 2006 16:42:42 +1100

On Tue, 2006-12-05 at 00:22 -0500, Kristian Høgsberg wrote:
> Hi,
> 
> I'm announcing an alternative firewire stack that I've been working on
> the last few weeks.  I'm aiming to implement feature parity with the
> current firewire stack, but not necessarily interface compatibility.
> For now, I have the low-level OHCI driver done, the mid-level
> transaction logic done, and the SBP-2 (storage) driver is basically
> done.  What's missing is a streaming interface (in progress) to allow
> reception and transmission of isochronous data and a userspace
> interface for controlling devices (much like raw1394 or libusb for
> usb).  I'm working out of this git repository:

A very very very quick look at the code shows that:

 - It looks nice / clear
 - It's horribly broken in at least two area :

 DO NOT USE BITFIELDS FOR DATA ON THE WIRE !!!

 and

 Where do you handle endianness ? (no need to shout for
 that one).

(Or in general, do not use bitfields period ....)

bitfields format is not guaranteed, and is not endian consistent. 

Ben.



From: David Miller [email blocked]
Subject: Re: [PATCH 0/3] New firewire stack
Date:	Mon, 04 Dec 2006 23:05:02 -0800 (PST)

From: Benjamin Herrenschmidt [email blocked]
Date: Tue, 05 Dec 2006 16:42:42 +1100

>  - It's horribly broken in at least two area :
> 
>  DO NOT USE BITFIELDS FOR DATA ON THE WIRE !!!
> 
>  and
> 
>  Where do you handle endianness ? (no need to shout for
>  that one).
> 
> (Or in general, do not use bitfields period ....)

Yes, this is a show stopper, the endianness and
word-size/endian testing should have been done before
submission.



From: Kristian Høgsberg [email blocked]
Subject: Re: [PATCH 0/3] New firewire stack
Date:	Tue, 05 Dec 2006 11:42:24 -0500

David Miller wrote:
> From: Benjamin Herrenschmidt [email blocked]
> Date: Tue, 05 Dec 2006 16:42:42 +1100
> 
>>  - It's horribly broken in at least two area :
>>
>>  DO NOT USE BITFIELDS FOR DATA ON THE WIRE !!!
>>
>>  and
>>
>>  Where do you handle endianness ? (no need to shout for
>>  that one).
>>
>> (Or in general, do not use bitfields period ....)
> 
> Yes, this is a show stopper, the endianness and
> word-size/endian testing should have been done before
> submission.

I guess my mistake here was to present it as a patch submission.  I 
acknowledged in my cover letter that it wasn't feature complete and I'm not 
pushing for inclusion just yet.  I'm very much aware of the point that when 
replacing a subsystem like this, the new code has to be as good as the old 
code.  In that respect, the patches I posted are lacking in other areas 
(isochronous streaming is the big one) that will take more work to fix than 
just making it work on big-endian and 64-bit architectures.  It's still a work 
in progress.

Having said that, I've been working on this for a while now, and I wanted to 
announce the effort and open the discussion about replacing the old stack. 
Something about "release early, release often"... :)  Anyway, I've moved the 
portability issues to the top of my list now.

Kristian


From: Marcel Holtmann [email blocked]
Subject: Re: [PATCH 0/3] New firewire stack
Date:	Tue, 05 Dec 2006 09:46:40 +0100

Hi Kristian,

> I'm announcing an alternative firewire stack that I've been working on
> the last few weeks.  I'm aiming to implement feature parity with the
> current firewire stack, but not necessarily interface compatibility.
> For now, I have the low-level OHCI driver done, the mid-level
> transaction logic done, and the SBP-2 (storage) driver is basically
> done.  What's missing is a streaming interface (in progress) to allow
> reception and transmission of isochronous data and a userspace
> interface for controlling devices (much like raw1394 or libusb for
> usb).  I'm working out of this git repository:
> 
>   http://gitweb.freedesktop.org/?p=users/krh/juju.git
> 
> but I'll be sending 3 patches for review after this mail: first the
> core subsystem, then the OHCI driver and finally the SBP-2 (SCSI over
> firewire) driver.  For people who want to test this out, the easiest
> approach right now is to clone the git repo and run make.  This
> requires the kernel-devel RPM on Fedora Core; I'm sure other distros
> have a similar package.

can you please use drivers/firewire/ if you want to start clean or
aiming at replacing drivers/ieee1394/. Using "fw" as an abbreviation in
the directory path is not really helpful.

Regards

Marcel



From: Kristian Høgsberg [email blocked]
Subject: Re: [PATCH 0/3] New firewire stack
Date:	Tue, 05 Dec 2006 10:13:55 -0500

Marcel Holtmann wrote:
> Hi Kristian,
> 
>> I'm announcing an alternative firewire stack that I've been working on
>> the last few weeks.  I'm aiming to implement feature parity with the
...
> can you please use drivers/firewire/ if you want to start clean or
> aiming at replacing drivers/ieee1394/. Using "fw" as an abbreviation in
> the directory path is not really helpful.

Yes, that's probably a better idea.  Do you see a problem with using fw_* as a 
prefix in the code though?  I don't see anybody using that prefix, but Stefan 
pointed out to me that it's often used to abbreviate firmware too.

Kristian



From: Marcel Holtmann [email blocked]
Subject: Re: [PATCH 0/3] New firewire stack
Date:	Tue, 05 Dec 2006 16:30:50 +0100

Hi Kristian,

> >> I'm announcing an alternative firewire stack that I've been working on
> >> the last few weeks.  I'm aiming to implement feature parity with the
> ...
> > can you please use drivers/firewire/ if you want to start clean or
> > aiming at replacing drivers/ieee1394/. Using "fw" as an abbreviation in
> > the directory path is not really helpful.
> 
> Yes, that's probably a better idea.  Do you see a problem with using fw_* as a 
> prefix in the code though?  I don't see anybody using that prefix, but Stefan 
> pointed out to me that it's often used to abbreviate firmware too.

the only problem are public and exported interfaces and function. For
static code you can use whatever you want. I personally would go with
"ieee1394", because that is the official name for it. Otherwise go with
"firewire" if you wanna separate yourself from the previous stack.

Besides having "fw" for firmware it also is used in terms of firewall
and you don't wanna have that confusion.

Regards

Marcel


From: Alexey Dobriyan [email blocked]
Subject: Re: [PATCH 0/3] New firewire stack
Date:	Tue, 5 Dec 2006 21:49:21 +0300

On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote:
> I'm announcing an alternative firewire stack that I've been working on
> the last few weeks.

Is mainline firewire so hopeless, that you've decided to rewrite it?
Could you show some ugly places in it?

We can end up with two not quite working sets of firewire drivers your
way.



From: Stefan Richter [email blocked]-berlin.de>
Subject: Re: [PATCH 0/3] New firewire stack
Date:	Tue, 05 Dec 2006 20:53:03 +0100

Alexey Dobriyan wrote:
> On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote:
>> I'm announcing an alternative firewire stack that I've been working on
>> the last few weeks.
> 
> Is mainline firewire so hopeless, that you've decided to rewrite it?
> Could you show some ugly places in it?

Although that's for Kristian to answer (and much of the answer can
already be found in his posting), here are some ugly things.
http://bugzilla.kernel.org/buglist.cgi?product=Drivers&component=IEEE1394
&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO
Or look here first: http://bugzilla.kernel.org/show_bug.cgi?id=6070

There have been severe issues with the FireWire drivers during a certain
period, due to lack of care. That's partly a thing of the past, and I
definitely don't consider the mainline drivers hopeless. (Otherwise I
hadn't stepped in as maintainer.) But we still lack manpower for
bugfixing. Also, the bugs which are left now are the ones that are the
hardest to find and fix. Therefore I am glad that Kristian is back again
and is contributing some real work. (For those who don't know him, he
has worked on the drivers in the past, long before I did.)

> We can end up with two not quite working sets of firewire drivers your
> way.

As long as I will be interested in maintenance of the FireWire drivers,
I intend to help that either a successful switch to the new stack is put
into practice, or that Kristian's designs and implementation are copied
where they benefit the old stack. I'm not sure which way it will go; it
depends on (1) who contributes what and (2) the shape in which
mainline's FireWire stack will be in in 2007. Right now it lacks modularity.
-- 
Stefan Richter
-=====-=-==- ==-- --=-=
http://arcgraph.de/sr/



From: Kristian Høgsberg [email blocked]
Subject: Re: [PATCH 0/3] New firewire stack
Date:	Tue, 05 Dec 2006 18:21:44 -0500

Alexey Dobriyan wrote:
> On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote:
>> I'm announcing an alternative firewire stack that I've been working on 
>> the last few weeks.
> 
> Is mainline firewire so hopeless, that you've decided to rewrite it? Could
> you show some ugly places in it?

Yes.  I'm not doing this lightheartedly.  It's a lot of work and it will
introduce regressions and instability for a little while.

My main point about ohci1394 (the old stacks PCI driver) is, that if you
really want to fix the issues with this driver, you have to shuffle the code
around so much that you'll introduce as many regressions as a clean rewrite.
The big problems in the ohci1394 drivers is the irq_handler, bus reset
handling and config rom handling.  These are some of the strong points of
fw-ohci.c:

  - Rock solid handling of generations and node IDs around bus resets.
    The only way to handle this atomically is to pass the generation
    count along all the way to the transmit function in the low-level
    driver.  The linux1394 low level driver API is broken in this
    respect.

  - Better handling of self ID receive and possible recursive bus
    resets.  Successive bus resets could overwrite the self ID DMA
    buffer, while we read out the contents.  The OHCI specification
    recommends a method similiar to linux/seqlock.h for reading out
    self IDs, to ensure we get a consistent result.

  - Much simpler bus reset handling; we only subscribe to the
    selfIDComplete interrupt and don't use the troublesome busReset
    interrupt.  Rely on async transmit context to not send data while
    busReset event bit is set.

  - Atomic updates of config rom contents as specified in section 5.5.6
    in the OHCI specification. The contents of the ConfigROMheader,
    BusOptions and ConfigROMmap registers are updated atomically by the
    controller after a reset.

The OHCI specification describes a number of the techniques to ensure race
free operation for the above cases, but the ohci1394 driver generally doesn't
use any of these.  If you want to see ugly code look at the ohci1394 irq
handler.  Much of the uglyness comes from trying to handle the busReset
interrupt, so that the mid-level linux1394 stack can fail I/O while the bus
reset takes place.  Now, OHCI hardware already reliably fails I/O during bus
reset, so there is no need to complicate the core stack with this extra state,
and the OHCI driver becomes much simpler and more reliable, since we now just
need to know when a bus reset has successfully completed.

Fixing this problem requires significant changes to the ohci1394 driver and
the mid-level stack, and will destabilize things until we've figure out how to
work around the odd flaky device out there.  Similar problems exists related
to sending packets without bus reset races, updating the config rom, and
reporting self ID packets and all require significant changes to the core
stack and ohci1394.  All taken together the scale tips towards a rewrite.

Another point is the various streaming drivers.  There used to be 5 different
userspace streaming APIs in the linux1394: raw1394, video1394, amdtp, dv1394
and rawiso.  Recently, amdtp (audio streaming) has been removed, since with
the rawiso interface, this can be done in userspace.  However the remaining 4
interfaces have slightly disjoint feature sets and can't really be phased out.
  In the long run, supporting 4 different interfaces that does almost the same
thing isn't feasible.  The streaming interface in my new stack (only
transmission implemented at this point) can replace all of these interfaces.

Finally, some parts aren't actually rewritten, just ported over and
refactored.  This is the case for the SBP-2 driver.  Functionally, my
fw-sbp2.c is identical to sbp2.c in the current stack, but I've changed it to
work with the new interfaces and cleaned up some of the redundancy.

> We can end up with two not quite working sets of firewire drivers your way.
> 
You can patch up the current stack to be less flaky, and Stefan has been doing
a great job at that lately, but it's still fundamentally broken in the ways
described above.

While my stack may less stable for the first couple of weeks, these are
transient issues, such as, say, lack of big endian testing, that are easily
fixed.  In the long run this new stack is much more maintainable and has a
bigger potential for stability.

Kristian



From: Ben Collins [email blocked]
Subject: Re: [PATCH 0/3] New firewire stack
Date:	Wed, 06 Dec 2006 00:35:49 -0500

On Tue, 2006-12-05 at 18:21 -0500, Kristian Høgsberg wrote:
> Alexey Dobriyan wrote:
> > On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote:
> >> I'm announcing an alternative firewire stack that I've been working on 
> >> the last few weeks.
> > 
> > Is mainline firewire so hopeless, that you've decided to rewrite it? Could
> > you show some ugly places in it?
> 
> Yes.  I'm not doing this lightheartedly.  It's a lot of work and it will
> introduce regressions and instability for a little while.
> 
> My main point about ohci1394 (the old stacks PCI driver) is, that if you
> really want to fix the issues with this driver, you have to shuffle the code
> around so much that you'll introduce as many regressions as a clean rewrite.
> The big problems in the ohci1394 drivers is the irq_handler, bus reset
> handling and config rom handling.  These are some of the strong points of
> fw-ohci.c:

My main concern is that when I picked up ieee1394 maint myself, it was
because it was not big-endian or 64-bit friendly. I spent the better
part of 3 months getting this right on PPC and UltraSPARC. Not because
it's hard to fix these issues, but because the hardware is not well
defined for a lot of these cases (I know you've seen the ohci1394 code
to handle endianness).

So while I can understand that ieee1394 doesn't have much man power
right now, and that there are some hard to find bugs in the current
tree, I can't see how starting from scratch alleviates this.

The tree is years old, and a lot of work has been put into it (lots of
my work, I'll admit I'm being a little protective). I'm not sure that
"replacing" it is wise, or even needed. Fork it, clean it up, but
rewriting just doesn't make sense.

Granted, this is your time, and you can spend it how you want, I just
don't want to see the ieee1394 stack take a step backwards in the hopes
that it will be better a year down the road.



From: Stefan Richter [email blocked]-berlin.de>
Subject: Re: [PATCH 0/3] New firewire stack
Date:	Wed, 06 Dec 2006 09:56:49 +0100

(Adding Cc: linux1394-devel)

Ben Collins wrote at linux-kernel:
> On Tue, 2006-12-05 at 18:21 -0500, Kristian Høgsberg wrote:
>> Alexey Dobriyan wrote:
>>> On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote:
>>>> I'm announcing an alternative firewire stack that I've been working on 
>>>> the last few weeks.
>>> Is mainline firewire so hopeless, that you've decided to rewrite it? Could
>>> you show some ugly places in it?
>> Yes.  I'm not doing this lightheartedly.  It's a lot of work and it will
>> introduce regressions and instability for a little while.
>>
>> My main point about ohci1394 (the old stacks PCI driver) is, that if you
>> really want to fix the issues with this driver, you have to shuffle the code
>> around so much that you'll introduce as many regressions as a clean rewrite.
>> The big problems in the ohci1394 drivers is the irq_handler, bus reset
>> handling and config rom handling.  These are some of the strong points of
>> fw-ohci.c:
> 
> My main concern is that when I picked up ieee1394 maint myself, it was
> because it was not big-endian or 64-bit friendly.

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.)

> I spent the better
> part of 3 months getting this right on PPC and UltraSPARC. Not because
> it's hard to fix these issues, but because the hardware is not well
> defined for a lot of these cases (I know you've seen the ohci1394 code
> to handle endianness).
> 
> So while I can understand that ieee1394 doesn't have much man power
> right now, and that there are some hard to find bugs in the current
> tree, I can't see how starting from scratch alleviates this.
> 
> The tree is years old, and a lot of work has been put into it (lots of
> my work, I'll admit I'm being a little protective). I'm not sure that
> "replacing" it is wise, or even needed. Fork it, clean it up, but
> rewriting just doesn't make sense.
> 
> Granted, this is your time, and you can spend it how you want, I just
> don't want to see the ieee1394 stack take a step backwards in the hopes
> that it will be better a year down the road.

No matter in which way we will put Kristian's work to use, regressions
must not happen --- beyond the measure that unintentionally happens when
bugs get fixed. Mainline's FireWire stack lost a lot of trust at
end-users and application developers because of periods of sometimes
very visible regressions.
-- 
Stefan Richter
-=====-=-==- ==-- --==-
http://arcgraph.de/sr/



From: "Alexander Neundorf" [email blocked]
Subject: Re:  Re: [PATCH 0/3] New firewire stack
Date:	Wed, 06 Dec 2006 12:40:36 +0100

Hi,

Von: Stefan Richter [email blocked]-berlin.de>

...
> bugs get fixed. Mainline's FireWire stack lost a lot of trust at
> end-users and application developers because of periods of sometimes
> very visible regressions.

For us it's working well, with no major problems (there was a problem with 
SMP kernels and the arm mapping, but my kernel is not recent and I didn't 
find the time yet to update to current versions, so I could not report the 
bug). We have customers and it works for them.

OTOH I heard from some people who wanted to use the 1394 stack for embedded 
devices without PCI and they didn't succeed to add support for their 
selected chipset. 

Bye
Alex

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer



From: Stefan Richter [email blocked]Be
Subject: Re: [PATCH 0/3] New firewire stack
Date:	Wed, 06 Dec 2006 13:38:36 +0100

Alexander Neundorf wrote:
> Von: Stefan Richter [email blocked]-berlin.de>
>> Mainline's FireWire stack lost a lot of trust
...
> For us it's working well, with no major problems (there was a problem with
> SMP kernels and the arm mapping, but my kernel is not recent and I didn't
> find the time yet to update to current versions, so I could not report the
> bug). We have customers and it works for them.

Perhaps the fix which was released in 2.6.19 is relevant. As always, you
can get it as part of my patchkits too which are currently available for
2.6.16.x and 2.6.18(.x). I had also patchkits for 2.6.1[457].x which I
could revive on request. If need be, I would also try to assist
distributors to identify and backport specific fixes. I am currently
wondering if I should take the time to pick out a collection of fixes
for Adrian's 2.6.16.x series.

> OTOH I heard from some people who wanted to use the 1394 stack for embedded
> devices without PCI and they didn't succeed to add support for their selected
> chipset. 

The ieee1394 core currently dependends on the PCI subsystem for no
obvious reason. The fix probably consists mostly of a rather trivial
conversion from the PCI DMA mapping API to generic DMA mapping. I
actually intend to do this conversion RSN.

Another question is whether the stack-internal APIs are really fit for
non-OHCI chips. There is an unfinished low-level driver for GP2Lynx
which worked to some degree at some point, but other than that I don't
remember positive or negative reports in this department. Maybe proper
documentation of the stack-internal APIs would already help embedded
developers a lot. Furthermore, there may be question marks WRT
interaction of the FireWire stack with architecture specific kernel code.

But back to the subject matter: Clearly, Kristian concentrates on
PCI/OHCI-1394 hardware at the moment. If embedded developers have
specific requirements on the FireWire stack's design, they should IMO
contribute with a list of requirements or maybe even with patches.
-- 
Stefan Richter
-=====-=-==- ==-- --==-
http://arcgraph.de/sr/



From: Kristian Høgsberg [email blocked]
Subject: Re: [PATCH 0/3] New firewire stack
Date:	Wed, 06 Dec 2006 16:21:15 -0500

Stefan Richter wrote:
...
> Another question is whether the stack-internal APIs are really fit for
> non-OHCI chips. There is an unfinished low-level driver for GP2Lynx
> which worked to some degree at some point, but other than that I don't
> remember positive or negative reports in this department. Maybe proper
> documentation of the stack-internal APIs would already help embedded
> developers a lot. Furthermore, there may be question marks WRT
> interaction of the FireWire stack with architecture specific kernel code.

I think some of the problems with the current stack come from the fact that it 
was originally written (by Andreas Bombe) for the PCILynx chipset, in other 
words, *not* for the OHCI chipset.  The PCILynx chipset is a much lower level 
chipset, it offloads much more to software.  For example, each self ID is 
received as an individual packet, where the OHCI chipset receives these into a 
special buffer and notifies software when it has received a consistent set of 
packets.  The current stack has a callback for the host controller driver to 
call once the bus reset phase starts, a callback for each received self ID and 
a callback to indicate the end of the bus reset phase.

In the new stack, the controller/core interface is more suited for the OHCI 
controller.  The stack doens't go into a bus reset state, and all self IDs are 
reported as an atomic event.  This makes the upper layers much simpler, suits 
the OHCI controller better, and should only require a few lines extra code in 
a PCILynx driver to buffer up the self IDs.  And it's arguably better to have 
the PCILynx driver do this than have the OHCI controller split up and 
otherwise atomic event.

> But back to the subject matter: Clearly, Kristian concentrates on
> PCI/OHCI-1394 hardware at the moment. If embedded developers have
> specific requirements on the FireWire stack's design, they should IMO
> contribute with a list of requirements or maybe even with patches.

It's true that I'm developing for PCI+OHCI, but I've kept the controller/core 
stack split that the old stack has, nothing outside the OHCI driver depends on 
PCI (I'm using the generic DMA API).  I've shifted the abstraction level up a 
bit for the controller interface, which makes sense in general, but also since 
this is what every desktop or laptop out there has.  That said, I don't think 
anything in the stack design will break for embedded/non-OHCI chipsets.

cheers,
Kristian


From: Ben Collins [email blocked]
Subject: Re: [PATCH 0/3] New firewire stack
Date:	Wed, 06 Dec 2006 09:49:06 -0500

On Wed, 2006-12-06 at 09:56 +0100, Stefan Richter wrote:
> (Adding Cc: linux1394-devel)
> 
> Ben Collins wrote at linux-kernel:
> > On Tue, 2006-12-05 at 18:21 -0500, Kristian Høgsberg wrote:
> >> Alexey Dobriyan wrote:
> >>> On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote:
> >>>> I'm announcing an alternative firewire stack that I've been working on 
> >>>> the last few weeks.
> >>> Is mainline firewire so hopeless, that you've decided to rewrite it? Could
> >>> you show some ugly places in it?
> >> Yes.  I'm not doing this lightheartedly.  It's a lot of work and it will
> >> introduce regressions and instability for a little while.
> >>
> >> My main point about ohci1394 (the old stacks PCI driver) is, that if you
> >> really want to fix the issues with this driver, you have to shuffle the code
> >> around so much that you'll introduce as many regressions as a clean rewrite.
> >> The big problems in the ohci1394 drivers is the irq_handler, bus reset
> >> handling and config rom handling.  These are some of the strong points of
> >> fw-ohci.c:
> > 
> > My main concern is that when I picked up ieee1394 maint myself, it was
> > because it was not big-endian or 64-bit friendly.
> 
> 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.



From: Kristian Høgsberg [email blocked]
Subject: Re: [PATCH 0/3] New firewire stack
Date:	Wed, 06 Dec 2006 19:31:25 -0500

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

• Archive of above thread