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
> > 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
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
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
this
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
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.) ...
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.
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
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
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
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
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
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 the new
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
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
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
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 hardware and
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.
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.) ... fixed SCSI
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:
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 1394a
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:
http://gitweb.freedesktop.org/?p=users/krh/juju.git
but to sum up the changes:
- Got rid of bitfields.
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:
http://gitweb.freedesktop.org/?p=users/krh/juju.git
but to sum up the changes:
- Got rid of bitfields.
24 matches
Mail list logo
