Benjamin Herrenschmidt wrote:
> One of the problems with hpsb_ is that it's a total pain to type
> and doesn't mean anything at first sight :-)
Both prevent that other people snatch this prefix from us. Also, only
people who can recite the meaning of that acronym when asleep are
permitted to call
> One thing is for sure, the fw_ prefix is not too well suited to stay
> if/when Kristian's code is pushed to mainline. During a switch period,
> we could e.g. replace the old stack's prefixes by hpsb1_ (as the 1st
> generation of FireWire kernel APIs) or whatever and replace Kristian's
> prefixes
On 12/8/06, Stefan Richter <[EMAIL PROTECTED]> wrote:
Pavel Machek wrote at linux-kernel:
> On Tue 05-12-06 17:05:30, Erik Mouw wrote:
>> On Tue, Dec 05, 2006 at 10:13:55AM -0500, Kristian H?gsberg wrote:
>> > Marcel Holtmann wrote:
>> > >can you please use drivers/firewire/ if you want to start
Pavel Machek wrote at linux-kernel:
> On Tue 05-12-06 17:05:30, Erik Mouw wrote:
>> On Tue, Dec 05, 2006 at 10:13:55AM -0500, Kristian H?gsberg wrote:
>> > Marcel Holtmann wrote:
>> > >can you please use drivers/firewire/ if you want to start clean or
>> > >aiming at replacing drivers/ieee1394/. Us
On Tue 05-12-06 17:05:30, Erik Mouw wrote:
> On Tue, Dec 05, 2006 at 10:13:55AM -0500, Kristian H?gsberg wrote:
> > Marcel Holtmann wrote:
> > >can you please use drivers/firewire/ if you want to start clean or
> > >aiming at replacing drivers/ieee1394/. Using "fw" as an abbreviation in
> > >the di
Ben Collins wrote:
...
I would like to see new development efforts take cleanliness WRT host
byte order and 64bit architectures into account from the ground up. (I
understand though why Kristian made the announcement in this early
phase, and I agree with him that this kind of development has to g
Kristian Høgsberg wrote:
> Stefan Richter wrote:
>> You have to look at the matter not only from the POV of API design but
>> also of deployment and support.
>
> My POV here *is* about deployment and support, but from the kernel side
> of things. If you commit yourself to long time support for th
Stefan Richter wrote:
...
Another point is the various streaming drivers. There used to be 5 different
userspace streaming APIs in the linux1394: raw1394, video1394, amdtp, dv1394
and rawiso. Recently, amdtp (audio streaming) has been removed, since with
the rawiso interface, this can be done i
Stefan Richter wrote:
...
Another question is whether the stack-internal APIs are really fit for
non-OHCI chips. There is an unfinished low-level driver for GP2Lynx
which worked to some degree at some point, but other than that I don't
remember positive or negative reports in this department. May
Geert Uytterhoeven wrote:
> On Tue, 5 Dec 2006, Marcel Holtmann wrote:
>> I personally would go with
>> "ieee1394", because that is the official name for it. Otherwise go with
>> "firewire" if you wanna separate yourself from the previous stack.
>
> Which still leaves the opportunity for having a
On Tue, 5 Dec 2006, Marcel Holtmann wrote:
> the only problem are public and exported interfaces and function. For
> static code you can use whatever you want. I personally would go with
> "ieee1394", because that is the official name for it. Otherwise go with
> "firewire" if you wanna separate you
On Wed, 2006-12-06 at 09:56 +0100, Stefan Richter wrote:
> (Adding Cc: linux1394-devel)
>
> Ben Collins wrote at linux-kernel:
> > On Tue, 2006-12-05 at 18:21 -0500, Kristian Høgsberg wrote:
> >> Alexey Dobriyan wrote:
> >>> On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote:
>
Alexander Neundorf wrote:
> Von: Stefan Richter <[EMAIL PROTECTED]>
>> Mainline's FireWire stack lost a lot of trust
...
> For us it's working well, with no major problems (there was a problem with
> SMP kernels and the arm mapping, but my kernel is not recent and I didn't
> find the time yet to up
Hi,
Von: Stefan Richter <[EMAIL PROTECTED]>
...
> bugs get fixed. Mainline's FireWire stack lost a lot of trust at
> end-users and application developers because of periods of sometimes
> very visible regressions.
For us it's working well, with no major problems (there was a problem with SMP
ke
(Adding Cc: linux1394-devel)
Ben Collins wrote at linux-kernel:
> On Tue, 2006-12-05 at 18:21 -0500, Kristian Høgsberg wrote:
>> Alexey Dobriyan wrote:
>>> On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote:
I'm announcing an alternative firewire stack that I've been working on
(Adding Cc: linux1394-devel)
Kristian Høgsberg wrote to linux-kernel:
> Alexey Dobriyan wrote:
>> On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote:
>>> I'm announcing an alternative firewire stack that I've been working
>>> on the last few weeks.
>>
>> Is mainline firewire so hope
On Tue, 2006-12-05 at 18:21 -0500, Kristian Høgsberg wrote:
> Alexey Dobriyan wrote:
> > On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote:
> >> I'm announcing an alternative firewire stack that I've been working on
> >> the last few weeks.
> >
> > Is mainline firewire so hopeless
Marcel Holtmann wrote:
Hi Erik,
can you please use drivers/firewire/ if you want to start clean or
aiming at replacing drivers/ieee1394/. Using "fw" as an abbreviation in
the directory path is not really helpful.
Yes, that's probably a better idea. Do you see a problem with using fw_*
as a pr
Ray Lee wrote:
On 12/4/06, Kristian Høgsberg <[EMAIL PROTECTED]> wrote:
Ok... I was planning to make big-endian versions of the structs so
that the
endian issue would be solved. But if the bit layout is not consistent, I
guess bitfields are useless for wire formats. I didn't know that
though
On Tue, Dec 05, Kristian Høgsberg wrote:
> I'm announcing an alternative firewire stack that I've been working on
I suggest you hash out the most obvious bugs in -mm.
Once it you have it in a reasonable shape, replace the drivers in
drivers/ieee1394 in one go.
Its just not worth the pain to switc
Alexey Dobriyan wrote:
On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote:
I'm announcing an alternative firewire stack that I've been working on
the last few weeks.
Is mainline firewire so hopeless, that you've decided to rewrite it? Could
you show some ugly places in it?
Yes
Benjamin Herrenschmidt wrote:
(bitfields as accessors to on-the-wire data)
...
> relies on the fact that it -seems- that by luck, gcc only has two
> representations around and they match little/big endian archs (though
> have we verified that is always correct, especially between 32 and 64
> bits a
On Tue, 2006-12-05 at 19:49 +0100, Stefan Richter wrote:
> Kristian Høgsberg wrote:
> > David Miller wrote:
> >> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> >>> DO NOT USE BITFIELDS FOR DATA ON THE WIRE !!!
>
> Actually we do so in some places of the existing FireWire drivers.
> Didn't go
Alexey Dobriyan wrote:
> On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote:
>> I'm announcing an alternative firewire stack that I've been working on
>> the last few weeks.
>
> Is mainline firewire so hopeless, that you've decided to rewrite it?
> Could you show some ugly places in
Kristian Høgsberg wrote:
> David Miller wrote:
>> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
>>> DO NOT USE BITFIELDS FOR DATA ON THE WIRE !!!
Actually we do so in some places of the existing FireWire drivers.
Didn't go wrong so far. :-)
>>> Where do you handle endianness ? (no need to sh
On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote:
> I'm announcing an alternative firewire stack that I've been working on
> the last few weeks.
Is mainline firewire so hopeless, that you've decided to rewrite it?
Could you show some ugly places in it?
We can end up with two not
Hi Kristian,
> >> I'm announcing an alternative firewire stack that I've been working on
> >> the last few weeks. I'm aiming to implement feature parity with the
> ...
> > can you please use drivers/firewire/ if you want to start clean or
> > aiming at replacing drivers/ieee1394/. Using "fw" as a
Hi Erik,
> > >can you please use drivers/firewire/ if you want to start clean or
> > >aiming at replacing drivers/ieee1394/. Using "fw" as an abbreviation in
> > >the directory path is not really helpful.
> >
> > Yes, that's probably a better idea. Do you see a problem with using fw_*
> > as a
David Miller wrote:
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 05 Dec 2006 16:42:42 +1100
- It's horribly broken in at least two area :
DO NOT USE BITFIELDS FOR DATA ON THE WIRE !!!
and
Where do you handle endianness ? (no need to shout for
that one).
(Or in general, d
On 12/4/06, Kristian Høgsberg <[EMAIL PROTECTED]> wrote:
Ok... I was planning to make big-endian versions of the structs so that the
endian issue would be solved. But if the bit layout is not consistent, I
guess bitfields are useless for wire formats. I didn't know that though, I
thought the C
On Tue, Dec 05, 2006 at 10:13:55AM -0500, Kristian Høgsberg wrote:
> Marcel Holtmann wrote:
> >can you please use drivers/firewire/ if you want to start clean or
> >aiming at replacing drivers/ieee1394/. Using "fw" as an abbreviation in
> >the directory path is not really helpful.
>
> Yes, that's
Marcel Holtmann wrote:
Hi Kristian,
I'm announcing an alternative firewire stack that I've been working on
the last few weeks. I'm aiming to implement feature parity with the
...
can you please use drivers/firewire/ if you want to start clean or
aiming at replacing drivers/ieee1394/. Using "
Hi Kristian,
> I'm announcing an alternative firewire stack that I've been working on
> the last few weeks. I'm aiming to implement feature parity with the
> current firewire stack, but not necessarily interface compatibility.
> For now, I have the low-level OHCI driver done, the mid-level
> tran
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 05 Dec 2006 16:42:42 +1100
> - It's horribly broken in at least two area :
>
> DO NOT USE BITFIELDS FOR DATA ON THE WIRE !!!
>
> and
>
> Where do you handle endianness ? (no need to shout for
> that one).
>
> (Or in general, do n
Benjamin Herrenschmidt wrote:
On Tue, 2006-12-05 at 00:22 -0500, Kristian Høgsberg wrote:
Hi,
I'm announcing an alternative firewire stack that I've been working on
the last few weeks. I'm aiming to implement feature parity with the
current firewire stack, but not necessarily interface compati
On Tue, 2006-12-05 at 00:22 -0500, Kristian Høgsberg wrote:
> Hi,
>
> I'm announcing an alternative firewire stack that I've been working on
> the last few weeks. I'm aiming to implement feature parity with the
> current firewire stack, but not necessarily interface compatibility.
> For now, I ha
Hi,
I'm announcing an alternative firewire stack that I've been working on
the last few weeks. I'm aiming to implement feature parity with the
current firewire stack, but not necessarily interface compatibility.
For now, I have the low-level OHCI driver done, the mid-level
transaction logic done,
37 matches
Mail list logo
