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