[haiku-commits] Re: r35008 - in haiku/branches/developer/colin/wireless: headers/posix/sys headers/private/net src/add-ons/kernel/network/devices/ieee80211 src/add-ons/kernel/network/devices/ieee80211/stack
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 15 Jan 2010 13:30:00 +0100
Colin Günther <coling@xxxxxx> wrote:
> Axel Dörfler schrieb:
> > So the BIeee80211Request is more or less what ifreq is for the
> > usual
> > stuff? Or is it a convenience class wrapping the latter?
> There will be a ieee80211req structure for managing the wifi stack,
> the
> same way as freebsd does it. This structure is the cousin of the
> ifreq
> structure. The BIeee80211Request, is meant to be a nice Wrapper for
> userland tools, as handling of those ieee80211req can get quite
> cumbersome.
> So this wrapper class idea is not set in stone, yet. For now the
> mentioning of this class shall just tell that there will be an extra
> wifi request data structure.
I like the idea of a wrapper class - it doesn't even have to be public,
though, ie. a shared class would be okay for a start.
> > But that driver is already the one implementing support for a
> > specific
> > hardware, right? You will only implement (ie. subclass) the
> > BIeee80211Device and fill in the missing parts.
> > Do I understand that one correctly?
> Lets say, it is the place where the hardware specific part will be
> implemented. But the BIeee80211Device class I have in mind, provides
> only some default implementations a la
>
> BIeee80211Device::GetSupportedChannels()
> {
> return B_ERROR;
> }
> As this class can't know which channels a specific hardware supports.
> So
> I would tell it a WiFi driver framework. This might represent the
> concept better than the term "class".
Yes, that makes sense. As I said, I like this concept.
Maybe something similar could be done for the driver architecture as
well (even though it's probably less rewarding there, and would mostly
be a way to write it differently).
> >> Well I wasn't aware of it that explicitly. I aiming towards a
> > > static
> >> kernel library for the BIeee80211Device, though.
> > We just don't have shared library support in the kernel - if you
> > want
> > to inherit from a C++ class, it would either be statically linked
> > or
> > part of the kernel.
> Oh, i thought by using static libraries, statically linking is
> implicit.
> I think I'm just to much compat layer trained. So, statically linking
> of
> a static library is what I have in mind for the WiFi driver
> framework.
Nah, you're right - linking a static library is what I called
statically linked.
Bye,
Axel.
Other related posts:
