Date: Fri, 06 Feb 2015 18:46:06 -0500 From: John Baldwin <jhb@freebsd.org> To: John-Mark Gurney <jmg@funkthat.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r278320 - in head: contrib/mdocml lib lib/libdevctl share/mk sys/dev/acpica sys/dev/pci sys/kern sys/sys usr.sbin usr.sbin/devctl Message-ID: <4184164.aqiB2fMKGA@ralph.baldwin.cx> In-Reply-To: <20150206233012.GY32312@funkthat.com> References: <201502061609.t16G92rn091851@svn.freebsd.org> <61974401.Fd0kRqNeQd@ralph.baldwin.cx> <20150206233012.GY32312@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, February 06, 2015 03:30:13 PM John-Mark Gurney wrote: > John Baldwin wrote this message on Fri, Feb 06, 2015 at 11:58 -0500: > > On Friday, February 06, 2015 04:09:02 PM John Baldwin wrote: > > > Author: jhb > > > Date: Fri Feb 6 16:09:01 2015 > > > New Revision: 278320 > > > URL: https://svnweb.freebsd.org/changeset/base/278320 > > > > > > Log: > > > Add a new device control utility for new-bus devices called devctl. > > > This > > > allows the user to request administrative changes to individual > > > devices > > > such as attach or detaching drivers or disabling and re-enabling > > > devices. > > > > For now I would consider this somewhat experimental. Some bus drivers may > > not take kindly to device_detach/device_probe_and_attach being called > > (Hans mentioned USB as a likely candidate). > > > > Also, in theory you can use 'devctl suspend' to power off PCI devices you > > don't need, but most drivers probably don't expect to have to deal with > > user requests while suspended (e.g. I tested this by suspending hdac0 on > > a laptop, but I didn't try playing a sound to see if that blew up.. it > > would not surprise me if it did). > > > > There are also some other rough edges such as: > > 1) An administratively suspended device will resume if you do a > > system-wide > > > > suspend and resume. > > Could we add a flag for this? Yes, it just isn't done as of yet. > > 2) There is no nice way for a driver to reject an administrative suspend > > > > request. It could fail its device_suspend method perhaps, but the > > driver > > can't easily tell if a suspend request is administrative or due to a > > system suspend. Perhaps we could re-use device_quiesce for this? > > We should look at expanding this... For the PCIe hot plug work, we > definately want administrative suspention to work so that people can > unplug their devices, or get notification that it is rejected (say, > disk is still mounted)... > > Also, looks like quiesce will be rejected if the device is busy... > That should be changed or at least clearer description of what > device_busy is suppose to do to a device... > > The good news is that very few drivers make use of device_busy, so > cleaning it up, or removing it won't be too hard... Drivers are free to define their own device_quiesce method. device_quiesce is what can reject a non forced (no -f) kldunload. So for detach the semantics are: device_quiesce fails if the device is busy, device_detach should be a best effort that should detach even if the device is busy. A "nice" detach request honors device_quiesce. A forced detach request ignores device_quiece and always invokes device_detach. I suspect reusing device_quiece to handle a "nice" vs forced suspend request will work just fine as the conditions for rejecting detaching are the same as for suspension. Also, for hotplug removal you want detach, not suspension anyway (which already uses device_quiesce and thus already supports this notion). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4184164.aqiB2fMKGA>