devctl(8): A device control utility

Warner Losh imp at bsdimp.com
Mon Jan 12 17:01:13 UTC 2015


> 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...

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/20150112/9675356d/attachment.sig>


More information about the freebsd-arch mailing list