stopmachine semaphore to mutex

The port_mutex is actually a semaphore, so easily converted to a struct mutex.

Signed-off-by Daniel Walker <[email protected]>

Quoted 4 lines · Daniel Walker

The port_mutex is actually a semaphore, so easily converted to a struct mutex.

Signed-off-by Daniel Walker <[email protected]>

Acked-by Ingo Molnar <[email protected]>

cool. How far away are we from being able to remove all the semaphore code? :-)

Quoted 11 lines · Daniel Walker

Quoted 5 lines

The port_mutex is actually a semaphore, so easily converted to a struct mutex.

Signed-off-by Daniel Walker <[email protected]>

Acked-by Ingo Molnar <[email protected]>

cool. How far away are we from being able to remove all the semaphore code? :-)

I wish my 7 patches made a dent, but it's hasn't done much. ;(

I would guess at least a week just to mop up the relatively easy ones.. I've got 12 in my queue, and there still ~50 hopefully trivial ones still to be looked at.. Then another ~30 more difficult ones (that use init_MUTEX_LOCKED, or sema_init with 0 instead of 1) ..

Daniel

Daniel,

FYI: I am working on the conversion of the 2 sem->mutex in kernel/printk.c

I looked at the console_sem , but i was going to leave that as last..

The problem with the console_sem is that it can get locked from interrupt context, which is discouraged with mutex types.. I think it will be complicated to convert..

Quoted 11 lines · Daniel Walker

Quoted 5 lines

The port_mutex is actually a semaphore, so easily converted to a struct mutex.

Signed-off-by Daniel Walker <[email protected]>

Acked-by Ingo Molnar <[email protected]>

cool. How far away are we from being able to remove all the semaphore code? :-)

I wish my 7 patches made a dent, but it's hasn't done much. ;(

I would guess at least a week just to mop up the relatively easy ones.. I've got 12 in my queue, and there still ~50 hopefully trivial ones still to be looked at.. Then another ~30 more difficult ones (that use init_MUTEX_LOCKED, or sema_init with 0 instead of 1) ..

El Thu, Dec 06, 2007 at 08:34:06AM -0800 Daniel Walker ha dit:

Quoted 13 lines · Ingo Molnar

Quoted 11 lines · Daniel Walker

Quoted 5 lines

The port_mutex is actually a semaphore, so easily converted to a struct mutex.

Signed-off-by Daniel Walker <[email protected]>

Acked-by Ingo Molnar <[email protected]>

cool. How far away are we from being able to remove all the semaphore code? :-)

Quoted 6 lines

I wish my 7 patches made a dent, but it's hasn't done much. ;(

I would guess at least a week just to mop up the relatively easy ones.. I've got 12 in my queue, and there still ~50 hopefully trivial ones still to be looked at.. Then another ~30 more difficult ones (that use init_MUTEX_LOCKED, or sema_init with 0 instead of 1) ..

I've also more patches of this type on my list, though i work in a slower pace

--
Matthias Kaehlcke
Linux Application Developer
Barcelona

You must have a plan. If you don't have a plan,
you'll become part of somebody else's plan
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
. '`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-

Hello Matthias,

Which do you have exactly on your list? (good to know, it prevents double work...)

Which do you have exactly on your list? (good to know, it prevents double work...)

2007/12/6, Matthias Kaehlcke <[email protected]>:

Quoted 33 lines

El Thu, Dec 06, 2007 at 08:34:06AM -0800 Daniel Walker ha dit:

Quoted 13 lines · Ingo Molnar

Quoted 11 lines · Daniel Walker

Quoted 5 lines

The port_mutex is actually a semaphore, so easily converted to a struct mutex.

Signed-off-by Daniel Walker <[email protected]>

Acked-by Ingo Molnar <[email protected]>

cool. How far away are we from being able to remove all the semaphore code? :-)

Quoted 6 lines

I wish my 7 patches made a dent, but it's hasn't done much. ;(

I would guess at least a week just to mop up the relatively easy ones.. I've got 12 in my queue, and there still ~50 hopefully trivial ones still to be looked at.. Then another ~30 more difficult ones (that use init_MUTEX_LOCKED, or sema_init with 0 instead of 1) ..

I've also more patches of this type on my list, though i work in a slower pace

You must have a plan. If you don't have a plan,
you'll become part of somebody else's plan
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
. '`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-

Quoted 2 lines

cool. How far away are we from being able to remove all the semaphore code? :-)

I wish my 7 patches made a dent, but it's hasn't done much. ;(

I would guess at least a week just to mop up the relatively easy ones.. I've got 12 in my queue, and there still ~50 hopefully trivial ones still to be looked at.. Then another ~30 more difficult ones (that use init_MUTEX_LOCKED, or sema_init with 0 instead of 1) ..

Quoted 10 lines · Ingo Molnar

Quoted 4 lines · Daniel Walker

The port_mutex is actually a semaphore, so easily converted to a struct mutex.

Signed-off-by Daniel Walker <[email protected]>

Acked-by Ingo Molnar <[email protected]>

cool. How far away are we from being able to remove all the semaphore code? :-)

I wish my 7 patches made a dent, but it's hasn't done much. ;(

I would guess at least a week just to mop up the relatively easy ones.. I've got 12 in my queue, and there still ~50 hopefully trivial ones still to be looked at.. Then another ~30 more difficult ones (that use init_MUTEX_LOCKED, or sema_init with 0 instead of 1) ..

Quoted 12 lines · Daniel Walker

Quoted 10 lines · Ingo Molnar

Quoted 4 lines · Daniel Walker

The port_mutex is actually a semaphore, so easily converted to a struct mutex.

Signed-off-by Daniel Walker <[email protected]>

Acked-by Ingo Molnar <[email protected]>

cool. How far away are we from being able to remove all the semaphore code? :-)

Quoted 7 lines

I wish my 7 patches made a dent, but it's hasn't done much. ;(

I would guess at least a week just to mop up the relatively easy ones.. I've got 12 in my queue, and there still ~50 hopefully trivial ones still to be looked at.. Then another ~30 more difficult ones (that use init_MUTEX_LOCKED, or sema_init with 0 instead of 1) ..

I didn't realise there were so many of these patch sets still to go. I could probably help out with some of them. Is there somewhere we could keep track of which ones are left to do, and who is handling them? If it would be helpful, I could go through all of the semaphore uses in the tree and try to figure out which (if any) are true counting semaphores that cannot be converted, and then I could post/send the list of convertible cases. Would that be helpful, or has it already been done somewhere else?

I've posted all the ones I've done so far ..

ftp://source.mvista.com/pub/dwalker/sem2mutex-2.6.24-rc4/

Feel free to review or test them.. I've found it pretty easy to simply grep for certain class of semaphore usage, check if it's conforming to the mutex requirements, then convert it or not.. Checking them is getting to be a habit, so I don't think a list would help me.. However, someone else might be able to use it..

Quoted 11 lines · Daniel Walker

I've posted all the ones I've done so far ..

ftp://source.mvista.com/pub/dwalker/sem2mutex-2.6.24-rc4/

Feel free to review or test them.. I've found it pretty easy to simply grep for certain class of semaphore usage, check if it's conforming to the mutex requirements, then convert it or not.. Checking them is getting to be a habit, so I don't think a list would help me.. However, someone else might be able to use it..

Thanks, that helps me not duplicate anything. One of the first ones I was looking at (before your post) was viotape.c, which is in your patch set. However, looking at the uses of the semaphore, I see that on line 409-410 the following code:

        if (noblock)
                return count;

which seems to ignore the fact that the semaphore has been downed (not to mention the dma buffer and op struct allocations. I think it should be:

	if (noblock)
		ret = count;
		goto free_dma;

instead. Do you want to make sure I'm right about that and fold it into your patch? Or have you already submitted your patch (or should it be in a separate patch? Alternatively, I can submit the patch if you don't want to bother with it.

Quoted 22 lines · Kevin Winchester

Quoted 10 lines · Daniel Walker

I've posted all the ones I've done so far ..

ftp://source.mvista.com/pub/dwalker/sem2mutex-2.6.24-rc4/

Feel free to review or test them.. I've found it pretty easy to simply grep for certain class of semaphore usage, check if it's conforming to the mutex requirements, then convert it or not.. Checking them is getting to be a habit, so I don't think a list would help me.. However, someone else might be able to use it..

Thanks, that helps me not duplicate anything. One of the first ones I was looking at (before your post) was viotape.c, which is in your patch set. However, looking at the uses of the semaphore, I see that on line 409-410 the following code:

        if (noblock)
                return count;

which seems to ignore the fact that the semaphore has been downed (not to mention the dma buffer and op struct allocations. I think it should be:

Quoted 8 lines

	if (noblock)
		ret = count;
		goto free_dma;

instead. Do you want to make sure I'm right about that and fold it into your patch? Or have you already submitted your patch (or should it be in a separate patch? Alternatively, I can submit the patch if you don't want to bother with it.

viotape was one of the first I started converting, but later I noticed the same thing you found above. I have it commented out of my series for that reason ..

I think this noblock path is actually doing what the author intended.. There are a few stray up() calls related to event handling and ioctls , and I think those are used to release the semaphore..

Daniel

Quoted 36 lines · Daniel Walker

Quoted 22 lines · Kevin Winchester

Quoted 10 lines · Daniel Walker

I've posted all the ones I've done so far ..

ftp://source.mvista.com/pub/dwalker/sem2mutex-2.6.24-rc4/

Feel free to review or test them.. I've found it pretty easy to simply grep for certain class of semaphore usage, check if it's conforming to the mutex requirements, then convert it or not.. Checking them is getting to be a habit, so I don't think a list would help me.. However, someone else might be able to use it..

Thanks, that helps me not duplicate anything. One of the first ones I was looking at (before your post) was viotape.c, which is in your patch set. However, looking at the uses of the semaphore, I see that on line 409-410 the following code:

        if (noblock)
                return count;

which seems to ignore the fact that the semaphore has been downed (not to mention the dma buffer and op struct allocations. I think it should be:

Quoted 8 lines

	if (noblock)
		ret = count;
		goto free_dma;

instead. Do you want to make sure I'm right about that and fold it into your patch? Or have you already submitted your patch (or should it be in a separate patch? Alternatively, I can submit the patch if you don't want to bother with it.

viotape was one of the first I started converting, but later I noticed the same thing you found above. I have it commented out of my series for that reason ..

Quoted 7 lines

I think this noblock path is actually doing what the author intended.. There are a few stray up() calls related to event handling and ioctls , and I think those are used to release the semaphore..

Daniel

Yes, you are right, I hadn't finished looking at all of the up() calls when I came to my conclusion. I will try to convert a few that are not on your list, but I would like to know how you are generating your patches into those files with the diffstat and recipient list. Is that a feature of some git command?

Quoted 5 lines

Yes, you are right, I hadn't finished looking at all of the up() calls when I came to my conclusion. I will try to convert a few that are not on your list, but I would like to know how you are generating your patches into those files with the diffstat and recipient list. Is that a feature of some git command?

Git may have a similar feature, but I'm using a tool call Quilt. It's used for managing a list of patches, and it can automatically add a diffstat to the patch header (part of the quilt refresh command). I also use it for emailing a list of patches.

Yes, I've used quilt for working with mm patches in the past, but I'm not too familiar with the mail features. For example, how do you get the recipient list and Signed-off-by in the patch file? Do you just edit it by hand? Or is there some guide to quilt I should be reading? I looked at the guide in /usr/share/doc/quilt/quilt.pdf, but it didn't have anything about email. /usr/share/doc/quilt/README.MAIL has the details of all of the mail options, but doesn't give a nice example of what to do with the patch file and how to call 'quilt mail'.

It's called stopmachine_mutex now, but it's a semaphore. So make it a "struct mutex" .

Signed-off-by Daniel Walker <[email protected]>