On Saturday, 3 March 2007 23:48, Tilman Schmidt wrote: > Ok, I've thought some more but I still don't know ... > > On 12.02.2007 01:10 I wrote: > > I don't doubt your basic assessment. However it doesn't translate that > > easily into a real implementation. In my case, I maintain a USB driver, > > so I have to deal with USB specifics of suspend/resume which happen not > > to be that well documented. My driver provides an isdn4linux device but > > isdn4linux knows nothing about suspend/resume so I am on my own on how > > to reconcile the two. The device itself, though in turn far from trivial, > > is actually the least of my worries. > > So, how *should* an isdn4linux driver handle a request to suspend? > Specifically, if there are active connections, should it try to > shut them down in an orderly fashion (which might imply some delays > waiting for the remote station to acknowledge, etc.)? Should it kill > them abruptly (as for a USB unplug event)? Or should it just refuse > to suspend while a connection is still active?
I think that refusing to suspend wouldn't be a good approach (think of an emergency suspend when the battery is running low). Probably the closing of connections would be the nicest thing from the user's point of view. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
