Re: [git pull] New firewire stack (updated)
Christoph Hellwig wrote: > ACK from me. I still have some comments but none of them is a merge > blocker. I put one small fix that Kristian sent on hold (const char * vs char * for shostt->proc_name) to let a related patch go to scsi-misc first. So this open item is my fault, not his. :-) -- Stefan Richter -=-=-=== -=-= -=-=- http://arcgraph.de/sr/ - 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/
Re: [git pull] New firewire stack (updated)
Christoph Hellwig wrote: > On Thu, May 10, 2007 at 07:26:56PM +0200, Stefan Richter wrote: >> - The drivers still live in drivers/firewire/, i.e. have not been put >> into mainline's drivers/ieee1394/. > > I don't quite like that. Then again git handles renames pretty nicely > and I hope we'll just shift the new drivers in place when the old code > goes away completely to give people a seamless migration. There were some comments in this and past reviews pro and contra the directory split. For me, it was easier to deal with patch handling that way since the stack went into -mm, but once the stack is in Linus' tree, my work will probably be easier anyway. -- Stefan Richter -=-=-=== -=-= -=-=- http://arcgraph.de/sr/ - 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/
Re: [git pull] New firewire stack (updated)
On Thu, May 10, 2007 at 06:38:50PM +0100, Christoph Hellwig wrote: > On Thu, May 10, 2007 at 07:26:56PM +0200, Stefan Richter wrote: > > Linus, please pull from the juju branch at > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git > > juju > > > > ACK from me. I still have some comments but none of them is a merge > blocker. > > > What did _not_ change: > > > > - The drivers are still named fw-core, fw-ohci, fw-sbp2 (but they > > feature conditional aliases sbp2 and ohci1394 now). Adrian > > suggested the prefix firewire- instead of fw-. > > > > - The drivers still live in drivers/firewire/, i.e. have not been put > > into mainline's drivers/ieee1394/. > > I don't quite like that. Then again git handles renames pretty nicely > and I hope we'll just shift the new drivers in place when the old code > goes away completely to give people a seamless migration. For users it shouldn't matter where the code is located in the kernel sources (and "firewire" is IMHO for many people more meaningful than "ieee1394"). cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: [git pull] New firewire stack (updated)
On Thu, May 10, 2007 at 07:26:56PM +0200, Stefan Richter wrote: > Linus, please pull from the juju branch at > > git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git > juju > ACK from me. I still have some comments but none of them is a merge blocker. > What did _not_ change: > > - The drivers are still named fw-core, fw-ohci, fw-sbp2 (but they > feature conditional aliases sbp2 and ohci1394 now). Adrian > suggested the prefix firewire- instead of fw-. > > - The drivers still live in drivers/firewire/, i.e. have not been put > into mainline's drivers/ieee1394/. I don't quite like that. Then again git handles renames pretty nicely and I hope we'll just shift the new drivers in place when the old code goes away completely to give people a seamless migration. - 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/
[git pull] New firewire stack (updated)
Linus, please pull from the juju branch at git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git juju to receive the new, alternative IEEE 1394 subsystem ( --- unless you consider it too close to the end of the merge window now or have other reservations...). Many thanks to all who reviewed the submission from May 1st. Your work is of great help and is very much appreciated. What changed since last submission: Ivo van Doorn (1): CRC ITU-T V.41 Kristian Høgsberg (14): firewire: Use lib/ implementation of CRC ITU-T. firewire: Clean up comment style. firewire: Convert card_rwsem to a regular mutex. firewire: Coding style cleanup: no spaces after function names. firewire: Uppercase most macro names. firewire: Use linux/*.h instead of asm/*.h header files. firewire: Break out shared IEEE1394 constant to separate header file. firewire: Add to fw-core-y instead of assigning fw-core-objs in Makefile. firewire: Allocate scsi_host up front and allocate the sbp2_device as hostdata. firewire: Handle the last few DMA mapping error cases. firewire: Return SCSI_MLQUEUE_HOST_BUSY for out of memory cases in queuecommand. firewire: Drop single buffer request support. firewire: Always use parens with sizeof. firewire: Convert OHCI driver to use standard goto unwinding for error handling. Kristian Høgsberg, Stefan Richter (1): firewire: Add a comment to describe why we split the sg list. Olaf Hering (1): firewire: Provide module aliase for backwards compatibility. What did _not_ change: - The drivers are still named fw-core, fw-ohci, fw-sbp2 (but they feature conditional aliases sbp2 and ohci1394 now). Adrian suggested the prefix firewire- instead of fw-. - The drivers still live in drivers/firewire/, i.e. have not been put into mainline's drivers/ieee1394/. As mentioned in the previous submission, the main item that is still to do regarding the new codebase is to bring over IP over 1394, currently known as eth1394. But the biggest task is certainly to come up with a transition schedule for the removal of the existing stack. IMO, exposure of the new stack at this time will enable the community of IEEE 1394 developers and users to provide us with the necessary feedback to tackle that schedule. To rehash the reasons to undertake this transition: + Considerably leaner codebase, + cleaned-up and improved in-stack APIs (with the side effect of getting rid of a bunch of old bugs), + consolidation of the currently four userspace ABIs into one improved ABI (which is already supported by the two FireWire low-level libraries libraw1394 and libdc1394), + improved host security and device security. As noted, linux1394-2.6.git's juju branch is based on 2.6.21-rc3. I can rebase it onto 2.6.21 or current git if you wish. The juju branch contains a linear series of now 138 commits: Adrian Bunk (1) Andrew Morton (4) Ivo van Doorn (1) Kristian Høgsberg (106) Marc Butler (1) Olaf Hering (1) Randy Dunlap (1) Stefan Richter (22) Thomas Gleixner (1) drivers/Makefile |1 + drivers/firewire/Kconfig | 61 ++ drivers/firewire/Makefile | 10 + drivers/firewire/fw-card.c | 560 +++ drivers/firewire/fw-cdev.c | 961 ++ drivers/firewire/fw-device.c | 813 +++ drivers/firewire/fw-device.h | 146 +++ drivers/firewire/fw-iso.c | 163 +++ drivers/firewire/fw-ohci.c | 1943 drivers/firewire/fw-ohci.h | 153 +++ drivers/firewire/fw-sbp2.c | 1147 + drivers/firewire/fw-topology.c | 537 ++ drivers/firewire/fw-topology.h | 92 ++ drivers/firewire/fw-transaction.c | 910 + drivers/firewire/fw-transaction.h | 458 + drivers/ieee1394/Kconfig |2 + include/linux/crc-itu-t.h | 28 + include/linux/firewire-cdev.h | 229 + include/linux/firewire-constants.h | 67 ++ lib/Kconfig|8 + lib/Makefile |1 + lib/crc-itu-t.c| 69 ++ 22 files changed, 8359 insertions(+), 0 deletions(-) create mode 100644 drivers/firewire/Kconfig create mode 100644 drivers/firewire/Makefile create mode 100644 drivers/firewire/fw-card.c create mode 100644 drivers/firewire/fw-cdev.c create mode 100644 drivers/firewire/fw-device.c create mode 100644 drivers/firewire/fw-device.h create mode 100644 drivers/firewire/fw-iso.c create mode 100644 drivers/firewire/fw-ohci.c create mode 100644 drivers/firewire/fw-ohci.h create mode 100644 drivers/firewire/fw-sbp2.c create mode 100644 drivers/firewire/fw-topology.c create mode 100644 drivers/firewire/fw-topology.h create mode 100644 drivers/firewire/fw-transaction.c create mode 100644
[git pull] New firewire stack (updated)
Linus, please pull from the juju branch at git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git juju to receive the new, alternative IEEE 1394 subsystem ( --- unless you consider it too close to the end of the merge window now or have other reservations...). Many thanks to all who reviewed the submission from May 1st. Your work is of great help and is very much appreciated. What changed since last submission: Ivo van Doorn (1): CRC ITU-T V.41 Kristian Høgsberg (14): firewire: Use lib/ implementation of CRC ITU-T. firewire: Clean up comment style. firewire: Convert card_rwsem to a regular mutex. firewire: Coding style cleanup: no spaces after function names. firewire: Uppercase most macro names. firewire: Use linux/*.h instead of asm/*.h header files. firewire: Break out shared IEEE1394 constant to separate header file. firewire: Add to fw-core-y instead of assigning fw-core-objs in Makefile. firewire: Allocate scsi_host up front and allocate the sbp2_device as hostdata. firewire: Handle the last few DMA mapping error cases. firewire: Return SCSI_MLQUEUE_HOST_BUSY for out of memory cases in queuecommand. firewire: Drop single buffer request support. firewire: Always use parens with sizeof. firewire: Convert OHCI driver to use standard goto unwinding for error handling. Kristian Høgsberg, Stefan Richter (1): firewire: Add a comment to describe why we split the sg list. Olaf Hering (1): firewire: Provide module aliase for backwards compatibility. What did _not_ change: - The drivers are still named fw-core, fw-ohci, fw-sbp2 (but they feature conditional aliases sbp2 and ohci1394 now). Adrian suggested the prefix firewire- instead of fw-. - The drivers still live in drivers/firewire/, i.e. have not been put into mainline's drivers/ieee1394/. As mentioned in the previous submission, the main item that is still to do regarding the new codebase is to bring over IP over 1394, currently known as eth1394. But the biggest task is certainly to come up with a transition schedule for the removal of the existing stack. IMO, exposure of the new stack at this time will enable the community of IEEE 1394 developers and users to provide us with the necessary feedback to tackle that schedule. To rehash the reasons to undertake this transition: + Considerably leaner codebase, + cleaned-up and improved in-stack APIs (with the side effect of getting rid of a bunch of old bugs), + consolidation of the currently four userspace ABIs into one improved ABI (which is already supported by the two FireWire low-level libraries libraw1394 and libdc1394), + improved host security and device security. As noted, linux1394-2.6.git's juju branch is based on 2.6.21-rc3. I can rebase it onto 2.6.21 or current git if you wish. The juju branch contains a linear series of now 138 commits: Adrian Bunk (1) Andrew Morton (4) Ivo van Doorn (1) Kristian Høgsberg (106) Marc Butler (1) Olaf Hering (1) Randy Dunlap (1) Stefan Richter (22) Thomas Gleixner (1) drivers/Makefile |1 + drivers/firewire/Kconfig | 61 ++ drivers/firewire/Makefile | 10 + drivers/firewire/fw-card.c | 560 +++ drivers/firewire/fw-cdev.c | 961 ++ drivers/firewire/fw-device.c | 813 +++ drivers/firewire/fw-device.h | 146 +++ drivers/firewire/fw-iso.c | 163 +++ drivers/firewire/fw-ohci.c | 1943 drivers/firewire/fw-ohci.h | 153 +++ drivers/firewire/fw-sbp2.c | 1147 + drivers/firewire/fw-topology.c | 537 ++ drivers/firewire/fw-topology.h | 92 ++ drivers/firewire/fw-transaction.c | 910 + drivers/firewire/fw-transaction.h | 458 + drivers/ieee1394/Kconfig |2 + include/linux/crc-itu-t.h | 28 + include/linux/firewire-cdev.h | 229 + include/linux/firewire-constants.h | 67 ++ lib/Kconfig|8 + lib/Makefile |1 + lib/crc-itu-t.c| 69 ++ 22 files changed, 8359 insertions(+), 0 deletions(-) create mode 100644 drivers/firewire/Kconfig create mode 100644 drivers/firewire/Makefile create mode 100644 drivers/firewire/fw-card.c create mode 100644 drivers/firewire/fw-cdev.c create mode 100644 drivers/firewire/fw-device.c create mode 100644 drivers/firewire/fw-device.h create mode 100644 drivers/firewire/fw-iso.c create mode 100644 drivers/firewire/fw-ohci.c create mode 100644 drivers/firewire/fw-ohci.h create mode 100644 drivers/firewire/fw-sbp2.c create mode 100644 drivers/firewire/fw-topology.c create mode 100644 drivers/firewire/fw-topology.h create mode 100644 drivers/firewire/fw-transaction.c create mode 100644
Re: [git pull] New firewire stack (updated)
On Thu, May 10, 2007 at 07:26:56PM +0200, Stefan Richter wrote: Linus, please pull from the juju branch at git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git juju ACK from me. I still have some comments but none of them is a merge blocker. What did _not_ change: - The drivers are still named fw-core, fw-ohci, fw-sbp2 (but they feature conditional aliases sbp2 and ohci1394 now). Adrian suggested the prefix firewire- instead of fw-. - The drivers still live in drivers/firewire/, i.e. have not been put into mainline's drivers/ieee1394/. I don't quite like that. Then again git handles renames pretty nicely and I hope we'll just shift the new drivers in place when the old code goes away completely to give people a seamless migration. - 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/
Re: [git pull] New firewire stack (updated)
On Thu, May 10, 2007 at 06:38:50PM +0100, Christoph Hellwig wrote: On Thu, May 10, 2007 at 07:26:56PM +0200, Stefan Richter wrote: Linus, please pull from the juju branch at git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git juju ACK from me. I still have some comments but none of them is a merge blocker. What did _not_ change: - The drivers are still named fw-core, fw-ohci, fw-sbp2 (but they feature conditional aliases sbp2 and ohci1394 now). Adrian suggested the prefix firewire- instead of fw-. - The drivers still live in drivers/firewire/, i.e. have not been put into mainline's drivers/ieee1394/. I don't quite like that. Then again git handles renames pretty nicely and I hope we'll just shift the new drivers in place when the old code goes away completely to give people a seamless migration. For users it shouldn't matter where the code is located in the kernel sources (and firewire is IMHO for many people more meaningful than ieee1394). cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: [git pull] New firewire stack (updated)
Christoph Hellwig wrote: On Thu, May 10, 2007 at 07:26:56PM +0200, Stefan Richter wrote: - The drivers still live in drivers/firewire/, i.e. have not been put into mainline's drivers/ieee1394/. I don't quite like that. Then again git handles renames pretty nicely and I hope we'll just shift the new drivers in place when the old code goes away completely to give people a seamless migration. There were some comments in this and past reviews pro and contra the directory split. For me, it was easier to deal with patch handling that way since the stack went into -mm, but once the stack is in Linus' tree, my work will probably be easier anyway. -- Stefan Richter -=-=-=== -=-= -=-=- http://arcgraph.de/sr/ - 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/
Re: [git pull] New firewire stack (updated)
Christoph Hellwig wrote: ACK from me. I still have some comments but none of them is a merge blocker. I put one small fix that Kristian sent on hold (const char * vs char * for shostt-proc_name) to let a related patch go to scsi-misc first. So this open item is my fault, not his. :-) -- Stefan Richter -=-=-=== -=-= -=-=- http://arcgraph.de/sr/ - 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/
Re: [git pull] New firewire stack
Olaf Hering wrote: On Thu, May 03, Olaf Hering wrote: On Thu, May 03, Stefan Richter wrote: ieee1394-old Noone will seriously ship two firewire stacks, so that cant be the issue (for distributors). Once there is a way to easily switch between kernel releases, I'm ok with whatever module names you pick. This patch loads fw-sbp2 if sbp2 is still in the config file. So one can go back and forth between releases without worry about the root filesystem drivers. That's a good solution, that should work. I've committed it locally, will push out changes soon. thanks, 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/
Re: [git pull] New firewire stack
Olaf Hering wrote: On Thu, May 03, Olaf Hering wrote: On Thu, May 03, Stefan Richter wrote: ieee1394-old Noone will seriously ship two firewire stacks, so that cant be the issue (for distributors). Once there is a way to easily switch between kernel releases, I'm ok with whatever module names you pick. This patch loads fw-sbp2 if sbp2 is still in the config file. So one can go back and forth between releases without worry about the root filesystem drivers. That's a good solution, that should work. I've committed it locally, will push out changes soon. thanks, 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/
Re: [git pull] New firewire stack
On Thu, May 03, Olaf Hering wrote:
> On Thu, May 03, Stefan Richter wrote:
>
> > ieee1394-old
>
> Noone will seriously ship two firewire stacks, so that cant be the
> issue (for distributors).
>
> Once there is a way to easily switch between kernel releases, I'm ok
> with whatever module names you pick.
This patch loads fw-sbp2 if sbp2 is still in the config file. So one can
go back and forth between releases without worry about the root
filesystem drivers.
Index: linux-2.6.21/drivers/firewire/fw-ohci.c
===
--- linux-2.6.21.orig/drivers/firewire/fw-ohci.c
+++ linux-2.6.21/drivers/firewire/fw-ohci.c
@@ -1881,6 +1881,9 @@ static struct pci_driver fw_ohci_pci_dri
MODULE_AUTHOR("Kristian Hoegsberg <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("Driver for PCI OHCI IEEE1394 controllers");
MODULE_LICENSE("GPL");
+#ifndef CONFIG_IEEE1394_OHCI1394_MODULE
+MODULE_ALIAS("ohci1394");
+#endif
static int __init fw_ohci_init(void)
{
Index: linux-2.6.21/drivers/firewire/fw-sbp2.c
===
--- linux-2.6.21.orig/drivers/firewire/fw-sbp2.c
+++ linux-2.6.21/drivers/firewire/fw-sbp2.c
@@ -1150,6 +1150,9 @@ MODULE_AUTHOR("Kristian Hoegsberg <[EMAIL PROTECTED]
MODULE_DESCRIPTION("SCSI over IEEE1394");
MODULE_LICENSE("GPL");
MODULE_DEVICE_TABLE(ieee1394, sbp2_id_table);
+#ifndef CONFIG_IEEE1394_SBP2_MODULE
+MODULE_ALIAS("sbp2");
+#endif
static int __init sbp2_init(void)
{
-
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/
Re: [git pull] New firewire stack
On Thu, May 03, Olaf Hering wrote:
On Thu, May 03, Stefan Richter wrote:
ieee1394-old
Noone will seriously ship two firewire stacks, so that cant be the
issue (for distributors).
Once there is a way to easily switch between kernel releases, I'm ok
with whatever module names you pick.
This patch loads fw-sbp2 if sbp2 is still in the config file. So one can
go back and forth between releases without worry about the root
filesystem drivers.
Index: linux-2.6.21/drivers/firewire/fw-ohci.c
===
--- linux-2.6.21.orig/drivers/firewire/fw-ohci.c
+++ linux-2.6.21/drivers/firewire/fw-ohci.c
@@ -1881,6 +1881,9 @@ static struct pci_driver fw_ohci_pci_dri
MODULE_AUTHOR(Kristian Hoegsberg [EMAIL PROTECTED]);
MODULE_DESCRIPTION(Driver for PCI OHCI IEEE1394 controllers);
MODULE_LICENSE(GPL);
+#ifndef CONFIG_IEEE1394_OHCI1394_MODULE
+MODULE_ALIAS(ohci1394);
+#endif
static int __init fw_ohci_init(void)
{
Index: linux-2.6.21/drivers/firewire/fw-sbp2.c
===
--- linux-2.6.21.orig/drivers/firewire/fw-sbp2.c
+++ linux-2.6.21/drivers/firewire/fw-sbp2.c
@@ -1150,6 +1150,9 @@ MODULE_AUTHOR(Kristian Hoegsberg [EMAIL PROTECTED]
MODULE_DESCRIPTION(SCSI over IEEE1394);
MODULE_LICENSE(GPL);
MODULE_DEVICE_TABLE(ieee1394, sbp2_id_table);
+#ifndef CONFIG_IEEE1394_SBP2_MODULE
+MODULE_ALIAS(sbp2);
+#endif
static int __init sbp2_init(void)
{
-
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/
Re: [git pull] New firewire stack
On Thu, 03 May 2007, Kristian Høgsberg wrote: > Adrian Bunk wrote: > >> | An advantage of changing the names is that they are now prefixed. > >> > >> Is the opportunity to clean up module names compelling enough, vs. (the > >> wish for) minimized trouble with scripts which refer to module names? > >> ... > > > > How big is the trouble actually? > > Exactly. In Fedora we've just added a fw-sbp2 case to mkinitrd, it's only a > couple of lines of extra shell code: > > elif [ "$modName" = "fw-sbp2" ]; then > findmodule fw-core > findmodule fw-ohci > modName="fw-sbp2" > > and that's the extent of the changes. The sbp2 case for the old drivers is > still in there and in the end mkinitrd works with either stack. > > Kristian I also think both stacks should be provided in the mainline kernel, preferably in their own separate directories. I still need the old stack for dv1394, which isn't available in the new stack. But if the new stack is also there, I might be motivated for example to try out the new sbp2 module, to see how well it works and how it compares in performance to the old sbp2 module. If it's not there, I'm probably not going to go out of my way to download it from the net, since my existing setup is working just fine for me. -Bill - 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/
Re: [git pull] New firewire stack
On Thu, 03 May 2007, Kristian Høgsberg wrote: Adrian Bunk wrote: | An advantage of changing the names is that they are now prefixed. Is the opportunity to clean up module names compelling enough, vs. (the wish for) minimized trouble with scripts which refer to module names? ... How big is the trouble actually? Exactly. In Fedora we've just added a fw-sbp2 case to mkinitrd, it's only a couple of lines of extra shell code: elif [ $modName = fw-sbp2 ]; then findmodule fw-core findmodule fw-ohci modName=fw-sbp2 and that's the extent of the changes. The sbp2 case for the old drivers is still in there and in the end mkinitrd works with either stack. Kristian I also think both stacks should be provided in the mainline kernel, preferably in their own separate directories. I still need the old stack for dv1394, which isn't available in the new stack. But if the new stack is also there, I might be motivated for example to try out the new sbp2 module, to see how well it works and how it compares in performance to the old sbp2 module. If it's not there, I'm probably not going to go out of my way to download it from the net, since my existing setup is working just fine for me. -Bill - 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/
Re: [git pull] New firewire stack
> 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/
Re: [git pull] New firewire stack
Adrian Bunk wrote: | An advantage of changing the names is that they are now prefixed. Is the opportunity to clean up module names compelling enough, vs. (the wish for) minimized trouble with scripts which refer to module names? ... How big is the trouble actually? Exactly. In Fedora we've just added a fw-sbp2 case to mkinitrd, it's only a couple of lines of extra shell code: elif [ "$modName" = "fw-sbp2" ]; then findmodule fw-core findmodule fw-ohci modName="fw-sbp2" and that's the extent of the changes. The sbp2 case for the old drivers is still in there and in the end mkinitrd works with either stack. 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/
Re: [git pull] New firewire stack
On Thu, May 03, 2007 at 03:30:36PM +0200, Stefan Richter wrote: > Olaf Hering wrote: > > On Thu, May 03, Stefan Richter wrote: > > > >>ieee1394-old > > > > Noone will seriously ship two firewire stacks, so that cant be the > > issue (for distributors). > > I don't actively watch distributions, but I believe there are frequently > alternative drivers shipped. How much sense that makes for FireWire is > another question. > > > Once there is a way to easily switch between kernel releases, I'm ok > > with whatever module names you pick. > > It may actually be easier to let problem reporters (who cannot or don't > want to compile kernels) compare between different kernel releases, > rather than to ask them to compare between different stacks on top of > the same kernel. Still, it potentially reduces the testers base. > > Adrian wrote: > | An advantage of changing the names is that they are now prefixed. > > Is the opportunity to clean up module names compelling enough, vs. (the > wish for) minimized trouble with scripts which refer to module names? >... How big is the trouble actually? We have never and cannot guarantee stable module names (think of e.g. PATA, e100 or sky2/skge), so changed names are always possible when upgrading kernels. Module aliases can solve many issues. And sometimes it might even be an advantage that different drivers for the same hardware get different names (consider especially PATA). Not changing the module names also has the problem that the old code must be removed from the kernel tree before the new one can be added since two different modules with the same names could easily cause trouble - consider a user first compiling and installing the one modular, and then compiling and installing the other one modular (e.g. due to problems with the one he tried first). Which module will now be loaded by modprobe? > Stefan Richter cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: [git pull] New firewire stack
Olaf Hering wrote: > On Thu, May 03, Stefan Richter wrote: > >> ieee1394-old > > Noone will seriously ship two firewire stacks, so that cant be the > issue (for distributors). I don't actively watch distributions, but I believe there are frequently alternative drivers shipped. How much sense that makes for FireWire is another question. > Once there is a way to easily switch between kernel releases, I'm ok > with whatever module names you pick. It may actually be easier to let problem reporters (who cannot or don't want to compile kernels) compare between different kernel releases, rather than to ask them to compare between different stacks on top of the same kernel. Still, it potentially reduces the testers base. Adrian wrote: | An advantage of changing the names is that they are now prefixed. Is the opportunity to clean up module names compelling enough, vs. (the wish for) minimized trouble with scripts which refer to module names? Kristian wrote: | Another point in favour of different module names is that the new | stack doesn't actually provide the same user space interfaces as the | old stack. This applies mostly to vs. . The rest should look identical to the user, except that some inapplicable module parameters (and bugs) were removed. -- Stefan Richter -=-=-=== -=-= ---== http://arcgraph.de/sr/ - 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/
Re: [git pull] New firewire stack
On Thu, May 03, Stefan Richter wrote: > ieee1394-old Noone will seriously ship two firewire stacks, so that cant be the issue (for distributors). Once there is a way to easily switch between kernel releases, I'm ok with whatever module names you pick. - 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/
Re: [git pull] New firewire stack
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) sbp2 (was fw-sbp2) eth1394 (to be done) --- but that's a bad name anyway, it implements IP over 1394, not Ethernet old modules, for example: ieee1394-old ohci1394-old sbp2-old eth1394-old pcilynx(unless somebody plans to port it, then pcilynx-old) raw1394(or rename it too?, it requires ieee1394-old) video1394 (ditto) dv1394 (ditto) 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. >> As for putting the new stack in drivers/ieee1394 - I don't know, I think it >> makes sense to keep the new stack in it's own directory. > > My immediate thought it that it would be neater and clearer to have both > stacks in different directories, but I could live with either. We could rename some of the existing source files to make the distinction clearer. > 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. 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.) -- Stefan Richter -=-=-=== -=-= ---== http://arcgraph.de/sr/ - 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/
Re: [git pull] New firewire stack
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) sbp2 (was fw-sbp2) eth1394 (to be done) --- but that's a bad name anyway, it implements IP over 1394, not Ethernet old modules, for example: ieee1394-old ohci1394-old sbp2-old eth1394-old pcilynx(unless somebody plans to port it, then pcilynx-old) raw1394(or rename it too?, it requires ieee1394-old) video1394 (ditto) dv1394 (ditto) 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. As for putting the new stack in drivers/ieee1394 - I don't know, I think it makes sense to keep the new stack in it's own directory. My immediate thought it that it would be neater and clearer to have both stacks in different directories, but I could live with either. We could rename some of the existing source files to make the distinction clearer. 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. 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.) -- Stefan Richter -=-=-=== -=-= ---== http://arcgraph.de/sr/ - 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/
Re: [git pull] New firewire stack
On Thu, May 03, Stefan Richter wrote: ieee1394-old Noone will seriously ship two firewire stacks, so that cant be the issue (for distributors). Once there is a way to easily switch between kernel releases, I'm ok with whatever module names you pick. - 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/
Re: [git pull] New firewire stack
Olaf Hering wrote: On Thu, May 03, Stefan Richter wrote: ieee1394-old Noone will seriously ship two firewire stacks, so that cant be the issue (for distributors). I don't actively watch distributions, but I believe there are frequently alternative drivers shipped. How much sense that makes for FireWire is another question. Once there is a way to easily switch between kernel releases, I'm ok with whatever module names you pick. It may actually be easier to let problem reporters (who cannot or don't want to compile kernels) compare between different kernel releases, rather than to ask them to compare between different stacks on top of the same kernel. Still, it potentially reduces the testers base. Adrian wrote: | An advantage of changing the names is that they are now prefixed. Is the opportunity to clean up module names compelling enough, vs. (the wish for) minimized trouble with scripts which refer to module names? Kristian wrote: | Another point in favour of different module names is that the new | stack doesn't actually provide the same user space interfaces as the | old stack. This applies mostly to fw-core vs. ieee1394 + raw1394 + video1394 + dv1394. The rest should look identical to the user, except that some inapplicable module parameters (and bugs) were removed. -- Stefan Richter -=-=-=== -=-= ---== http://arcgraph.de/sr/ - 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/
Re: [git pull] New firewire stack
On Thu, May 03, 2007 at 03:30:36PM +0200, Stefan Richter wrote: Olaf Hering wrote: On Thu, May 03, Stefan Richter wrote: ieee1394-old Noone will seriously ship two firewire stacks, so that cant be the issue (for distributors). I don't actively watch distributions, but I believe there are frequently alternative drivers shipped. How much sense that makes for FireWire is another question. Once there is a way to easily switch between kernel releases, I'm ok with whatever module names you pick. It may actually be easier to let problem reporters (who cannot or don't want to compile kernels) compare between different kernel releases, rather than to ask them to compare between different stacks on top of the same kernel. Still, it potentially reduces the testers base. Adrian wrote: | An advantage of changing the names is that they are now prefixed. Is the opportunity to clean up module names compelling enough, vs. (the wish for) minimized trouble with scripts which refer to module names? ... How big is the trouble actually? We have never and cannot guarantee stable module names (think of e.g. PATA, e100 or sky2/skge), so changed names are always possible when upgrading kernels. Module aliases can solve many issues. And sometimes it might even be an advantage that different drivers for the same hardware get different names (consider especially PATA). Not changing the module names also has the problem that the old code must be removed from the kernel tree before the new one can be added since two different modules with the same names could easily cause trouble - consider a user first compiling and installing the one modular, and then compiling and installing the other one modular (e.g. due to problems with the one he tried first). Which module will now be loaded by modprobe? Stefan Richter cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: [git pull] New firewire stack
Adrian Bunk wrote: | An advantage of changing the names is that they are now prefixed. Is the opportunity to clean up module names compelling enough, vs. (the wish for) minimized trouble with scripts which refer to module names? ... How big is the trouble actually? Exactly. In Fedora we've just added a fw-sbp2 case to mkinitrd, it's only a couple of lines of extra shell code: elif [ $modName = fw-sbp2 ]; then findmodule fw-core findmodule fw-ohci modName=fw-sbp2 and that's the extent of the changes. The sbp2 case for the old drivers is still in there and in the end mkinitrd works with either stack. 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/
Re: [git pull] New firewire stack
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/
Re: [git pull] New firewire stack
Kritian wrote: > Olaf Hering wrote: > > On Tue, May 01, Kristian H?gsberg wrote: > > > >> drivers/firewire/Kconfig | 60 ++ > > > > NACK. > > Upgrade the current drivers/ieee1394/ with the new code, and keep all > > existing module names. > > What's your reasoning here? Having different module names allows people to > compile both stacks and switch between them as they wish. While I'm not fussed about the implementation details I agree with those who have advocated a migration period where both stacks are present. A major change such as this is almost certain to turn up bugs when it becomes more widely tested, and many firewire users are unlikely to test the new stack without an easy fallback to a known working system. Yes, I know development and production systems should be separate, but I (and many others) can't afford enough hardware for that. > Another point in favour of different module names is that the new stack > doesn't actually provide the same user space interfaces as the old stack. > Basically, no applications use the raw kernel interfaces and the new stack > is only compatible at the library level. In the light of this, I think > it's fair to change the module names. Sounds reasonable to me. 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. > As for putting the new stack in drivers/ieee1394 - I don't know, I think it > makes sense to keep the new stack in it's own directory. My immediate thought it that it would be neater and clearer to have both stacks in different directories, but I could live with either. 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). 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/
Re: [git pull] New firewire stack
Adrian Bunk wrote: On Wed, May 02, 2007 at 02:48:11PM +0200, Stefan Richter wrote: Olaf Hering wrote: On Tue, May 01, Kristian Høgsberg wrote: drivers/firewire/Kconfig | 60 ++ NACK. Upgrade the current drivers/ieee1394/ with the new code, Last time I believe I was the only one who asked whether to put it into drivers/ieee1394 instead of another directory. Of course I acknowledge that everytime a new review round is started, people do reconsider. Especially since we had a gap of a few months since the last LKML review. and keep all existing module names. I'm impartial to that. Using same names might ease the transition from the userspace side, as far as there is userland which relies on module names. A certain drawback of same names would be that geeks cannot install both stacks at once during the transition period. Therefore, checking whether eventual problems are in fact regressions involves a module unload/ configure/ build/ install/ reload cycle, instead of just module unload/ reload. This especially means we can only get help from testers who are able to build kernels. Other opinions? An advantage of changing the names is that they are now prefixed. But looking at them, there will again be the point whether everyone will think that "fw" is firmware, and perhaps switching to the (although longer) prefix "firewire" might make sense? I like "firewire" better, I'm already using that for the userspace header file. Renaming the modules to firewire-core, firewire-ohci and firewire-sbp2 sounds good to me. 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/
Re: [git pull] New firewire stack
Stefan Richter wrote: Christoph Hellwig wrote: .. Please send out patches for review first. Yes, it's been a while since the last submission for review [1], and most of the changes went over linux1394-devel only. And to put it mildly, there aren't a lot of capable reviewers watching that list. ... (If this division seems odd, don't blame Kristian, blame me. :-) I'm looking forward to comments. Looks good to me, thanks Stefan. The first three patches don't compile on their own as they are, but it's a good split of the core stack. 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/
Re: [git pull] New firewire stack
On Wed, May 02, Kristian Høgsberg wrote: > Olaf Hering wrote: > >On Tue, May 01, Kristian Høgsberg wrote: > > > >> drivers/firewire/Kconfig | 60 ++ > > > >NACK. > >Upgrade the current drivers/ieee1394/ with the new code, and keep all > >existing module names. > > What's your reasoning here? Whats the upgrade path for root on sbp2? Right now mkinitrd puts 'ohci1394 spb2' into the initrd because both names are stored in a config file. How does one configure that config file to have a setup that works with kernels which provide only drivers/ieee1394 and a newer ones which provide only drivers/firewire? - 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/
Re: [git pull] New firewire stack
Olaf Hering wrote: On Tue, May 01, Kristian Høgsberg wrote: drivers/firewire/Kconfig | 60 ++ NACK. Upgrade the current drivers/ieee1394/ with the new code, and keep all existing module names. What's your reasoning here? Having different module names allows people to compile both stacks and switch between them as they wish. Another point in favour of different module names is that the new stack doesn't actually provide the same user space interfaces as the old stack. Basically, no applications use the raw kernel interfaces and the new stack is only compatible at the library level. In the light of this, I think it's fair to change the module names. As for putting the new stack in drivers/ieee1394 - I don't know, I think it makes sense to keep the new stack in it's own directory. If it's a deal breaker for inclusion, let's talk about moving it, but it would be nice if you could elaborate just a little bit beyond "NACK". thanks, 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/
Re: [git pull] New firewire stack
Gene Heskett wrote: > On Wednesday 02 May 2007, Stefan Richter wrote: >> Olaf Hering wrote: >>> NACK. >>> Upgrade the current drivers/ieee1394/ with the new code, >>> and keep all existing module names. >> I'm impartial to that. Using same names might ease the transition from >> the userspace side, as far as there is userland which relies on module >> names. >> >> A certain drawback of same names would be that geeks cannot install both >> stacks at once during the transition period. [...] > So I'd vote unconditionally to have 2 trees to select > from at module load time until the shakeout has produced usable code in the > 2nd tree. [...] Adrian Bunk wrote: > An advantage of changing the names is that they are now prefixed. > But looking at them, there will again be the point whether everyone will > think that "fw" is firmware, and perhaps switching to the (although > longer) prefix "firewire" might make sense? Whatever names the FireWire modules will get, we shouldn't change the names anymore _after_ the new code appears in mainline. Anyway, if the same names really should be used, as Olaf demands, then it affects at most ohci1394, sbp2, eth1394, ieee1394. However, ieee1394 is probably never loaded explicitly by scripts (only auto-loaded per dependency of the others), and the other three all have proper module aliases. If the new modules are meant to look like the old ones, then there is also the problem with module parameters. Many of the old stack's module parameters are merely there as hacks or workarounds though; therefore they shouldn't appear in shipped scripts and shipped configurations anyway. -- Stefan Richter -=-=-=== -=-= ---=- http://arcgraph.de/sr/ - 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/
Re: [git pull] New firewire stack
On Wed, May 02, 2007 at 02:48:11PM +0200, Stefan Richter wrote: > Olaf Hering wrote: > > On Tue, May 01, Kristian Høgsberg wrote: > > > >> drivers/firewire/Kconfig | 60 ++ > > > > NACK. > > Upgrade the current drivers/ieee1394/ with the new code, > > Last time I believe I was the only one who asked whether to put it into > drivers/ieee1394 instead of another directory. Of course I acknowledge > that everytime a new review round is started, people do reconsider. > Especially since we had a gap of a few months since the last LKML review. > > > and keep all existing module names. > > I'm impartial to that. Using same names might ease the transition from > the userspace side, as far as there is userland which relies on module > names. > > A certain drawback of same names would be that geeks cannot install both > stacks at once during the transition period. Therefore, checking > whether eventual problems are in fact regressions involves a module > unload/ configure/ build/ install/ reload cycle, instead of just module > unload/ reload. This especially means we can only get help from testers > who are able to build kernels. > > Other opinions? An advantage of changing the names is that they are now prefixed. But looking at them, there will again be the point whether everyone will think that "fw" is firmware, and perhaps switching to the (although longer) prefix "firewire" might make sense? > Stefan Richter cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: [git pull] New firewire stack
On Wednesday 02 May 2007, Stefan Richter wrote: >Olaf Hering wrote: >> On Tue, May 01, Kristian Høgsberg wrote: >>> drivers/firewire/Kconfig | 60 ++ >> >> NACK. >> Upgrade the current drivers/ieee1394/ with the new code, > >Last time I believe I was the only one who asked whether to put it into >drivers/ieee1394 instead of another directory. Of course I acknowledge >that everytime a new review round is started, people do reconsider. >Especially since we had a gap of a few months since the last LKML review. > >> and keep all existing module names. > >I'm impartial to that. Using same names might ease the transition from >the userspace side, as far as there is userland which relies on module >names. > >A certain drawback of same names would be that geeks cannot install both >stacks at once during the transition period. Therefore, checking >whether eventual problems are in fact regressions involves a module >unload/ configure/ build/ install/ reload cycle, instead of just module >unload/ reload. This especially means we can only get help from testers >who are able to build kernels. > >Other opinions? I can and do build my own kernels so that's not a problem for me. I also have a firewire movie camera that went through absolute hell the last time a firewire upgrade came by, and it was over 5 months before I had a working kino install again. So I'd vote unconditionally to have 2 trees to select from at module load time until the shakeout has produced usable code in the 2nd tree. >From me, its a definite ACK. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) I owe, I owe, It's off to work I go... - 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/
Re: [git pull] New firewire stack
Olaf Hering wrote: > On Tue, May 01, Kristian Høgsberg wrote: > >> drivers/firewire/Kconfig | 60 ++ > > NACK. > Upgrade the current drivers/ieee1394/ with the new code, Last time I believe I was the only one who asked whether to put it into drivers/ieee1394 instead of another directory. Of course I acknowledge that everytime a new review round is started, people do reconsider. Especially since we had a gap of a few months since the last LKML review. > and keep all existing module names. I'm impartial to that. Using same names might ease the transition from the userspace side, as far as there is userland which relies on module names. A certain drawback of same names would be that geeks cannot install both stacks at once during the transition period. Therefore, checking whether eventual problems are in fact regressions involves a module unload/ configure/ build/ install/ reload cycle, instead of just module unload/ reload. This especially means we can only get help from testers who are able to build kernels. Other opinions? -- Stefan Richter -=-=-=== -=-= ---=- http://arcgraph.de/sr/ - 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/
Re: [git pull] New firewire stack
On Tue, May 01, Kristian Høgsberg wrote: > drivers/firewire/Kconfig | 60 ++ NACK. Upgrade the current drivers/ieee1394/ with the new code, and keep all existing module names. - 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/
Re: [git pull] New firewire stack
Christoph Hellwig wrote: > On Tue, May 01, 2007 at 04:27:11PM -0400, Kristian H??gsberg wrote: >> Hi Linus, >> >> As you may know, we've been working on a new FireWire stack over on >> linux1394-devel. The main driver behind this work is to get a small, >> maintainable and supportable FireWire stack, with an acceptable >> backwards compatibility story. > > Please send out patches for review first. > Yes, it's been a while since the last submission for review [1], and most of the changes went over linux1394-devel only. And to put it mildly, there aren't a lot of capable reviewers watching that list. Changes since last submission, AFAIR: - completion of the DMA engine - completion of the userspace ABI - extensions to exported sysfs attributes - some other feature additions like bus manager capability - lots of bug fixes - some style fixes I'll folllow up with "git diff v2.6.21-rc3..juju" ripped apart, reordered, and refreshed against 2.6.21: [PATCH 1/6] firewire: handling of cards, buses, nodes [PATCH 2/6] firewire: isochronous and asynchronous I/O [PATCH 3/6] firewire: char device interface [PATCH 4/6] firewire: OHCI-1394 lowlevel driver [PATCH 5/6] firewire: SBP-2 highlevel driver [PATCH 6/6] firewire: add it all to kbuild (If this division seems odd, don't blame Kristian, blame me. :-) I'm looking forward to comments. [1] http://lkml.org/lkml/2006/12/19/306 http://lkml.org/lkml/2006/12/19/307 http://lkml.org/lkml/2006/12/19/309 http://lkml.org/lkml/2006/12/19/310 http://lkml.org/lkml/2006/12/19/308 -- Stefan Richter -=-=-=== -=-= ---=- http://arcgraph.de/sr/ - 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/
Re: [git pull] New firewire stack
On Tue, May 01, 2007 at 04:27:11PM -0400, Kristian H??gsberg wrote: > Hi Linus, > > As you may know, we've been working on a new FireWire stack over on > linux1394-devel. The main driver behind this work is to get a small, > maintainable and supportable FireWire stack, with an acceptable > backwards compatibility story. Please send out patches for review first. - 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/
Re: [git pull] New firewire stack
On Tue, May 01, 2007 at 04:27:11PM -0400, Kristian H??gsberg wrote: Hi Linus, As you may know, we've been working on a new FireWire stack over on linux1394-devel. The main driver behind this work is to get a small, maintainable and supportable FireWire stack, with an acceptable backwards compatibility story. Please send out patches for review first. - 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/
Re: [git pull] New firewire stack
Christoph Hellwig wrote: On Tue, May 01, 2007 at 04:27:11PM -0400, Kristian H??gsberg wrote: Hi Linus, As you may know, we've been working on a new FireWire stack over on linux1394-devel. The main driver behind this work is to get a small, maintainable and supportable FireWire stack, with an acceptable backwards compatibility story. Please send out patches for review first. Yes, it's been a while since the last submission for review [1], and most of the changes went over linux1394-devel only. And to put it mildly, there aren't a lot of capable reviewers watching that list. Changes since last submission, AFAIR: - completion of the DMA engine - completion of the userspace ABI - extensions to exported sysfs attributes - some other feature additions like bus manager capability - lots of bug fixes - some style fixes I'll folllow up with git diff v2.6.21-rc3..juju ripped apart, reordered, and refreshed against 2.6.21: [PATCH 1/6] firewire: handling of cards, buses, nodes [PATCH 2/6] firewire: isochronous and asynchronous I/O [PATCH 3/6] firewire: char device interface [PATCH 4/6] firewire: OHCI-1394 lowlevel driver [PATCH 5/6] firewire: SBP-2 highlevel driver [PATCH 6/6] firewire: add it all to kbuild (If this division seems odd, don't blame Kristian, blame me. :-) I'm looking forward to comments. [1] http://lkml.org/lkml/2006/12/19/306 http://lkml.org/lkml/2006/12/19/307 http://lkml.org/lkml/2006/12/19/309 http://lkml.org/lkml/2006/12/19/310 http://lkml.org/lkml/2006/12/19/308 -- Stefan Richter -=-=-=== -=-= ---=- http://arcgraph.de/sr/ - 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/
Re: [git pull] New firewire stack
On Tue, May 01, Kristian Høgsberg wrote: drivers/firewire/Kconfig | 60 ++ NACK. Upgrade the current drivers/ieee1394/ with the new code, and keep all existing module names. - 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/
Re: [git pull] New firewire stack
Olaf Hering wrote: On Tue, May 01, Kristian Høgsberg wrote: drivers/firewire/Kconfig | 60 ++ NACK. Upgrade the current drivers/ieee1394/ with the new code, Last time I believe I was the only one who asked whether to put it into drivers/ieee1394 instead of another directory. Of course I acknowledge that everytime a new review round is started, people do reconsider. Especially since we had a gap of a few months since the last LKML review. and keep all existing module names. I'm impartial to that. Using same names might ease the transition from the userspace side, as far as there is userland which relies on module names. A certain drawback of same names would be that geeks cannot install both stacks at once during the transition period. Therefore, checking whether eventual problems are in fact regressions involves a module unload/ configure/ build/ install/ reload cycle, instead of just module unload/ reload. This especially means we can only get help from testers who are able to build kernels. Other opinions? -- Stefan Richter -=-=-=== -=-= ---=- http://arcgraph.de/sr/ - 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/
Re: [git pull] New firewire stack
On Wednesday 02 May 2007, Stefan Richter wrote: Olaf Hering wrote: On Tue, May 01, Kristian Høgsberg wrote: drivers/firewire/Kconfig | 60 ++ NACK. Upgrade the current drivers/ieee1394/ with the new code, Last time I believe I was the only one who asked whether to put it into drivers/ieee1394 instead of another directory. Of course I acknowledge that everytime a new review round is started, people do reconsider. Especially since we had a gap of a few months since the last LKML review. and keep all existing module names. I'm impartial to that. Using same names might ease the transition from the userspace side, as far as there is userland which relies on module names. A certain drawback of same names would be that geeks cannot install both stacks at once during the transition period. Therefore, checking whether eventual problems are in fact regressions involves a module unload/ configure/ build/ install/ reload cycle, instead of just module unload/ reload. This especially means we can only get help from testers who are able to build kernels. Other opinions? I can and do build my own kernels so that's not a problem for me. I also have a firewire movie camera that went through absolute hell the last time a firewire upgrade came by, and it was over 5 months before I had a working kino install again. So I'd vote unconditionally to have 2 trees to select from at module load time until the shakeout has produced usable code in the 2nd tree. From me, its a definite ACK. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) I owe, I owe, It's off to work I go... - 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/
Re: [git pull] New firewire stack
On Wed, May 02, 2007 at 02:48:11PM +0200, Stefan Richter wrote: Olaf Hering wrote: On Tue, May 01, Kristian Høgsberg wrote: drivers/firewire/Kconfig | 60 ++ NACK. Upgrade the current drivers/ieee1394/ with the new code, Last time I believe I was the only one who asked whether to put it into drivers/ieee1394 instead of another directory. Of course I acknowledge that everytime a new review round is started, people do reconsider. Especially since we had a gap of a few months since the last LKML review. and keep all existing module names. I'm impartial to that. Using same names might ease the transition from the userspace side, as far as there is userland which relies on module names. A certain drawback of same names would be that geeks cannot install both stacks at once during the transition period. Therefore, checking whether eventual problems are in fact regressions involves a module unload/ configure/ build/ install/ reload cycle, instead of just module unload/ reload. This especially means we can only get help from testers who are able to build kernels. Other opinions? An advantage of changing the names is that they are now prefixed. But looking at them, there will again be the point whether everyone will think that fw is firmware, and perhaps switching to the (although longer) prefix firewire might make sense? Stefan Richter cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: [git pull] New firewire stack
Gene Heskett wrote: On Wednesday 02 May 2007, Stefan Richter wrote: Olaf Hering wrote: NACK. Upgrade the current drivers/ieee1394/ with the new code, and keep all existing module names. I'm impartial to that. Using same names might ease the transition from the userspace side, as far as there is userland which relies on module names. A certain drawback of same names would be that geeks cannot install both stacks at once during the transition period. [...] So I'd vote unconditionally to have 2 trees to select from at module load time until the shakeout has produced usable code in the 2nd tree. [...] Adrian Bunk wrote: An advantage of changing the names is that they are now prefixed. But looking at them, there will again be the point whether everyone will think that fw is firmware, and perhaps switching to the (although longer) prefix firewire might make sense? Whatever names the FireWire modules will get, we shouldn't change the names anymore _after_ the new code appears in mainline. Anyway, if the same names really should be used, as Olaf demands, then it affects at most ohci1394, sbp2, eth1394, ieee1394. However, ieee1394 is probably never loaded explicitly by scripts (only auto-loaded per dependency of the others), and the other three all have proper module aliases. If the new modules are meant to look like the old ones, then there is also the problem with module parameters. Many of the old stack's module parameters are merely there as hacks or workarounds though; therefore they shouldn't appear in shipped scripts and shipped configurations anyway. -- Stefan Richter -=-=-=== -=-= ---=- http://arcgraph.de/sr/ - 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/
Re: [git pull] New firewire stack
Olaf Hering wrote: On Tue, May 01, Kristian Høgsberg wrote: drivers/firewire/Kconfig | 60 ++ NACK. Upgrade the current drivers/ieee1394/ with the new code, and keep all existing module names. What's your reasoning here? Having different module names allows people to compile both stacks and switch between them as they wish. Another point in favour of different module names is that the new stack doesn't actually provide the same user space interfaces as the old stack. Basically, no applications use the raw kernel interfaces and the new stack is only compatible at the library level. In the light of this, I think it's fair to change the module names. As for putting the new stack in drivers/ieee1394 - I don't know, I think it makes sense to keep the new stack in it's own directory. If it's a deal breaker for inclusion, let's talk about moving it, but it would be nice if you could elaborate just a little bit beyond NACK. thanks, 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/
Re: [git pull] New firewire stack
On Wed, May 02, Kristian Høgsberg wrote: Olaf Hering wrote: On Tue, May 01, Kristian Høgsberg wrote: drivers/firewire/Kconfig | 60 ++ NACK. Upgrade the current drivers/ieee1394/ with the new code, and keep all existing module names. What's your reasoning here? Whats the upgrade path for root on sbp2? Right now mkinitrd puts 'ohci1394 spb2' into the initrd because both names are stored in a config file. How does one configure that config file to have a setup that works with kernels which provide only drivers/ieee1394 and a newer ones which provide only drivers/firewire? - 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/
Re: [git pull] New firewire stack
Adrian Bunk wrote: On Wed, May 02, 2007 at 02:48:11PM +0200, Stefan Richter wrote: Olaf Hering wrote: On Tue, May 01, Kristian Høgsberg wrote: drivers/firewire/Kconfig | 60 ++ NACK. Upgrade the current drivers/ieee1394/ with the new code, Last time I believe I was the only one who asked whether to put it into drivers/ieee1394 instead of another directory. Of course I acknowledge that everytime a new review round is started, people do reconsider. Especially since we had a gap of a few months since the last LKML review. and keep all existing module names. I'm impartial to that. Using same names might ease the transition from the userspace side, as far as there is userland which relies on module names. A certain drawback of same names would be that geeks cannot install both stacks at once during the transition period. Therefore, checking whether eventual problems are in fact regressions involves a module unload/ configure/ build/ install/ reload cycle, instead of just module unload/ reload. This especially means we can only get help from testers who are able to build kernels. Other opinions? An advantage of changing the names is that they are now prefixed. But looking at them, there will again be the point whether everyone will think that fw is firmware, and perhaps switching to the (although longer) prefix firewire might make sense? I like firewire better, I'm already using that for the userspace header file. Renaming the modules to firewire-core, firewire-ohci and firewire-sbp2 sounds good to me. 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/
Re: [git pull] New firewire stack
Stefan Richter wrote: Christoph Hellwig wrote: .. Please send out patches for review first. Yes, it's been a while since the last submission for review [1], and most of the changes went over linux1394-devel only. And to put it mildly, there aren't a lot of capable reviewers watching that list. ... (If this division seems odd, don't blame Kristian, blame me. :-) I'm looking forward to comments. Looks good to me, thanks Stefan. The first three patches don't compile on their own as they are, but it's a good split of the core stack. 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/
Re: [git pull] New firewire stack
Kritian wrote: Olaf Hering wrote: On Tue, May 01, Kristian H?gsberg wrote: drivers/firewire/Kconfig | 60 ++ NACK. Upgrade the current drivers/ieee1394/ with the new code, and keep all existing module names. What's your reasoning here? Having different module names allows people to compile both stacks and switch between them as they wish. While I'm not fussed about the implementation details I agree with those who have advocated a migration period where both stacks are present. A major change such as this is almost certain to turn up bugs when it becomes more widely tested, and many firewire users are unlikely to test the new stack without an easy fallback to a known working system. Yes, I know development and production systems should be separate, but I (and many others) can't afford enough hardware for that. Another point in favour of different module names is that the new stack doesn't actually provide the same user space interfaces as the old stack. Basically, no applications use the raw kernel interfaces and the new stack is only compatible at the library level. In the light of this, I think it's fair to change the module names. Sounds reasonable to me. 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. As for putting the new stack in drivers/ieee1394 - I don't know, I think it makes sense to keep the new stack in it's own directory. My immediate thought it that it would be neater and clearer to have both stacks in different directories, but I could live with either. 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). 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/
Re: [git pull] New firewire stack
Kristian Høgsberg wrote: ... > Carrying two FireWire stacks in the kernel > at the same time is not ideal, but it allows for wider testing of the > new stack, while keeping the old stack as a fallback for cases where > regressions make the new stack not usable. IMO, giving the new stack full exposure will get us the required input from developers and users so that a migration schedule can be prepared. > There's a lot of good reasons to switch to the new stack and a lot of > reasons to switch away from the old one. Highlights: > > - Has been in Fedora rawhide (development branch) and -mm for 3 >months, will be shipping in Fedora 7. There were also a few enthusiasts who gave the new stack a spin via patchkits which I used to publish. > - Backwards compatible at the library level; existing user space >libraries have been ported to use the new user space interface. > > - Less than 8k lines of code compared to 30k lines of code in the old >stack, and a similar size reduction in the sizes of the .ko's. > > - No kernel threads, compared to one subsystem thread and one thread >per FireWire controller in the old stack. > > - One user space interface to support zero-copy scatter-gather >streaming, as opposed to the old stacks 4 (was 5) different >streaming interfaces. > > - Per-device device files, letting userspace set up more finegrained >access control, such as preventing direct access to FireWire >storage devices. Or in short, Kristian has been addressing a number of big TODOs of the old stack with his reimplementation in a relatively short timeframe, TODOs which haven't been worked on in the existing stack for years, literally. There are also some smaller but effective features in the new stack like gap count optimization for better asynchronous throughput, something which I never got around to implement for the mainline stack because I have been busy with bugfixing and janitorial work. > Regressions: > > - eth1394 not ported over. There is nothing preventing this from >being done, though, but there's a couple of infrastructure bits >that aren't done yet. Actually that's one of the reasons why I started to work on eth1394 recently. > - No support for the PCILynx chipset. Nobody has this chipset >anymore, and the pcilynx driver in the old stack is bit-rotting anyway. > > - Some SBP-2 (storage) devices fail after significant amounts of IO. >Not clear what the problem is, but I can reproduce it here and am >working on fixing it. > > Please pull from the juju branch in Stefans repo: > > git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git juju > > thanks, > Kristian Linus, the juju branch is branched off v2.6.21-rc3, and it contains a linear series of 121 commits: Adrian Bunk (1) Andrew Morton (4) Kristian Høgsberg (91) Marc Butler (1) Randy Dunlap (1) Stefan Richter (22) Thomas Gleixner (1) If you would rather have it rebased on e.g. 2.6.21 or otherwise reorganized, or want to have the resulting diff posted for everyone to look at, I'd gladly do that. The stat as I get to see it locally and at master.kernel.org: drivers/Makefile |1 + drivers/firewire/Kconfig | 60 + drivers/firewire/Makefile | 10 + drivers/firewire/fw-card.c| 544 drivers/firewire/fw-cdev.c| 954 ++ drivers/firewire/fw-device.c | 782 +++ drivers/firewire/fw-device.h | 149 +++ drivers/firewire/fw-iso.c | 163 +++ drivers/firewire/fw-ohci.c| 1896 +++ drivers/firewire/fw-ohci.h| 153 +++ drivers/firewire/fw-sbp2.c| 1165 drivers/firewire/fw-topology.c| 519 drivers/firewire/fw-topology.h| 94 ++ drivers/firewire/fw-transaction.c | 889 + drivers/firewire/fw-transaction.h | 505 +++ drivers/ieee1394/Kconfig |2 + include/linux/firewire-cdev.h | 268 17 files changed, 8154 insertions(+), 0 deletions(-) create mode 100644 drivers/firewire/Kconfig create mode 100644 drivers/firewire/Makefile create mode 100644 drivers/firewire/fw-card.c create mode 100644 drivers/firewire/fw-cdev.c create mode 100644 drivers/firewire/fw-device.c create mode 100644 drivers/firewire/fw-device.h create mode 100644 drivers/firewire/fw-iso.c create mode 100644 drivers/firewire/fw-ohci.c create mode 100644 drivers/firewire/fw-ohci.h create mode 100644 drivers/firewire/fw-sbp2.c create mode 100644 drivers/firewire/fw-topology.c create mode 100644 drivers/firewire/fw-topology.h create mode 100644 drivers/firewire/fw-transaction.c create mode 100644 drivers/firewire/fw-transaction.h create mode 100644 include/linux/firewire-cdev.h -- Stefan Richter -=-=-=== -=-= = http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More
[git pull] New firewire stack
Hi Linus, As you may know, we've been working on a new FireWire stack over on linux1394-devel. The main driver behind this work is to get a small, maintainable and supportable FireWire stack, with an acceptable backwards compatibility story. I've been talking to Stefan Richter about it and we feel that the new stack is ready for inclusion into mainline. What I'd like to propose is that we carry both the new and the old stack in mainline for a few releases. Once we've reached a satisfactory level of stability and worked through what regressions there may be, we can consider deprecating the old stack. Carrying two FireWire stacks in the kernel at the same time is not ideal, but it allows for wider testing of the new stack, while keeping the old stack as a fallback for cases where regressions make the new stack not usable. There's a lot of good reasons to switch to the new stack and a lot of reasons to switch away from the old one. Highlights: - Has been in Fedora rawhide (development branch) and -mm for 3 months, will be shipping in Fedora 7. - Backwards compatible at the library level; existing user space libraries have been ported to use the new user space interface. - Less than 8k lines of code compared to 30k lines of code in the old stack, and a similar size reduction in the sizes of the .ko's. - No kernel threads, compared to one subsystem thread and one thread per FireWire controller in the old stack. - One user space interface to support zero-copy scatter-gather streaming, as opposed to the old stacks 4 (was 5) different streaming interfaces. - Per-device device files, letting userspace set up more finegrained access control, such as preventing direct access to FireWire storage devices. Regressions: - eth1394 not ported over. There is nothing preventing this from being done, though, but there's a couple of infrastructure bits that aren't done yet. - No support for the PCILynx chipset. Nobody has this chipset anymore, and the pcilynx driver in the old stack is bit-rotting anyway. - Some SBP-2 (storage) devices fail after significant amounts of IO. Not clear what the problem is, but I can reproduce it here and am working on fixing it. Please pull from the juju branch in Stefans repo: git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git juju thanks, Kristian drivers/Makefile |1 + drivers/firewire/Kconfig | 60 ++ drivers/firewire/Makefile | 10 + drivers/firewire/fw-card.c| 544 +++ drivers/firewire/fw-cdev.c| 954 +++ drivers/firewire/fw-device.c | 781 +++ drivers/firewire/fw-device.h | 149 +++ drivers/firewire/fw-iso.c | 163 drivers/firewire/fw-ohci.c| 1896 + drivers/firewire/fw-ohci.h| 153 +++ drivers/firewire/fw-sbp2.c| 1165 +++ drivers/firewire/fw-topology.c| 519 ++ drivers/firewire/fw-topology.h| 94 ++ drivers/firewire/fw-transaction.c | 889 + drivers/firewire/fw-transaction.h | 505 ++ drivers/ieee1394/Kconfig |2 + include/linux/firewire-cdev.h | 268 ++ 17 files changed, 8153 insertions(+), 0 deletions(-) - 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/
[git pull] New firewire stack
Hi Linus, As you may know, we've been working on a new FireWire stack over on linux1394-devel. The main driver behind this work is to get a small, maintainable and supportable FireWire stack, with an acceptable backwards compatibility story. I've been talking to Stefan Richter about it and we feel that the new stack is ready for inclusion into mainline. What I'd like to propose is that we carry both the new and the old stack in mainline for a few releases. Once we've reached a satisfactory level of stability and worked through what regressions there may be, we can consider deprecating the old stack. Carrying two FireWire stacks in the kernel at the same time is not ideal, but it allows for wider testing of the new stack, while keeping the old stack as a fallback for cases where regressions make the new stack not usable. There's a lot of good reasons to switch to the new stack and a lot of reasons to switch away from the old one. Highlights: - Has been in Fedora rawhide (development branch) and -mm for 3 months, will be shipping in Fedora 7. - Backwards compatible at the library level; existing user space libraries have been ported to use the new user space interface. - Less than 8k lines of code compared to 30k lines of code in the old stack, and a similar size reduction in the sizes of the .ko's. - No kernel threads, compared to one subsystem thread and one thread per FireWire controller in the old stack. - One user space interface to support zero-copy scatter-gather streaming, as opposed to the old stacks 4 (was 5) different streaming interfaces. - Per-device device files, letting userspace set up more finegrained access control, such as preventing direct access to FireWire storage devices. Regressions: - eth1394 not ported over. There is nothing preventing this from being done, though, but there's a couple of infrastructure bits that aren't done yet. - No support for the PCILynx chipset. Nobody has this chipset anymore, and the pcilynx driver in the old stack is bit-rotting anyway. - Some SBP-2 (storage) devices fail after significant amounts of IO. Not clear what the problem is, but I can reproduce it here and am working on fixing it. Please pull from the juju branch in Stefans repo: git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git juju thanks, Kristian drivers/Makefile |1 + drivers/firewire/Kconfig | 60 ++ drivers/firewire/Makefile | 10 + drivers/firewire/fw-card.c| 544 +++ drivers/firewire/fw-cdev.c| 954 +++ drivers/firewire/fw-device.c | 781 +++ drivers/firewire/fw-device.h | 149 +++ drivers/firewire/fw-iso.c | 163 drivers/firewire/fw-ohci.c| 1896 + drivers/firewire/fw-ohci.h| 153 +++ drivers/firewire/fw-sbp2.c| 1165 +++ drivers/firewire/fw-topology.c| 519 ++ drivers/firewire/fw-topology.h| 94 ++ drivers/firewire/fw-transaction.c | 889 + drivers/firewire/fw-transaction.h | 505 ++ drivers/ieee1394/Kconfig |2 + include/linux/firewire-cdev.h | 268 ++ 17 files changed, 8153 insertions(+), 0 deletions(-) - 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/
Re: [git pull] New firewire stack
Kristian Høgsberg wrote: ... Carrying two FireWire stacks in the kernel at the same time is not ideal, but it allows for wider testing of the new stack, while keeping the old stack as a fallback for cases where regressions make the new stack not usable. IMO, giving the new stack full exposure will get us the required input from developers and users so that a migration schedule can be prepared. There's a lot of good reasons to switch to the new stack and a lot of reasons to switch away from the old one. Highlights: - Has been in Fedora rawhide (development branch) and -mm for 3 months, will be shipping in Fedora 7. There were also a few enthusiasts who gave the new stack a spin via patchkits which I used to publish. - Backwards compatible at the library level; existing user space libraries have been ported to use the new user space interface. - Less than 8k lines of code compared to 30k lines of code in the old stack, and a similar size reduction in the sizes of the .ko's. - No kernel threads, compared to one subsystem thread and one thread per FireWire controller in the old stack. - One user space interface to support zero-copy scatter-gather streaming, as opposed to the old stacks 4 (was 5) different streaming interfaces. - Per-device device files, letting userspace set up more finegrained access control, such as preventing direct access to FireWire storage devices. Or in short, Kristian has been addressing a number of big TODOs of the old stack with his reimplementation in a relatively short timeframe, TODOs which haven't been worked on in the existing stack for years, literally. There are also some smaller but effective features in the new stack like gap count optimization for better asynchronous throughput, something which I never got around to implement for the mainline stack because I have been busy with bugfixing and janitorial work. Regressions: - eth1394 not ported over. There is nothing preventing this from being done, though, but there's a couple of infrastructure bits that aren't done yet. Actually that's one of the reasons why I started to work on eth1394 recently. - No support for the PCILynx chipset. Nobody has this chipset anymore, and the pcilynx driver in the old stack is bit-rotting anyway. - Some SBP-2 (storage) devices fail after significant amounts of IO. Not clear what the problem is, but I can reproduce it here and am working on fixing it. Please pull from the juju branch in Stefans repo: git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git juju thanks, Kristian Linus, the juju branch is branched off v2.6.21-rc3, and it contains a linear series of 121 commits: Adrian Bunk (1) Andrew Morton (4) Kristian Høgsberg (91) Marc Butler (1) Randy Dunlap (1) Stefan Richter (22) Thomas Gleixner (1) If you would rather have it rebased on e.g. 2.6.21 or otherwise reorganized, or want to have the resulting diff posted for everyone to look at, I'd gladly do that. The stat as I get to see it locally and at master.kernel.org: drivers/Makefile |1 + drivers/firewire/Kconfig | 60 + drivers/firewire/Makefile | 10 + drivers/firewire/fw-card.c| 544 drivers/firewire/fw-cdev.c| 954 ++ drivers/firewire/fw-device.c | 782 +++ drivers/firewire/fw-device.h | 149 +++ drivers/firewire/fw-iso.c | 163 +++ drivers/firewire/fw-ohci.c| 1896 +++ drivers/firewire/fw-ohci.h| 153 +++ drivers/firewire/fw-sbp2.c| 1165 drivers/firewire/fw-topology.c| 519 drivers/firewire/fw-topology.h| 94 ++ drivers/firewire/fw-transaction.c | 889 + drivers/firewire/fw-transaction.h | 505 +++ drivers/ieee1394/Kconfig |2 + include/linux/firewire-cdev.h | 268 17 files changed, 8154 insertions(+), 0 deletions(-) create mode 100644 drivers/firewire/Kconfig create mode 100644 drivers/firewire/Makefile create mode 100644 drivers/firewire/fw-card.c create mode 100644 drivers/firewire/fw-cdev.c create mode 100644 drivers/firewire/fw-device.c create mode 100644 drivers/firewire/fw-device.h create mode 100644 drivers/firewire/fw-iso.c create mode 100644 drivers/firewire/fw-ohci.c create mode 100644 drivers/firewire/fw-ohci.h create mode 100644 drivers/firewire/fw-sbp2.c create mode 100644 drivers/firewire/fw-topology.c create mode 100644 drivers/firewire/fw-topology.h create mode 100644 drivers/firewire/fw-transaction.c create mode 100644 drivers/firewire/fw-transaction.h create mode 100644 include/linux/firewire-cdev.h -- Stefan Richter -=-=-=== -=-= = http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at
