devctl(8): A device control utility

[Warner Losh]

> On Jan 12, 2015, at 3:01 PM, John Baldwin <jhb at FreeBSD.org> wrote:
> 
> On 1/12/15 12:01 PM, Warner Losh wrote:
>> 
>>> On Jan 12, 2015, at 9:16 AM, John Baldwin <jhb at FreeBSD.org> wrote:
>>> 
>>> On 1/5/15 4:18 PM, John Baldwin wrote:
>>>> On Monday, January 05, 2015 09:58:19 PM Hans Petter Selasky wrote:
>>>>> On 01/05/15 21:37, John Baldwin wrote:
>>>>>> On 1/5/15 3:13 PM, Hans Petter Selasky wrote:
>>>>>>> On 01/05/15 21:01, John Baldwin wrote:
>>>>>>>> The devctl(8) utility is then a thin wrapper around libdevctl (and
>>>>>>>> does not
>>>>>>>> yet have a manpage).
>>>>>>>> 
>>>>>>>> Do folks have any feedback?
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> In the USB area attach and detach must be synchronized to the USB stack
>>>>>>> and "usbconfig -d X.Y set_config Z" or "usbconfig -d X.Y reset" should
>>>>>>> be used to avoid races attaching and detaching drivers!
>>>>>> 
>>>>>> I think this points to one or more missing bus methods so that the bus
>>>>>> can hook into device_probe_and_attach() to reset a device as needed.
>>>>>> (e.g. if you had bus_probe_started / bus_probe_finished and possibly
>>>>>> similar methods for attach.  PCI could use a bus_attach_finished()
>>>>>> callback so that it could clean up any dangling resources and possibly
>>>>>> power down on a failed attach the way it does in bus_child_detached as
>>>>>> well).
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> USB has its own threads to allocate/free devices. Another problem is how
>>>>> to atomically get a reference count across multiple layers like PCI and
>>>>> USB. It doesn't allow probe/attach when called from outside these threads.
>>>> 
>>>> That just means you need to use some locks. :)  Cardbus also uses an event
>>>> thread to handle auto-attach of devices when it detected a card change event,
>>>> but that doesn't prevent it from servicing an ioctl request.
>>> 
>>> Another option btw would be to add bus methods that wrap probe and
>>> attach (rather than pre and post event hooks).  I wish bus_add_child()
>>> were done this way such that device_add_child_ordered() were renamed to
>>> bus_generic_add_child() (and was the default add_child method) and that
>>> device_add_child_ordered() called 'BUS_ADD_CHILD()' so that
>>> 'device_add_child()' was the proper public API (instead of exposing
>>> BUS_ADD_CHILD()).  Similarly, I think that 'device_attach()' and
>>> 'device_probe_and_attach()' should be the public API and that one way or
>>> another we should add hooks to allow bus drivers to modify their
>>> behavior if needed.  However, they should be fine for devctl ioctls to
>>> invoke as well as other kernel bits.
>> 
>> When I was doing CardBus and PC Card I wished for similar things.  Then
>> I realized I didn’t need them because as the bus author, I know when these
>> events happened and could take appropriate actions for the bus. I didn’t have
>> that atomic access issues though, since as the bus author I also controlled how
>> and when mutexes were taken out and when I allowed access to the bus. I
>> only used mutexes in CardBus and PC Card because most of the sleeps were
>> short, but other ways to do locking are quite possible...
> 
> I think the problem here is that devctl introduces events that happen
> without the bus's knowledge.

When we did the kludge sysctl power stuff for cardbus (which was never committed), we sent
a message to the bus to tell it to do the power off and cope with whatever else was needed. There
were times that it couldn’t comply, iirc, so this ‘command’ allowed errors to be returned for things
that were forbidden / not allowed for some reason at the time rather than getting a message that
this thing happened and we had to mop up now.

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20150114/2d62e927/attachment.sig>