zap a pile of dangling tabs

Convert infinite sleeps to {m,t}sleep_nsec(9).

ok visa@

Correct wakeup() dance in sensor_task_work()
Problem noticed by krw

Sensors are run as callbacks inside tasks. During suspend a sensor
could be running inside a driver that will be force-detached, or due
to tsleep end up disrupting the softstate/hardstate contract.

Sensors are run as callbacks inside tasks. During suspend a sensor
could be running inside a driver that will be force-detached, or due
to tsleep end up disrupting the softstate/hardstate contract. At
suspend time, quisce all these callbacks by waiting for completion.
This issue has never been observed for real, but may be implicated in
suspend/resume failures.
ok kettenis guenther mlarkin

show more ...

Remove some includes include-what-you-use claims don't
have any direct symbols used. Tested for indirect use by compiling
amd64/i386/sparc64 kernels.

ok tedu@ deraadt@

we want to defer work traditionally (in openbsd) handled in an
interrupt context to a taskq running in a thread. however, there
is a concern that if we do that then we allow accidental use of
sleepin

we want to defer work traditionally (in openbsd) handled in an
interrupt context to a taskq running in a thread. however, there
is a concern that if we do that then we allow accidental use of
sleeping APIs in this work, which will make it harder to move the
work back to interrupts in the future.

guenther and kettenis came up with the idea of marking a proc with
CANTSLEEP which the sleep paths can check and panic on.

this builds on that so you create taskqs that run with CANTSLEEP
set except when they need to sleep for more tasks to run.

the taskq_create api is changed to take a flags argument so users
can specify CANTSLEEP. MPSAFE is also passed via this flags field
now. this means archs that defined IPL_MPSAFE to 0 can now create
mpsafe taskqs too.

lots of discussion at s2k15
ok guenther@ miod@ mpi@ tedu@ pelikan@

show more ...

remove the second void * argument on tasks.

when workqs were introduced, we provided a second argument so you
could pass a thing and some context to work on it in. there were
very few things that to

remove the second void * argument on tasks.

when workqs were introduced, we provided a second argument so you
could pass a thing and some context to work on it in. there were
very few things that took advantage of the second argument, so when
i introduced pools i suggested removing it. since tasks were meant
to replace workqs, it was requested that we keep the second argument
to make porting from workqs to tasks easier.

now that workqs are gone, i had a look at the use of the second
argument again and found only one good use of it (vdsp(4) on sparc64
if you're interested) and a tiny handful of questionable uses. the
vast majority of tasks only used a single argument. i have since
modified all tasks that used two args to only use one, so now we
can remove the second argument.

so this is a mechanical change. all tasks only passed NULL as their
second argument, so we can just remove it.

ok krw@

show more ...

prefer sizeof(*ptr) to sizeof(struct) for malloc and free

some systems install sensors where numbering introduces a gap which
falsely triggered the added panic. revert the panic for now while a
better solution is being worked on

as reported by Bjorn Ketela

some systems install sensors where numbering introduces a gap which
falsely triggered the added panic. revert the panic for now while a
better solution is being worked on

as reported by Bjorn Ketelaars on misc@ via jsing@

show more ...

panic when a sensordev gets installed twice, instead of blowing up amazingly
later on

ok deraadt@

add a few sizes to free

remove uneeded proc.h includes
ok mpi@ kspillner@

add a size argument to free. will be used soon, but for now default to 0.
after discussions with beck deraadt kettenis.

use a separate task queue for sensors;
with input from and ok kettenis, deraadt

move kernel sensor tasks from using workqs to tasks. while here
whack the locking and task cancellation.

sensor updates tested locally, and by mpi@ on ugold(4). ok mpi@

sys/param.h gets you sys/types.h automatically

Get rid of MAXSENSORDEVICES. Gaps in sensordev lists are now handled
by returning ENXIO instead of ENOENT, to essentially indicate hotplug
sensor that has gone away. Accessing beyond the end of the

Get rid of MAXSENSORDEVICES. Gaps in sensordev lists are now handled
by returning ENXIO instead of ENOENT, to essentially indicate hotplug
sensor that has gone away. Accessing beyond the end of the sensordev
list still returns ENOENT, so that you can see there are no further devices.
ok kettenis oga

show more ...

timeout_add -> timeout_add_msec

ok dlg@

Convert timeout_add() calls using multiples of hz to timeout_add_sec()

Really just the low-hanging fruit of (hopefully) forthcoming timeout
conversions.

ok art@, krw@

fix a memory leak that was introduced in r1.20 on 2007-06-24T05Z; ok dlg

rework sensor tasks to use the kernels generic workq rather than a special
kernel thread of its own. the api has changed (which will be fixed in the
manpage shortly) so all the users of sensor tasks

rework sensor tasks to use the kernels generic workq rather than a special
kernel thread of its own. the api has changed (which will be fixed in the
manpage shortly) so all the users of sensor tasks that i can find have
been fixed too.

noone tested, so its going in to force people to run with it.
"put it in" deraadt@

show more ...

perhaps it made art's head hurt because it is wrong. triggers NULL
deref in sensor_task_work(); found by krw, dlg should talk to him

rework the sensor task handling to run in the kernels generic workq.

apologies to art for abusing timeouts so badly. apologies to tedu for
making his head hurt.

tested by and ok tedu@

split userland & kernel struct sensor/sensordev so that the addition
of new fields in the future is less disruptive. This is done similar
to how struct proc is handled for ps(1). ok jmc (man page c

split userland & kernel struct sensor/sensordev so that the addition
of new fields in the future is less disruptive. This is done similar
to how struct proc is handled for ps(1). ok jmc (man page changes)
tested fkr simon, and more suggestions from millert

show more ...

kernel code implimemting the new two-level sensor api; written by
Constantine A. Murenin