lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 4 Mar 2007 20:04:25 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Tilman Schmidt <tilman@...p.cc>
Cc:	LKML <linux-kernel@...r.kernel.org>, nigel@...el.suspend2.net,
	Pavel Machek <pavel@....cz>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: Suspend/resume semantics for ISDN drivers (was: NAK new drivers without proper power management?)

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ