Hey guys,
let me first introduce myself. I'm Patrick Steinhardt, student of
information technology at the Free University of Berlin, Germany,
in the 6th term of the bachelor degree course. As a side job I am
employed by the IVU Traffic Technologies AG since two and a half
years, developing enterprise software in C, C++ and Java.
I am interested in applying for the Google Summer of Code at the
Linux Foundation. I've always been interested in getting in touch
with low level programming and the Linux kernel but because of
the seeminlgy high hurdle of getting into it I never dared to
start. That's why I see a great chance for me to get into kernel
programming through the GSoC program, encouraging me to dive into
the unknown and getting help wherever I need it.
My point of interest with the wireless code is especially the b43
driver. I own a relatively old Macbook with a Broadcom 14e4:432b
wireless card. To be honest, it doesn't really work well with the
b43 driver. But as I do not want to rely on the proprietary wl
driver indefinitly I'd like to improve b43 to fully handle my
card.
My current relevant skillset unfortunately only includes
experience with C, various relating tools (gdb, valgrind,
perf) and some x86 assembler. But I've got no exprience with
wireless technology (even though I'm currently visiting a lecture
which covers low level wireless technologies like wireless LAN)
or hardware near programming.
Do you think it is possible to get into the topic fast and deep
enough to accomplish my goals? Are there any other thoughts or
culprits I should take into account?
Regards,
Patrick
Hi,
thanks for your insights, I'll stay away from GSoC with that
idea, then.
I'd still be interested in doing some work but got no idea where
to start. Any recommendations for some resources I might
investigate to get going?
Regards,
Patrick
On Mon, Apr 15, 2013 at 12:36:06PM +0200, Rafał Miłecki wrote:
> 2013/4/13 Larry Finger <[email protected]>:
> > I think that your coding experience makes you qualified to undertake the
> > coding necessary to improve the performance of b43 on the 14e4:432b device;
> > however, I recommend that you not attempt it as a GSoC project. The reason
> > is that those projects are highly visible, and what you are trying to do is
> > very difficult. The actual coding is likely not a problem, but knowing what
> > to code is not trivial. I would hate for you to fail in a way that would be
> > so completely obvious.
> >
> > As you probably know, b43 has been developed using reverse engineering (RE)
> > techniques. We have no knowledge of the internal workings of the chips.
> > Since the LP-PHY, more and more has been required by the driver. Earlier PHY
> > models did quite a lot in the firmware. With the N PHYs such as your device
> > has, the problem got even worse. and the implementation is more incomplete.
> > For instance, implementation of power regulation in the wireless chip has
> > barely been touched.
> >
> > At the moment, I am the only person doing any of the RE work, and I have
> > relatively little time to work on that. Much of the more recent development
> > has come from comparing MMIO dumps between wl and b43 to see what parts are
> > missing from b43. That requires an extremely good knowledge of the existing
> > driver, and that would take a long time to acquire.
> >
> > The b43 project welcomes your interest, and I hope you pursue it eventually,
> > but I still think you should find another project for the GSoC.
>
> I would love to see extra developer in b43 project, but I have to
> confirm what Larry has said. It's hard task and we're really missing
> specifications for the hardware.
>
> There are few things that should be easy to add, like 5GHz support
> (most of the code is already there, it just needs enabling & testing)
> or maybe even (some) 802.11n features.
>
> Further improvements unfortunately are much more complicated or even
> impossible due to lack of documentation.
>
> You can try doing MMIO tracking and comparing with closed source
> driver, but it's not trivial and doesn't guarantee you'll notice
> important differences (not to mention understanding them).
>
> --
> Rafał
Patrick,
I think that your coding experience makes you qualified to undertake the coding
necessary to improve the performance of b43 on the 14e4:432b device; however, I
recommend that you not attempt it as a GSoC project. The reason is that those
projects are highly visible, and what you are trying to do is very difficult.
The actual coding is likely not a problem, but knowing what to code is not
trivial. I would hate for you to fail in a way that would be so completely obvious.
As you probably know, b43 has been developed using reverse engineering (RE)
techniques. We have no knowledge of the internal workings of the chips. Since
the LP-PHY, more and more has been required by the driver. Earlier PHY models
did quite a lot in the firmware. With the N PHYs such as your device has, the
problem got even worse. and the implementation is more incomplete. For instance,
implementation of power regulation in the wireless chip has barely been touched.
At the moment, I am the only person doing any of the RE work, and I have
relatively little time to work on that. Much of the more recent development has
come from comparing MMIO dumps between wl and b43 to see what parts are missing
from b43. That requires an extremely good knowledge of the existing driver, and
that would take a long time to acquire.
The b43 project welcomes your interest, and I hope you pursue it eventually, but
I still think you should find another project for the GSoC.
Larry
2013/4/13 Larry Finger <[email protected]>:
> I think that your coding experience makes you qualified to undertake the
> coding necessary to improve the performance of b43 on the 14e4:432b device;
> however, I recommend that you not attempt it as a GSoC project. The reason
> is that those projects are highly visible, and what you are trying to do is
> very difficult. The actual coding is likely not a problem, but knowing what
> to code is not trivial. I would hate for you to fail in a way that would be
> so completely obvious.
>
> As you probably know, b43 has been developed using reverse engineering (RE)
> techniques. We have no knowledge of the internal workings of the chips.
> Since the LP-PHY, more and more has been required by the driver. Earlier PHY
> models did quite a lot in the firmware. With the N PHYs such as your device
> has, the problem got even worse. and the implementation is more incomplete.
> For instance, implementation of power regulation in the wireless chip has
> barely been touched.
>
> At the moment, I am the only person doing any of the RE work, and I have
> relatively little time to work on that. Much of the more recent development
> has come from comparing MMIO dumps between wl and b43 to see what parts are
> missing from b43. That requires an extremely good knowledge of the existing
> driver, and that would take a long time to acquire.
>
> The b43 project welcomes your interest, and I hope you pursue it eventually,
> but I still think you should find another project for the GSoC.
I would love to see extra developer in b43 project, but I have to
confirm what Larry has said. It's hard task and we're really missing
specifications for the hardware.
There are few things that should be easy to add, like 5GHz support
(most of the code is already there, it just needs enabling & testing)
or maybe even (some) 802.11n features.
Further improvements unfortunately are much more complicated or even
impossible due to lack of documentation.
You can try doing MMIO tracking and comparing with closed source
driver, but it's not trivial and doesn't guarantee you'll notice
important differences (not to mention understanding them).
--
Rafał