Re: [PATCH 0/4] New firewire stack - updated patches

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 the few old machines which have it can be
cheaply upgraded to OHCI (which performs better for SBP-2 anyway).

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 _someone_ will do the port.

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

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'm not planning to port the pcilynx driver either. I think it's a sore
point for the old stack as it is - nobody uses it or tests it and it's
continously bit-rotting. So I'd rather not support it.

Here I agree.

However, it can
perform as well as an OHCI card for SBP-2. If you set up a
self-modifying DMA program it can read and write system memory without
CPU intervention too.

OK, I didn't know that although I suspected something like this might be
possible. Of course this remains a potential feature as long as there is
no manpower to actually implement it. (Nor is there a userbase to speak
of to appreciate such an effort.)

- Make a libraw1394 compatibility library

Consider using libraw1394 right from the start of this porting project.
If there is only one libraw1394 (which works with raw1394 and with
fw-device-cdev), enthusiasts might have an easier time to test your
stack.

Hmm, maybe. There is going to be completely different code paths for
each API entry point and not a lot of code sharing. But there is
definitely some merit to only having one library, and if it could detect
the kernel interface automatically and just work that would be even better.

Certainly, there won't be any benefit WRT code sharing in the library.
It's more about deployment.
--
Stefan Richter
-=====-=-==- ==-- =-=--
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: 2.6.17-rc5-mm1
    ... Jan Beulich was the one who noticed the stack overflow. ... be "check for overflows which would kill a 4k stack kernel". ... Random Oops on early boot. ... # ACPI Support ...
    (Linux-Kernel)
  • Re: 2.6.17-rc5-mm1
    ... message), i.e., 2.6.17-rc5-mm3 with Ingo's lockdep-combo patch added. ... I would expect that to increase stack usage... ... # Firmware Drivers ... # ACPI Support ...
    (Linux-Kernel)
  • Re: 2.6.17-rc5-mm1
    ... 2.6.17-rc5-mm3 with 4K stack crashes, the stack seems to be corrupted. ... The kernel does this in a lot of places, ... # Firmware Drivers ... # ACPI Support ...
    (Linux-Kernel)
  • RE: System.AccessViolationException in .NET 2.0 application
    ... Based on the call stack, there is an AV exception in the ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.general)
  • Re: ipw2100 wireless driver
    ... support wpa yet. ... We're also using the stack for the ipw2200 project (which we hope to get another ... fragments to the driver for transmission. ... handlers for exposing that information. ...
    (Linux-Kernel)