Frank Mayhar wrote: > Eric Anderson wrote: > >>Hmm - this was working this morning before I updated, with a -CURRENT as of last week, and I didn't notice anything in /usr/src/UPDATING. So what I should have is: >> >>ath_load="YES" >>ath_hal_load="YES" >>ath_rate_load="YES" > > > I just have > > if_ath_load="YES" > > in my /boot/loader.conf. That picks up everything. > > >>I guess what I missed (and just noticed), is that there are not individual modules for each rate algorithm now, one module (named ath_rate) that is the algorithm of whatever is built. > > > It has been this way for some time, actually. Yes, I forgot about this little "detail". As a result of my change folks using modules are now using ath_rate_sample by default. I'll deal with it. > > >>>You want to go to sys/modules/ath_rate_{amrr|onoe|sample} and do a 'make >>>install'. >> >>I did that already - but why doesn't a 'make installkernel ...' not accomplish that? (forgive my ignorance) > > > It does. It installs ath_rate.ko for each of amrr, onoe and (now) sample. > Obviously, the last one in wins. You'll have to ask Sam about what shortcoming > of the FreeBSD module system leads to this. Actually it's nothing to do with the module system. When I split the rate control code into a separate module various folks didn't want to incur the overhead of using indrect function pointers in the fast path so we used the symbol names to bind rate control support to the driver. This has many downsides and I'm not reall happy with it but since it's unlikely folks will want to run multiple algorithms concurrently I've not spent any time on the issue. > > >>>Hmm. Is ath_rate_sample linked properly? >> >>How can I help you determine that? (is readelf -a output what you want?) > > > Already fixed; read your -current email. Yes, Tai-hwa fixed my botch (I'd tested only with a statically linked kernel). SamReceived on Fri Mar 11 2005 - 18:11:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:29 UTC