[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD kernel modules.
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).
I wouldn't be bothered about loosing connection- as John said as well.
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.
On Tue, Dec 7, 2010 at 10:16 PM, John Nemeth <jnemeth%victoria.tc.ca@localhost>
> 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
> }-- End of excerpt from Iain Hibbert
Main Index |
Thread Index |