On Tue, May 13, 2008 at 11:40:21PM +0300, Andriy Gapon wrote:
on 13/05/2008 22:16 Kostik Belousov said the following:
I looked at your previous patch, and it seems it is much simpler to
do drop the devmtx once more then to try to abuse free lists.
In the destroy_devl(), after the
on 14/05/2008 15:19 Kostik Belousov said the following:
On Tue, May 13, 2008 at 11:40:21PM +0300, Andriy Gapon wrote:
on 13/05/2008 22:16 Kostik Belousov said the following:
I looked at your previous patch, and it seems it is much simpler to
do drop the devmtx once more then to try to abuse
on 13/05/2008 22:04 Andriy Gapon said the following:
on 12/05/2008 00:48 Kostik Belousov said the following:
No, we do not have a leak, but we have somewhat non-obvious behaviour.
The cdev structure is freed only after the last reference to cdev is
gone. Typical holder of the reference is the
On Tue, May 13, 2008 at 10:04:56PM +0300, Andriy Gapon wrote:
on 12/05/2008 00:48 Kostik Belousov said the following:
No, we do not have a leak, but we have somewhat non-obvious behaviour.
The cdev structure is freed only after the last reference to cdev is
gone. Typical holder of the
on 12/05/2008 00:48 Kostik Belousov said the following:
No, we do not have a leak, but we have somewhat non-obvious behaviour.
The cdev structure is freed only after the last reference to cdev is
gone. Typical holder of the reference is the devfs vnode. In the normal
usage, the vnode is present
on 13/05/2008 22:16 Kostik Belousov said the following:
I looked at your previous patch, and it seems it is much simpler to
do drop the devmtx once more then to try to abuse free lists.
In the destroy_devl(), after the
while (dev-si_threadcount != 0) {
/* Use unique
Kostik, John, Warner,
thank you for your guidance and suggestions.
I am currently testing the patch attached and I am using a kernel with
WITNESS and INVARIANTS enabled.
Scope of my testing is plugging/unplugging of UMASS devices.
I get CREATE notifications all right.
I do not get any
On Sun, May 11, 2008 at 11:50:20PM +0300, Andriy Gapon wrote:
Kostik, John, Warner,
thank you for your guidance and suggestions.
I am currently testing the patch attached and I am using a kernel with
WITNESS and INVARIANTS enabled.
Scope of my testing is plugging/unplugging of UMASS
In message: [EMAIL PROTECTED]
: However it is possible that it did something wrong - at that time I had
: devctl calls in kern_conf.
I'd be inclined to say 'create' and 'destroy' for the events. ATTACH
and DETACH are typically reserved for device driver events, not for
device node events.
On Fri, Apr 25, 2008 at 12:35:26AM +0300, Andriy Gapon wrote:
I decided to do it in devfs_devs.c because there are less entry points
there and the code is much simpler (you know: aliases, clones).
I also had to add !cold condition, because apparently we have devices
created so early in the
on 25/04/2008 12:50 Kostik Belousov said the following:
Did you run this with WITNESS ?
You put the whole devctl_notify() call under the dev_mtx. This includes
the malloc(), PROC_LOCK() and signalling, and some internal devctl_queue()
stuff. This is wrong.
Kostik,
I tried this patch only
On Fri, Apr 25, 2008 at 05:12:12PM +0300, Andriy Gapon wrote:
on 25/04/2008 12:50 Kostik Belousov said the following:
Did you run this with WITNESS ?
You put the whole devctl_notify() call under the dev_mtx. This includes
the malloc(), PROC_LOCK() and signalling, and some internal
on 25/04/2008 17:36 Kostik Belousov said the following:
The malloc and free cannot be called while holding dev_mtx, this causes
the LORs. Please, look at the rev. 1.207, 1.210 of the kern/kern_conf.c
for the workarounds for the malloc issues. It seems that you may abuse the
dev_unlock_and_free()
on 24/04/2008 01:39 Andriy Gapon said the following:
on 23/04/2008 22:49 John Baldwin said the following:
Events have a subsystem associated with them, so devfs events would use
their
own subsystem type to avoid that sort of confusion.
Thank you for straightening me - for some reason I
On Thursday 24 April 2008 04:05:10 am Andriy Gapon wrote:
on 24/04/2008 01:39 Andriy Gapon said the following:
on 23/04/2008 22:49 John Baldwin said the following:
Events have a subsystem associated with them, so devfs events would use
their own subsystem type to avoid that sort of
I decided to do it in devfs_devs.c because there are less entry points
there and the code is much simpler (you know: aliases, clones).
I also had to add !cold condition, because apparently we have devices
created so early in the boot, that devctl is not ready to handle a
notification. My system
on 23/04/2008 00:06 Jille said the following:
Andriy Gapon wrote:
Maybe this is a crazy idea or maybe we already have something like this.
Is it possible to get notifications about changes in devfs - appearance
and disappearance of devices (in devfs sense of the word)?
devctl currently
On Tuesday 22 April 2008 03:54:17 pm Andriy Gapon wrote:
Maybe this is a crazy idea or maybe we already have something like this.
Is it possible to get notifications about changes in devfs - appearance
and disappearance of devices (in devfs sense of the word)?
devctl currently notifies about
on 23/04/2008 16:55 John Baldwin said the following:
On Tuesday 22 April 2008 03:54:17 pm Andriy Gapon wrote:
Maybe this is a crazy idea or maybe we already have something like this.
Is it possible to get notifications about changes in devfs - appearance
and disappearance of devices (in devfs
On Wednesday 23 April 2008 03:25:23 pm Andriy Gapon wrote:
on 23/04/2008 16:55 John Baldwin said the following:
On Tuesday 22 April 2008 03:54:17 pm Andriy Gapon wrote:
Maybe this is a crazy idea or maybe we already have something like this.
Is it possible to get notifications about changes
on 23/04/2008 22:49 John Baldwin said the following:
Events have a subsystem associated with them, so devfs events would use their
own subsystem type to avoid that sort of confusion.
Thank you for straightening me - for some reason I was thinking about
+/- (attach/detach) events, but I see
Maybe this is a crazy idea or maybe we already have something like this.
Is it possible to get notifications about changes in devfs - appearance
and disappearance of devices (in devfs sense of the word)?
devctl currently notifies about real (hardware) devices handled by
device drivers and some
Andriy Gapon wrote:
Maybe this is a crazy idea or maybe we already have something like this.
Is it possible to get notifications about changes in devfs - appearance
and disappearance of devices (in devfs sense of the word)?
devctl currently notifies about real (hardware) devices handled by
23 matches
Mail list logo
