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 the new workqueue API changes.
- Moved subsystem to drivers/firewire from drivers/fw.
plus a number of bug fixes.
Congrats. WRT the 1st, 3rd, and 5th item you are now ahead of mainline's
stack. :-)
Hehe, yeah, I saw the big FIXME in raw1394.c about compat_ioctl. But
raw1394.c shouldn't be that hard to fix, the ioctl structs are using
explicitly sized types and u64 for userspace pointers, the one problem I see
is that some of the 64-bit fields aren't 64-bit aligend.
As mentioned last time, the stack still lacks isochronous receive
functionality to be on par with the old stack, feature-wise. This is
the one remaining piece of feature work kernel-side. When that is
done, I have a couple of TODO items in user space:
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. The only thing I've ever heard people say about it is that it's
annoying because it screws up their network interface ordering. And Windows
Vista will drop the IP over 1394 functionality, which is another data point
about how widely used this standard is.
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. 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.
- 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.
cheers,
Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
