> Jonathan Woithe wrote: > >> Olaf Hering wrote: > >>> NACK. > >>> Upgrade the current drivers/ieee1394/ with the new code, and keep all > >>> existing module names. > [...] > > However, as a compromise how about renaming the existing stack's modules and > > then reusing the existing names for the new stack? Messy I know, but this > > way both stacks would still be available without recompilation for those who > > needed them and the sbp2-as-root dilemma raised by Olaf would also be > > covered. > > I.e. new modules: > ieee1394 (was fw-core) > ohci1394 (was fw-ohci) > :
> old modules, for example: > ieee1394-old > ohci1394-old > : > > Looks... weird. > > On the other hand, a 1394 module compilation cycle in order to do the > fallback is not such a huge issue, except that it requires the person to > be able to compile modules. That's probably the main issue. True on all counts. I guess it's a question of whether the lack of an easy fallback path will significantly reduce the number of testers. I don't have enough of a feel to answer that. > eth1394 (to be done) --- but that's a bad name anyway, it > implements IP over 1394, not Ethernet So, when eth1394 is ported the name should be something like fw-ip, at least if we are to remain consistent with the other 3 module names. > > Oh yes, it would be nice to have working PCILynx support again (although I > > acknowledge it's unlikely to happen). Some of us do have these cards > > installed for sniffing purposes (using nosy) but it would be nice to be able > > to use them with libraw1394 as well. It would for example save me having to > > swap cards depending on what I needed to do (I have insufficient PCI slots > > to have both the PCILynx and OHCI cards installed simultaneously). > > But then, what is the actual utility of pcilynx? (I mean the current > driver, not the card or a future driver.) Last time I checked, sbp2 was > broken without OHCI's physical DMA, and AFAIK raw1394's newer iso API > and video1394 and dv1394 don't work with pcilynx either. It certainly doesn't support the raw1394 API so its current usefulness is extremely limited. > Porting pcilynx to the new low-level API would be quite resource > demanding --- seen in relation to which resources we have, what the > existing pcilynx driver's state of affairs is, and how rare the hardware > is. (For those who have the hardware, the stand-alone Nosy is > undoubtedly the killer application, not pcilynx.) Precisely. As I said, I've probably got a corner case and it's certainly not worth the effort just for that. It would be nice though. You're right about nosy; so long as nosy (which is independent of the firewire stack) keeps working I'll be happy. :) Regards jonathan - 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/