On Sun, 16 Dec 2007 10:40:07 -0500 (EST)
"Jared D. McNeill" <jmcneill@invisible.ca> wrote:

> On Sun, 16 Dec 2007, Steven M. Bellovin wrote:
> > It's not clear to me that it's really a work-around, as opposed to a
> > solution that leverages code that's already there.  Remember that I
> > have two different needs: certainly, the desire to improve NetBSD,
> > but also the need for a stable, full-function platform that I can
> > use to get my day job done.  My question was addressing the latter.
> 
> Your solution satisfies neither.
> 
> Most of our device drivers don't even support detaching; you'll have
> to write code anyway. If you detach the driver and reattach it on
> resume, there is little chance of the hardware working properly.

That's a fair statement, though I'll note that I've long used detach
before removing my PCMCIA EVDO modem -- simply removing the card (after
closing all devices, of course) had too high a chance of crashing the
system.  I've never tried reattaching, as opposed to removing and
reinserting the card.
> 
> You're aware that this is the development branch of NetBSD, right?
> 
Sure.  I'm contemplating it for my laptop only because I have no other
choices; there are no other Unix-like systems that support my
configuration any better in their stable branches, either.  I run
-current on my laptop in a fairly conservative fashion -- I upgrade my
desktop machines first, because given my usage patterns they're less
critical.  

I'll repeat publicly what I've said privately.  Given my day job
schedule -- and given that my T42 is out of warranty and exhibiting
signs of hardware failure -- I have about five weeks to move my primary
work environment to *something*.  I'd much rather it were NetBSD, for
reasons of aesthetics, experience, and compatibility with all of my
other machines, but my ability to actually *use* the machine is more
important.  I can do without things like dual core, audio and the audio
buttons, and the built-in EVDO modem.  I can't do without
suspend/resume, wireless, and at least one working USB port.  (Linux
has problems with two of the three ports on this model.  The problem is
*not* understood, though it seems to manifest itself as an interrupt
storm causing the kernel to disable the ports.  For reasons that are
equally mysterious, the third port isn't affected by all this.)

		--Steve Bellovin, http://www.cs.columbia.edu/~smb