[Prism54-devel] Re: wireless API semantics when netif down?

[Luis R. Rodriguez]

I personally feel that we shouldn't be burdening Linux wireless driver
developers with "hackish" workarounds just so that drivers work flawlessly
around Distribution network scripts.

Why not get things straight and define semantics that *should and are
proper* ways for a driver to work and then just have the Distributions
fix/update their scripts?

=09Luis

On Wed, 26 Nov 2003, Herbert Valerio Riedel wrote:

> On Tue, Nov 25, 2003 at 07:10:55PM -0800, Jean Tourrilhes wrote:
> > On Tue, Nov 25, 2003 at 11:25:32AM +0100, Herbert Valerio Riedel wrote:
> > > On Tue, Nov 25, 2003 at 10:54:26AM +0100, Bj=F8rn Mork wrote:
> > > [..]
> > > > The best solution would of course be if the driver could report the
> > > > real mac address even before the interface is up.
> > > [..]
> > >
> > > alas this requires the firmware to have been uploaded and be operatio=
nal;
> > > something that'd be easiest/best to do at ifup time...
> >
> > =09I know, that's why I told you about it.
>
> while at it, I'll try to paraphrase what I got from you, and formulate
> it as a TODO-kinda-list (with some embedded questions to you to
> answer) for the short term future :-)
>
> *) we need to duplicate most objects in the MIB in our private driver
>    struct (partlally done by me some weeks ago) and try best-effort to
>    make it syncronized with the firmware's MIB (to be improved)
>
> *) when the device is down,
>    . the IW handlers should succeed in setting values (do they 'return
>      0' or 'return EINPROGRESS' in that case)? (btw, which patch for
>      orinoco were you referring to?), and copy them to our private MIB-mi=
rror
>
>    . what shall we do, when on ifup some of the setted values in our
>      private MIB-mirror should show up as being rejected by the firmware
>      as being invalid?
>
>    . the values we return on queries are those in our private MIB-mirror.=
=2E.?
>      (what else could make sense?)
>
> *) when the device get's up, we restore settings in our MIB (partially
>    done as well); what do if some settings are invalid? let ->open fail?
>    update our MIB-mirror with the values the firmware now actually has se=
t?
>    should ->open delay until all settings are restored, or should it
>    return immediately while the restoration continues in background?
>
>    shall we care about calling netif_carrier_on/off? would this help
>    applications in userspace? would dhcpd wait until carrier is on?
>
>    after initialization has been completed, we can start passing
>    user-requests/queries to firwmare, instead of operating only on our
>    MIB copy; but while in initialization phase, how shall we block/delay
>    user-requests? delay the ioctl() caller, or simply let it fail? or
>    even succeed without effect?
>
> *) when device is up,
>    . on queries, we return just the copy in the MIB, assuming we have
>      the the mirror syncronized; or maybe we really query the firmware, a=
nd
>      while at it, we update the MIB mirror (if the value should have
>      changed without our knowledge... which actually would be bad for som=
e
>      values which aren't supposed to change without our intervention...)
>
>    . when setting values, now we can finally test immediately whether
>      the arguments are valid; and return this directly to the userspace c=
aller
>
>
> ...ok, enough questions for now, I surely forgot to write down some of
> the ones I had on my mind while reading your long reply... ;-)
>
> ...btw, is there some wlan/linux-driver-writing-guidelines document?
>
> > > it's quite annoying to have such a large firmware, which needs to be
> > > loaded from time to time, and which for now has to reside on the
> > > filesystem...
> > =09Probably better than having to reside in kernel memory (non
> > swapable).
>
> indeed... alas this makes in-kernel ip-autoconfiguration out of reach...
>
> > =09By the way, do you have any plan to merge into 2.6.X, or do
> > you plan to remain standalone ?
>
> well, I guess I can speak for the rest of the team, that we
>  want to get the driver merged into the stock kernel sooner or later;
> but honestly the driver is far from being ready for that...
>
> on the other hand, being so dependant on a proprietary firmware, which
> _seems_ to be the source of some bugs, we might never get a rock-solid
> driver worth being included in 2.6.x :-(
>
> btw, there's one major bug right now which we have a real hard time
> pinning down: it seems to be powermanagement related, especially when
> acpi is inolved, the card tends to hang hard which requires it to be
> completely powered down to be reset at all... there's been a
> suggestion, it might have to do with bus-mastering and entering C3
> state... any ideas/hints where else to look at?
>
> regards,
> --
> Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
> Email: hvr@hvrlab.org       /    Finger hvr@gnu.org for GnuPG Public Key
> GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F 4142
> _______________________________________________
> Prism54-devel mailing list
> Prism54-devel@prism54.org
> http://prism54.org/mailman/listinfo/prism54-devel
>