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. :-)
--
Ste
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
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
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_
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
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
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 n
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?
>
> 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
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
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 distributio
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 se
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: sen
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? Mess
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 diffe
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
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 lis
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
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 b
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
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 on
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 pu
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 direct
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
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 st
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
> backwa
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 expos
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 f
28 matches
Mail list logo
