Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Jan 2015 10:01:03 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        Hans Petter Selasky <hps@selasky.org>, arch@freebsd.org
Subject:   Re: devctl(8): A device control utility
Message-ID:  <11219A27-4C5B-4429-8847-3E54F9C4CD1E@bsdimp.com>
In-Reply-To: <54B3F349.9050703@FreeBSD.org>
References:  <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54AAF60A.9070609@FreeBSD.org> <54AAFAEB.2090505@selasky.org> <6155572.yV5dxPJznD@ralph.baldwin.cx> <54B3F349.9050703@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_D6493F37-45A7-4144-A238-62995AB12EF8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jan 12, 2015, at 9:16 AM, John Baldwin <jhb@FreeBSD.org> wrote:
>=20
> 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).
>>>>>>=20
>>>>>> Do folks have any feedback?
>>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> 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!
>>>>=20
>>>> 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).
>>>=20
>>> Hi,
>>>=20
>>> 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.
>>=20
>> 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.
>=20
> 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=E2=80=99t need them because as the bus author, I know =
when these
events happened and could take appropriate actions for the bus. I =
didn=E2=80=99t 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

--Apple-Mail=_D6493F37-45A7-4144-A238-62995AB12EF8
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUs/3PAAoJEGwc0Sh9sBEArfwP/2oRtY/d7tvFxbZ4C5+w77tt
MPzQhy2V21ehXlba3oPiefx7Nck8XV8koW4W44VuxFKw84q477TOnUPsMGK/3JN4
cQw6WUXcWn7Z8kAmd3dQv3UGSnO44Tg64WFYdTSczluqOvBxocGGY9d5WaC2U/Qo
lG99tq7xwcwmvNYz4Hw2DkN5puwJ38IXyFyDl826oz9JIuKhCToRSOncWLIpJfPL
4B9LxZeGyY4f1XXn1ABQiRHk6osGvAf0VEMrUyyRQ3BYAwNyGFesoOJU3FGc1a1i
VTHrdKgp8MZNAzKw4IbNeYOCPkhYVOAE1VbKxx4GsKLKJ6Sm1vS3IxoKXDJup+1S
IvDeVXKI9P4yalyVu2llaT116mYaaxJ2jj9hZT2woFIPy5qg753SfTSK3zVBHpwe
OWbbSguFILcbSh4hxBRxbsMVySeL+CQ4VOgzG+V0MLb7+hyQG0DbWJENRdNuRxNe
MYO6Zwwltwk81CE6GiTlzT26+trWKyUsqQ4EONLs1FTq3E8JBwYb1MYWKXLtFV4h
97bCzkdf880jrb89gOAEaASvEiCyJCyMbPYSVrwpR+bTyTDJK6FYWeBiSXu4G3hk
q7Dl7xJkuiydodNLNlk2jLCD/6gbCGpHu1TfiKZqmMseyIt3huoOMtuTs+4NTiqf
zXEFtYopM+QNnVqkx0w0
=Wv8m
-----END PGP SIGNATURE-----

--Apple-Mail=_D6493F37-45A7-4144-A238-62995AB12EF8--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11219A27-4C5B-4429-8847-3E54F9C4CD1E>