On Friday 22 May 2009 11:37:38 am Scott Long wrote:
> John Baldwin wrote:
> > On Friday 22 May 2009 9:44:18 am Scott Long wrote:
> >> John Baldwin wrote:
> >>> On Thursday 21 May 2009 6:11:02 pm Attilio Rao wrote:
> At this point I wonder what's the purpose of maintaining the sleeping
> v
John Baldwin wrote:
On Friday 22 May 2009 9:44:18 am Scott Long wrote:
John Baldwin wrote:
On Thursday 21 May 2009 6:11:02 pm Attilio Rao wrote:
At this point I wonder what's the purpose of maintaining the sleeping
version for such functions?
Actually, I still very much do not like using M_NOW
M. Warner Losh wrote:
In message: <4a16ac32.2040...@samsco.org>
Scott Long writes:
: John Baldwin wrote:
: > On Thursday 21 May 2009 6:11:02 pm Attilio Rao wrote:
: >> At this point I wonder what's the purpose of maintaining the sleeping
: >> version for such functions?
: >
: > Actu
On Friday 22 May 2009 9:44:18 am Scott Long wrote:
> John Baldwin wrote:
> > On Thursday 21 May 2009 6:11:02 pm Attilio Rao wrote:
> >> At this point I wonder what's the purpose of maintaining the sleeping
> >> version for such functions?
> >
> > Actually, I still very much do not like using M_NOW
In message: <4a16ac32.2040...@samsco.org>
Scott Long writes:
: John Baldwin wrote:
: > On Thursday 21 May 2009 6:11:02 pm Attilio Rao wrote:
: >> At this point I wonder what's the purpose of maintaining the sleeping
: >> version for such functions?
: >
: > Actually, I still very much
On Fri, May 22, 2009 at 07:44:18AM -0600, Scott Long wrote:
> John Baldwin wrote:
> >On Thursday 21 May 2009 6:11:02 pm Attilio Rao wrote:
> >>At this point I wonder what's the purpose of maintaining the sleeping
> >>version for such functions?
> >
> >Actually, I still very much do not like using M
John Baldwin wrote:
On Thursday 21 May 2009 6:11:02 pm Attilio Rao wrote:
At this point I wonder what's the purpose of maintaining the sleeping
version for such functions?
Actually, I still very much do not like using M_NOWAIT needlessly. I would
much rather the solution for make_dev() be th
On Fri, 22 May 2009, John Baldwin wrote:
On Thursday 21 May 2009 6:11:02 pm Attilio Rao wrote:
At this point I wonder what's the purpose of maintaining the sleeping
version for such functions?
Actually, I still very much do not like using M_NOWAIT needlessly. I would
much rather the solutio
On Thursday 21 May 2009 6:11:02 pm Attilio Rao wrote:
> At this point I wonder what's the purpose of maintaining the sleeping
> version for such functions?
Actually, I still very much do not like using M_NOWAIT needlessly. I would
much rather the solution for make_dev() be that the 1 or 2 places
On Fri, 22 May 2009, Attilio Rao wrote:
You need to check return values here if it returns NULL.
IMHO, having a non-sleepable version of destroy_dev(), create_dev() and
such would be ideal. Ideally, we should resolve all the sleeping point and
do the conversion. I'm unable to check the code
On Fri, May 22, 2009 at 12:11:02AM +0200, Attilio Rao wrote:
> 2009/5/21 Kostik Belousov :
> > On Thu, May 21, 2009 at 07:05:17PM +0200, Attilio Rao wrote:
> >> 2009/5/21 Kostik Belousov :
> >> > On Thu, May 21, 2009 at 09:23:15AM -0700, Scott Long wrote:
> >> >> Kostik Belousov wrote:
> >> >> >We
In message: <3bbf2fe10905211511g53defb6cmac45fc2469cc...@mail.gmail.com>
Attilio Rao writes:
: At this point I wonder what's the purpose of maintaining the sleeping
: version for such functions?
As John explained, destroy_dev() needs to sleep to flush all the
threads out of the driver
2009/5/21 Kostik Belousov :
> On Thu, May 21, 2009 at 07:05:17PM +0200, Attilio Rao wrote:
>> 2009/5/21 Kostik Belousov :
>> > On Thu, May 21, 2009 at 09:23:15AM -0700, Scott Long wrote:
>> >> Kostik Belousov wrote:
>> >> >We do have the KPI for the callers that cannot drop the locks and need
>> >>
In message <20090521.144043.-501541558@bsdimp.com>, "M. Warner Losh" writes
:
>: Correct, but kqueuing /dev is not nearly as expressiv as devctl,
>: where the protocol has space where the device driver could pass
>: useful information to devd(8).
>
>It could, but right now it doesn't.
My poin
Poul-Henning Kamp wrote:
In message <20090521.101537.864824728@bsdimp.com>, "M. Warner Losh" writes:
Right now, the devctl_notify() is what gets it into devd. However,
I'd always viewed devd as having multiple event sources and not just
>from the /dev/devctl device.
Correct, but
In message: <2070.1242926...@critter.freebsd.dk>
"Poul-Henning Kamp" writes:
: In message <20090521.101537.864824728@bsdimp.com>, "M. Warner Losh"
writes:
:
: >Right now, the devctl_notify() is what gets it into devd. However,
: >I'd always viewed devd as having multiple event s
On Thu, May 21, 2009 at 07:05:17PM +0200, Attilio Rao wrote:
> 2009/5/21 Kostik Belousov :
> > On Thu, May 21, 2009 at 09:23:15AM -0700, Scott Long wrote:
> >> Kostik Belousov wrote:
> >> >We do have the KPI for the callers that cannot drop the locks and need
> >> >to do destroy_dev, destroy_dev_sc
In message <20090521.101537.864824728@bsdimp.com>, "M. Warner Losh" writes:
>Right now, the devctl_notify() is what gets it into devd. However,
>I'd always viewed devd as having multiple event sources and not just
>from the /dev/devctl device.
Correct, but kqueuing /dev is not nearly as expr
2009/5/21 Kostik Belousov :
> On Thu, May 21, 2009 at 09:23:15AM -0700, Scott Long wrote:
>> Kostik Belousov wrote:
>> >We do have the KPI for the callers that cannot drop the locks and need
>> >to do destroy_dev, destroy_dev_sched(9).
>>
>> Good to know, I'll look at destroy_dev_sched(). I'd rath
On Thu, May 21, 2009 at 09:23:15AM -0700, Scott Long wrote:
> Kostik Belousov wrote:
> >We do have the KPI for the callers that cannot drop the locks and need
> >to do destroy_dev, destroy_dev_sched(9).
>
> Good to know, I'll look at destroy_dev_sched(). I'd rather not have to
> roll my own decou
On Thu, May 21, 2009 at 12:23:54PM -0400, John Baldwin wrote:
> On Thursday 21 May 2009 12:15:35 pm Kostik Belousov wrote:
> > On Thu, May 21, 2009 at 12:10:59PM -0400, John Baldwin wrote:
> > Another thing done inside destroy_dev is the call to the destructors
> > of the cdevpriv data, that never
On Thursday 21 May 2009 12:15:35 pm Kostik Belousov wrote:
> On Thu, May 21, 2009 at 12:10:59PM -0400, John Baldwin wrote:
> Another thing done inside destroy_dev is the call to the destructors
> of the cdevpriv data, that never had any restrictions on the sleepable
> context.
>
> We do have the K
Kostik Belousov wrote:
On Thu, May 21, 2009 at 12:10:59PM -0400, John Baldwin wrote:
On Thursday 21 May 2009 11:54:01 am Scott Long wrote:
M. Warner Losh wrote:
In message:
Robert Watson writes:
: On Thu, 21 May 2009, John Baldwin wrote:
:
: Move the M_WAITOK flag in noti
In message: <1689.1242921...@critter.freebsd.dk>
"Poul-Henning Kamp" writes:
: In message <4a157919.7040...@samsco.org>, Scott Long writes:
:
: >I would also love to have destroy_dev() and make_dev() be locking-neutral.
:
: As far as I know, there is nothing preventing that any more.
On Thu, May 21, 2009 at 12:10:59PM -0400, John Baldwin wrote:
> On Thursday 21 May 2009 11:54:01 am Scott Long wrote:
> > M. Warner Losh wrote:
> > > In message:
> > > Robert Watson writes:
> > > : On Thu, 21 May 2009, John Baldwin wrote:
> > > :
> > > : Move the M_WAITOK flag
On Thursday 21 May 2009 11:54:01 am Scott Long wrote:
> M. Warner Losh wrote:
> > In message:
> > Robert Watson writes:
> > : On Thu, 21 May 2009, John Baldwin wrote:
> > :
> > : Move the M_WAITOK flag in notify() into an M_NOWAIT one in order
to
> > : > match
> > : th
In message <4a157919.7040...@samsco.org>, Scott Long writes:
>I would also love to have destroy_dev() and make_dev() be locking-neutral.
As far as I know, there is nothing preventing that any more.
The current state of affairs still reflects a reality from before
SMPng entirely changed what "ke
On Thu, 21 May 2009, M. Warner Losh wrote:
: devctl_notify() probably needs to grow a sleepable flag, or perhaps we need
: two variations, one that can sleep.
devctl_notify() has expanded well beyond its original needs. Having an
extra case for sleeping is the wrong way to solve this problem
M. Warner Losh wrote:
In message:
Robert Watson writes:
: On Thu, 21 May 2009, John Baldwin wrote:
:
: Move the M_WAITOK flag in notify() into an M_NOWAIT one in order to
: > match
: the behaviour alredy present with the further malloc() call in
: devctl_notif
On Thursday 21 May 2009 11:41:00 am M. Warner Losh wrote:
> In message:
> Robert Watson writes:
> : On Thu, 21 May 2009, John Baldwin wrote:
> :
> : Move the M_WAITOK flag in notify() into an M_NOWAIT one in order to
> : > match
> : the behaviour alredy present with the
On Thu, May 21, 2009 at 09:41:00AM -0600, M. Warner Losh wrote:
> In message:
> Robert Watson writes:
> : On Thu, 21 May 2009, John Baldwin wrote:
> :
> : Move the M_WAITOK flag in notify() into an M_NOWAIT one in order to
> : > match
> : the behaviour alredy present wi
In message:
Robert Watson writes:
: On Thu, 21 May 2009, John Baldwin wrote:
:
: Move the M_WAITOK flag in notify() into an M_NOWAIT one in order to
: > match
: the behaviour alredy present with the further malloc() call in
: devctl_notify().
: This fixes
On Thu, 21 May 2009, John Baldwin wrote:
Move the M_WAITOK flag in notify() into an M_NOWAIT one in order to
match
the behaviour alredy present with the further malloc() call in
devctl_notify().
This fixes a bug in the CAM layer where the camisr handler finished to
call camperiphfree
Ken Smith wrote:
On Thu, 2009-05-21 at 09:42 -0400, John Baldwin wrote:
I agree with kib, this should be reverted and CAM fixed instead.
I haven't sent out an updated 8.0-REL status report yet (soon...) but
one of the people who contributed status information when I sent out the
last one was S
On Thu, 2009-05-21 at 09:42 -0400, John Baldwin wrote:
> I agree with kib, this should be reverted and CAM fixed instead.
I haven't sent out an updated 8.0-REL status report yet (soon...) but
one of the people who contributed status information when I sent out the
last one was Scott Long saying he
On Thursday 21 May 2009 9:29:57 am Attilio Rao wrote:
> 2009/5/21 Kostik Belousov :
> > On Thu, May 21, 2009 at 01:22:07PM +, Attilio Rao wrote:
> >> Author: attilio
> >> Date: Thu May 21 13:22:07 2009
> >> New Revision: 192535
> >> URL: http://svn.freebsd.org/changeset/base/192535
> >>
> >> Lo
2009/5/21 Kostik Belousov :
> On Thu, May 21, 2009 at 03:29:57PM +0200, Attilio Rao wrote:
>> 2009/5/21 Kostik Belousov :
>> > On Thu, May 21, 2009 at 01:22:07PM +, Attilio Rao wrote:
>> >> Author: attilio
>> >> Date: Thu May 21 13:22:07 2009
>> >> New Revision: 192535
>> >> URL: http://svn.fre
On Thu, May 21, 2009 at 03:29:57PM +0200, Attilio Rao wrote:
> 2009/5/21 Kostik Belousov :
> > On Thu, May 21, 2009 at 01:22:07PM +, Attilio Rao wrote:
> >> Author: attilio
> >> Date: Thu May 21 13:22:07 2009
> >> New Revision: 192535
> >> URL: http://svn.freebsd.org/changeset/base/192535
> >>
2009/5/21 Attilio Rao :
> 2009/5/21 Kostik Belousov :
>> On Thu, May 21, 2009 at 01:22:07PM +, Attilio Rao wrote:
>>> Author: attilio
>>> Date: Thu May 21 13:22:07 2009
>>> New Revision: 192535
>>> URL: http://svn.freebsd.org/changeset/base/192535
>>>
>>> Log:
>>> Move the M_WAITOK flag in no
2009/5/21 Kostik Belousov :
> On Thu, May 21, 2009 at 01:22:07PM +, Attilio Rao wrote:
>> Author: attilio
>> Date: Thu May 21 13:22:07 2009
>> New Revision: 192535
>> URL: http://svn.freebsd.org/changeset/base/192535
>>
>> Log:
>> Move the M_WAITOK flag in notify() into an M_NOWAIT one in ord
On Thu, May 21, 2009 at 01:22:07PM +, Attilio Rao wrote:
> Author: attilio
> Date: Thu May 21 13:22:07 2009
> New Revision: 192535
> URL: http://svn.freebsd.org/changeset/base/192535
>
> Log:
> Move the M_WAITOK flag in notify() into an M_NOWAIT one in order to match
> the behaviour alredy
Author: attilio
Date: Thu May 21 13:22:07 2009
New Revision: 192535
URL: http://svn.freebsd.org/changeset/base/192535
Log:
Move the M_WAITOK flag in notify() into an M_NOWAIT one in order to match
the behaviour alredy present with the further malloc() call in
devctl_notify().
This fixes a
42 matches
Mail list logo
