Kristian Høgsberg wrote:
> Here's a new set of patches for the new firewire stack.
...
> It is still work in progress, but at least now it should work across
> all architectures and endianesses.
Committed to linux1394-2.6.git.
BTW, I prepended "ieee1394:" to the titles of most of the commits to
t
> > Well... I don't think eth1394 was ever used much and it's
> not something
> > I plan to port over.
>
> It is used, even though it is not very robust because it is
> not actively
> maintained (yet). If your stack will shape up to become a potential
> replacement of mainline's stack, I'm sure
I wrote:
> Because of the potentially much larger
> repeater delays of 1394b PHYs, the only suitable method to determine a
> working least gap count of such setups is round-trip delay measurement
> with ping packets. But a good compromise would be to run table-based gap
> count optimization for 139
Kristian Høgsberg wrote:
> And as for gap count optimization, I just added that to my git repo.
What can I say.
...
> and the optimization is definitely noticable. This is a setup
> where the box and the disk are both connected to a hub so the max hops
> is 2, so we're using gap count 4:
...
>
I wrote:
> Kristian Høgsberg wrote:
[eth1394]
>> The only thing I've ever heard people say about it is that it's
>> annoying because it screws up their network interface ordering.
>
> Yeah, the same way hot-pluggable SCSI devices screw up device naming of
(I forgot to complete the post.) ... fixe
Stefan Richter wrote:
...
And Windows Vista will drop the IP over 1394 functionality,
which is another data point about how widely used this standard is.
If we cared what Windows supports or does not support, we would have gap
count optimization by now, but no support of IEEE 1394b-2002.
Yeah
Kristian Høgsberg wrote:
> Stefan Richter wrote:
>> Actually there are also eth1394 and pcilynx to be pulled over. Eth1394
>> should be quite easy to do for anybody after iso reception is settled in
>> your stack. Pcilynx could follow depending on developer interest. It's
>> increasingly rare hardw
Pieter Palmers wrote:
Kristian Høgsberg wrote:
Hi,
Here's a new set of patches for the new firewire stack. The changes
since the last set of patches address the issues that were raised on
the list and can be reviewed in detail here:
.. for some reason I didn't get patch 3/4 and 4/4 on the linu
Stefan Richter wrote:
Kristian Høgsberg wrote:
...
to sum up the changes:
- Got rid of bitfields.
- Tested on ppc, ppc64 x86-64 and x86.
- ioctl interface tested on 32-bit userspace / 64-bit kernels.
- ASCIIfied sources.
- Incorporated Jeff Garziks comments.
- Updated to work with th
Kristian Høgsberg wrote:
Hi,
Here's a new set of patches for the new firewire stack. The changes
since the last set of patches address the issues that were raised on
the list and can be reviewed in detail here:
.. for some reason I didn't get patch 3/4 and 4/4 on the linux1394-devel
list, so I
Kristian Høgsberg wrote:
...
> to sum up the changes:
>
> - Got rid of bitfields.
>
> - Tested on ppc, ppc64 x86-64 and x86.
>
> - ioctl interface tested on 32-bit userspace / 64-bit kernels.
>
> - ASCIIfied sources.
>
> - Incorporated Jeff Garziks comments.
>
> - Updated to work with t
11 matches
Mail list logo
