Re: NetBSD kernel modules.

[Piotr Adamus <panpiotradamus%gmail.com@localhost>]

Hello all,

thank you for your time and replies.

I was user of NetBSD since 3.0 until the the quite current 5.99.XX. I
will provide the dmesg and other tomorrow.

I do use suspend- it is useful. But on Linux (FreeBSD doesn't wake-up
for me at all).

@iain

I wouldn't be bothered about loosing connection- as John said as well.

@John

I was afraid that there is not too much work done on modules. I will
try the drvctl tomorrow and report.


Let me report my findings tomorrow- thanks one more time.

Kr,

Piotr.


On Tue, Dec 7, 2010 at 10:16 PM, John Nemeth <jnemeth%victoria.tc.ca@localhost> 
wrote:
> On Mar 25,  7:15am, Iain Hibbert wrote:
> } On Tue, 7 Dec 2010, John Nemeth wrote:
> } > On Apr 28, 10:22am, Piotr Adamus wrote:
> } > }
> } > } I have one simple question: is it possible to compile these drivers
> } > } into modules only: sdhc, ubt, uaudio? At this moment I don't have
> } > } NetBSD installed. These drivers don't have suspend support enabled.
> } >
> } >      There is a module for uaudio, but there are no modules for sdhc
> } > and ubt.  Kernel modules are a work in progress and driver modules even
> } > more so.  You're best bet if you don't need them, is to remove them
> } > from your kernel.
> }
> } I am not sure but in the old days (when I wrote ubt), there was not really
> } any need for specific suspend support in ubt because USB devices were just
> } detached upon suspend events. Is the USB stack any different now? I
> } confess, I don't use suspend.
>
>     I don't know the USB stack.  However, I just looked at ubt.c and I
> see that Christos added NULL suspend and resume handlers in rev. 1.30,
> which is between NetBSD 4.x and NetBSD 5.x.
>
>     Piotr, what version of NetBSD are you running?  Also, can you
> execute this command, please:  "ident /netbsd | grep ubt".
>
> } In any case, there is plenty of state about the current Bluetooth
> } connections that is held inside the controller and would be lost if the
> } device was powered down with no way that I know of to reinstate it, not to
>
>     In that case, you should probably create suspend and resume
> routines to save and restore the necessary data.
>
> } mention that devices would likely be out of range after awakening, so I
> } don't really know how much code would be useful there anyway.
>
>     Maybe, maybe not.  Equipment doesn't necessarily move while being
> suspended (or, if it does move, the Bluetooth device might move with
> it, i.e. a mouse or a keyboard).  And, with Bluetooth, devices can
> move in and out of range at random times, so this needs to be handled
> anyways.
>
> }-- End of excerpt from Iain Hibbert
>