cvs commit: src/share/man/man4 Makefile rr232x.4
src/sys/dev/rr232x
LICENSE README amd64-elf.rr232x_lib.o.uu array.h him.h himfuncs.h
hptintf.h i386-elf.rr232x_lib.o.uu ldm.h list.h os_bsd.c os_bsd.h
osm.h osm_bsd.c rr232x_config.c ...
Scott Long
scottl at samsco.org
Tue May 2 03:41:28 UTC 2006
Fair enough, I'll give this a try and see what happens.
Scott
Maxim Sobolev wrote:
> IMHO it is misleading, since FreeBSD users get used to the fact
> that the driver only announces itself if actual hardware is present
> in the system. With number of supported devices in GENERIC growing
> up dmesg will eventually turn into mess if each device driver will
> announce itself unconditionally.
>
> At the very least, please put those printf's under if (bootverbose).
>
> -Maxim
>
> On Mon, May 01, 2006 at 08:32:37PM -0600, Scott Long wrote:
>
>>Sam Leffler wrote:
>>
>>>Scott Long wrote:
>>>
>>>
>>>>Sam Leffler wrote:
>>>>
>>>>
>>>>>Scott Long wrote:
>>>>>
>>>>>
>>>>>>The architecture of the driver makes this a request hard to do. I
>>>>>>don't like it, but there is precedence already with the ath driver.
>>>>>
>>>>>
>>>>>
>>>>>I'm guessing you're referring to ath bailing if the hal could not be
>>>>>attached or the card otherwise setup? If so the card was actually
>>>>>recognized and failure to complete the attach is totally separate.
>>>>>
>>>>>ath doesn't print anything during probe.
>>>>>
>>>>> Sam
>>>>
>>>>
>>>>I thought that the ath hal printed a line early in boot with the
>>>>version number.
>>>
>>>
>>>The hal is a separate module. It prints it's version string on module
>>>load. I can put it under bootverbose if desired but it's way useful to
>>>tell people to send me:
>>>
>>>dmesg|grep ath
>>>
>>>and get the hal version and mac+phy revs for the hardware.
>>>
>>> Sam
>>
>>The same is basically true of rr232x, though there is no module
>>separation of HAL vs OSM like with ath.
>>
>>Scott
>>
More information about the cvs-src
mailing list