Re: [git pull] New firewire stack

Re: [git pull] New firewire stack

[Jonathan Woithe]

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

Re: [git pull] New firewire stack

[Stefan Richter]

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/

Re: [git pull] New firewire stack

[Olaf Hering]

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. 

Re: [git pull] New firewire stack

[Stefan Richter]

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/

Re: [git pull] New firewire stack

[Adrian Bunk]

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

Re: [git pull] New firewire stack

[Kristian Høgsberg]

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

Re: [git pull] New firewire stack

[Jonathan Woithe]

> 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

Re: [git pull] New firewire stack

[Bill Fink]

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

Re: [git pull] New firewire stack

[Olaf Hering]

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 <krh@bitplanet.net>");
 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 <krh@b
 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)
 {

Re: [git pull] New firewire stack

[Kristian Høgsberg]

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

Re: [git pull] New firewire stack

[Kristian Høgsberg]

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

Re: [git pull] New firewire stack

[Olaf Hering]

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?

Re: [git pull] New firewire stack

[Kristian Høgsberg]

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

Re: [git pull] New firewire stack

[Kristian Høgsberg]

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

Re: [git pull] New firewire stack

[Stefan Richter]

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/

Re: [git pull] New firewire stack

[Adrian Bunk]

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

Re: [git pull] New firewire stack

[Gene Heskett]

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...

Re: [git pull] New firewire stack

[Stefan Richter]

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/

Re: [git pull] New firewire stack

[Olaf Hering]

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.

Re: [git pull] New firewire stack

[Stefan Richter]

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/

Re: [git pull] New firewire stack

[Christoph Hellwig]

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.

Re: [git pull] New firewire stack

[Stefan Richter]

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/

[git pull] New firewire stack

[Kristian Høgsberg]

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(-)