the latest modification of src/sys/dev/hotplug.c (1) changes hotplug(4)
behaviour concerning devices that are attached before the hotplug device
is opened (by hotplugd(8), for example). such devices are ignored in
hotplug.c by hotplug_put_event because of !evqueue (line 92 in -current). 

since the commit messages says nothing about behaviour change I suggest
the following patch to restore the old behaviour:


Index: hotplug.c
===================================================================
RCS file: /cvs/src/sys/dev/hotplug.c,v
retrieving revision 1.10
diff -u -r1.10 hotplug.c
--- hotplug.c	2 Dec 2010 04:12:35 -0000	1.10
+++ hotplug.c	11 Dec 2010 19:00:09 -0000
@@ -90,7 +90,8 @@
 		return (1);
 	}
 	if (!evqueue)
-		return (1);
+		evqueue = malloc(sizeof(*he) * HOTPLUG_MAXEVENTS, M_DEVBUF, \
+		    M_WAITOK);
 
 	evqueue[evqueue_head] = *he;
 	evqueue_head = EVQUEUE_NEXT(evqueue_head);


yes, the malloc thing is now done in hotplug_put_event() as well as
hotplugopen(), but this well reflects reality: hotplug can be opened
first and hotplug can receive an event first. 

the message below went to misc@, no responses.

(1)
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/hotplug.c.diff?r1=1.9;r2=1.10
by tedu, ``make hotplug queue dynamic, allowing us to increase size
without waste. ok deraadt kettenis miod''


[ message continues ]

You can't do this, because sleeping in this function would be bad.

You shouldn't need to handle hotplug events before the daemon is
running, just have the normal startup scripts deal with it.  Not
receiving old events actually prevents problems where the device is
both attached and detached before hotplugd is running.

Sorry, I missed your previous email.

[ message continues ]

The behaviour change in hotplug(4)/hotplugd(8) after your commit makes
it more ``hot plug'', actually. What bothers me (but not many others,
obviously) is the fact that the behaviour change is undocumented. Four
places come to my mind:
1) a comment in hotplug.c with appropriate commit message.
2) hotplug(4) man page, ``When a device attaches or detaches, the
   corresponding event is queued'' should (suggestion) read ``Once the
   device is opened by userland, when a device attaches or detaches, the
   corresponding event is queued.'' (I am not a native speaker, so
   please correct me!)
3) hotplugd(8) man page, make
   ``The hotplugd daemon monitors the hotplug(4) pseudo-device, acting on
   signaled events by executing the scripts in the /etc/hotplug
   directory.'' read
   ``The hotplugd daemon opens the hotplug(4) pseudo-device and thus
   enables event signaling. It then monitors the device, acting on
   signaled events by executing the scripts in the /etc/hotplug
   directory.''
4) http://www.openbsd.org/faq/current.html


I did not think this through, obviously, thanks for explaining.

[ message continues ]

That sounds good.  I was aware of the change, but didn't think anybody
would notice. :)

[ message continues ]

Missing internet link is hard to ignore ;-) (In the morning, if I've
left the pcmcia card plugged.)

[ message continues ]

See below. Commit message suggestion: "document behaviour change: no
more queueing before open to avoid problems when both attach and detach




Index: share/man/man4/hotplug.4
===================================================================
RCS file: /cvs/src/share/man/man4/hotplug.4,v
retrieving revision 1.3
diff -u -r1.3 hotplug.4
--- share/man/man4/hotplug.4	31 May 2007 19:19:50 -0000	1.3
+++ share/man/man4/hotplug.4	13 Dec 2010 11:29:30 -0000
@@ -31,7 +31,8 @@
 .Nm
 pseudo-device passes device attachment and detachment events to
 userland.
-When a device attaches or detaches, the corresponding event is queued.
+Once the device is opened by userland, when a device attaches or detaches, 
+the corresponding event is queued.
 The events can then be obtained from the queue through the
 .Xr read 2
 call on the

Index: usr.sbin/hotplugd/hotplugd.8
===================================================================
RCS file: /cvs/src/usr.sbin/hotplugd/hotplugd.8,v
retrieving revision 1.10
diff -u -r1.10 hotplugd.8
--- usr.sbin/hotplugd/hotplugd.8	20 Mar 2009 17:53:14 -0000	1.10
+++ usr.sbin/hotplugd/hotplugd.8	13 Dec 2010 11:26:51 -0000
@@ -26,9 +26,11 @@
 .Sh DESCRIPTION
 The
 .Nm
-daemon monitors the
+daemon opens the
 .Xr hotplug 4
-pseudo-device, acting on signaled events by executing the scripts in the
+pseudo-device and thus enables event signaling.
+It then monitors the device, acting on signaled events by executing the 
+scripts in the
 .Pa /etc/hotplug
 directory.
 By default it uses the

Index: sys/dev/hotplug.c
===================================================================
RCS file: /cvs/src/sys/dev/hotplug.c,v
retrieving revision 1.10
diff -u -r1.10 hotplug.c
--- sys/dev/hotplug.c	2 Dec 2010 04:12:35 -0000	1.10
+++ sys/dev/hotplug.c	13 Dec 2010 11:41:59 -0000
@@ -89,6 +89,13 @@
 		printf("hotplug: event lost, queue full\n");
 		return (1);
 	}
+
+	/* 
+	 * Do not queue events prior to hotplugopen anymore. This prevents 
+	 * ...
[ message continues ]

A bit late to the game, but I don't really agree with Tedu that the
changed behaviour is an improvement.  Say I have configured
hotplugd(8) such that it automatically mounts things when I plug in my
camera.  Now I reboot my machine, without unplugging the camera.
Previously hotplugd(8) would remount things upon boot.  Now suddenly


But this just seems to change the wording without actually changing

Adding comments like this, describing historical behaviour really
isn't such a good idea.

[ message continues ]

I thought it would make clear that only starting hotplugd enables the

That is beyond my competence.

[ message continues ]

On Mon, 13 Dec 2010 14:28:42 +0100, MERIGHI Marcus

Maybe a bit aggressive, but why not something like this in put_event :

if (!opened && event.type == DETACH) {
 foreach (ev in event_queue)
    if (ev.type == ATTACH && ev.devclass == event.devclass &&
       ev.devname == event.devname)
        remove(ev);
} 

So we remove all attached then detached devices before hotplugd is

[ message continues ]

On Mon, Dec 13, 2010 at 7:41 AM, Mark Kettenis <mark.kettenis@xs4all.nl>

I think the solution to that is to make adding the duid to fstab work.
 At boot, if the duid exists, it's mounted.  If it doesn't, it doesn't
mount but also doesn't error out.  This may already work even, I
haven't tried it.

For example, network interfaces plugged in at boot just work without
hotplug support.  If the device is present, hostname.if is run.  If
not, no error.  I think disks should work the same way.

[ message continues ]

Sorry, but a FAT-formatted USB device (which most cameras effectively
are) will never have a duid.

[ message continues ]

On Mon, Dec 13, 2010 at 3:27 PM, Mark Kettenis <mark.kettenis@xs4all.nl>

Surely there is something on the disk that can be used to formuate
one?  I mean, people have to write hotplug scripts that figure this
out, don't they?  Why make it so hard?

[ message continues ]

FAT has volume labels; I'm not saying that too much hackery would be
desirable, but it's not impossible to abuse these as a kind-of-duid.

		Joachim

[ message continues ]

I echo Mark's sentiments, though for a different reason.

Softraid crypto volumes take time to fsck, yet are useful to use.

In my case I can wait 20+min for my personal laptop to be useful, or I
can wait 5min and let the rest fsck while I get to be productive.  The
laptop has /usr, /var, /tmp, /home, /usr/obj, /usr/src, /usr/ports
amongst other partitions.  I've marked all but the first four as
'noauto' and then use the hotplug attach routine to fsck and mount the
rest, which are not necessary for me to be productive and check email.

Since this change, I've hardcoded the scripts, but would definately
prefer the prior behavior.

Thanks,

Penned by Mark Kettenis on 20101213  6:41.17, we have:
| > Date: Mon, 13 Dec 2010 12:48:55 +0100
| > From: MERIGHI Marcus <mcmer-openbsd@tor.at>
| > 
| > > That sounds good.  I was aware of the change, but didn't think anybody
| > > would notice. :)
| 
| A bit late to the game, but I don't really agree with Tedu that the
| changed behaviour is an improvement.  Say I have configured
| hotplugd(8) such that it automatically mounts things when I plug in my
| camera.  Now I reboot my machine, without unplugging the camera.
| Previously hotplugd(8) would remount things upon boot.  Now suddenly
| it doesn't and I have to unplug and replug the camera.
| 
| > Index: share/man/man4/hotplug.4
| > ===================================================================
| > RCS file: /cvs/src/share/man/man4/hotplug.4,v
| > retrieving revision 1.3
| > diff -u -r1.3 hotplug.4
| > --- share/man/man4/hotplug.4	31 May 2007 19:19:50 -0000	1.3
| > +++ share/man/man4/hotplug.4	13 Dec 2010 11:29:30 -0000
| > @@ -31,7 +31,8 @@
| >  .Nm
| >  pseudo-device passes device attachment and detachment events to
| >  userland.
| > -When a device attaches or detaches, the corresponding event is queued.
| > +Once the device is opened by userland, when a device attaches or detaches, 
| > +the corresponding event is queued.
| >  The events can then be obtained from the ...
[ message continues ]

I can agree there's a problem here, but the fact that you're using
hotplug to mount disks that aren't hotplugged indicates the problem is
elsewhere. :)  I don't think hotplug was supposed to be the "do random
stuff a little bit but not too long after boot" utility.

[ message continues ]

Softraid cryptoraid disks are hotplug'ed whenever someone issues
bioctl, whether it is in /etc/rc, /etc/rc.local.local, or elsewhere.

It is not presently possible to have them created prior to init,
but then again, usb disks (read: cameras) can be done prior to init.

I can insert a usb disk and create a softraid crypto volume after
hotplugd starts, and let the attach script worry about duid and fsck
and mount, but I can't do this if it happens to show up before
hotplugd starts.

Whether it's cameras or softraid or external usb disks, all are
hotplugged regardless of when they arrive on the scene or their
backing store.

*shrug*

Penned by Ted Unangst on 20101213 14:04.13, we have:
| On Mon, Dec 13, 2010 at 2:48 PM, Todd T. Fries <todd@fries.net> wrote:
| > I echo Mark's sentiments, though for a different reason.
| >
| > Softraid crypto volumes take time to fsck, yet are useful to use.
| >
| > In my case I can wait 20+min for my personal laptop to be useful, or I
| > can wait 5min and let the rest fsck while I get to be productive. ?The
| > laptop has /usr, /var, /tmp, /home, /usr/obj, /usr/src, /usr/ports
| > amongst other partitions. ?I've marked all but the first four as
| > 'noauto' and then use the hotplug attach routine to fsck and mount the
| > rest, which are not necessary for me to be productive and check email.
| >
| > Since this change, I've hardcoded the scripts, but would definately
| > prefer the prior behavior.
| 
| I can agree there's a problem here, but the fact that you're using
| hotplug to mount disks that aren't hotplugged indicates the problem is
| elsewhere. :)  I don't think hotplug was supposed to be the "do random
| stuff a little bit but not too long after boot" utility.

-- 
Todd Fries .. todd@fries.net

 _____________________________________________
|                                             \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                 \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com             ...
[ message continues ]

OK, if you can wait a few more hours, I will make a diff to go back
the way things came.

[ message continues ]

On Mon, Dec 13, 2010 at 03:04:13PM -0500, Ted Unangst wrote:
| I can agree there's a problem here, but the fact that you're using
| hotplug to mount disks that aren't hotplugged indicates the problem is
| elsewhere. :)  I don't think hotplug was supposed to be the "do random
| stuff a little bit but not too long after boot" utility.

I use an @reboot cronjob to fsck and mount large partitions that are
not immediately necessary upon boot.  I get an e-mail from cron if
there was an issue found during fsck'ing, and usually things just work
out fine.  These partitions are marked with 0 0 in fstab:

[weerd@bfib] $ cat /usr/local/libexec/cronscripts/afterboot
#!/bin/sh
# afterboot: fsck and mount large partitions
######################################################################

PATH=/bin:/sbin:/usr/bin

for PART in `awk '/0 0$/ {print $1}' /etc/fstab`
do
        if fsck -p ${PART} > /dev/null
        then
                mount ${PART}
        else
                echo "Errors found on ${PART}, please check"
        fi
done

Many ways to skin a cat, I suppose, but this one works fine for me...

Cheers,

Paul 'WEiRD' de Weerd

+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

[ message continues ]

And hot-pluggable serial devices, like GPS receivers. Some of them do
have usb serial numbers I can key on.

[ message continues ]