unified spinlock initialization arch/um/drivers/port_kern.c
PATCH 1/1 unified spinlock initialization arch/um/drivers/port_kern.c
From: <[email protected]>
Cc: <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>
Unify the spinlock initialization as far as possible.
---
linux-2.6.11-paolo/arch/um/drivers/port_kern.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-)
arch/um/drivers/port_kern.c renamed from arch/um/drivers/port_kern.c~uml-switch-spinlock-init +1 -1
@@ -185,11 +185,11 @@ void *port_data(int port_num) .has_connection = 0, .sem =__SEMAPHORE_INITIALIZER (port->sem, 0), - .lock = SPIN_LOCK_UNLOCKED, .port = port_num, .fd = fd, .pending = LIST_HEAD_INIT(port->pending), .connections = LIST_HEAD_INIT(port->connections) }); +spin_lock_init (&port->lock);list_add (&port->list, &ports); found:
_
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Quoted 5 lines · On Wed, Mar 09, 2005 at 10:42:33AM +0100, [email protected] wrote:
From: <[email protected]>
Cc: <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>Unify the spinlock initialization as far as possible.
Are you sure this is really the best option in this instance? Sometimes, static data initialisation is more efficient than code-based manual initialisation, especially when the memory is written to anyway.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
Quoted 11 lines · Russell King
Quoted 5 lines · On Wed, Mar 09, 2005 at 10:42:33AM +0100, [email protected] wrote:
From: <[email protected]>
Cc: <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>Unify the spinlock initialization as far as possible.
Are you sure this is really the best option in this instance? Sometimes, static data initialisation is more efficient than code-based manual initialisation, especially when the memory is written to anyway.
Agreed, theoretically, but this was done for multiple reasons globally, for instance as a preparation to Ingo Molnar's preemption patches. There was mention of this on lwn.net about this:
http://lwn.net/Articles/108719/
Ok?
Signature · 16 lines
Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Quoted 12 lines · Blaisorblade
Quoted 11 lines · Russell King
Quoted 5 lines · On Wed, Mar 09, 2005 at 10:42:33AM +0100, [email protected] wrote:
From: <[email protected]>
Cc: <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>Unify the spinlock initialization as far as possible.
Are you sure this is really the best option in this instance? Sometimes, static data initialisation is more efficient than code-based manual initialisation, especially when the memory is written to anyway.
Quoted 5 lines
Agreed, theoretically, but this was done for multiple reasons globally, for instance as a preparation to Ingo Molnar's preemption patches. There was mention of this on lwn.net about this:
Was this announced on linux-kernel as well? I don't remember seeing it.
I'm not convinced about the practicality of converting all static initialisations to code-based initialisations though - I can see that the number of initialisation functions scattered throughout the kernel is going to increase dramatically to achieve this.
With a 2.4 to 2.6 kernel bloat already on the order of 140% for similar functionality, I can only see the kernel getting more and more bloated _for the same feature level_ because we're trying to add more features to the kernel.
I'm not entirely convinced that is an all round sane approach.
Signature · 14 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Quoted 3 lines · Russell King
I'm not convinced about the practicality of converting all static initialisations to code-based initialisations though
This is the first one I recall seeing. All the other conversions were replacing
static spinlock_t lock = SPIN_LOCK_UNLOCKED;
with
static DEFINE_SPINLOCK(lock);
and replacing
{
lock = SPIN_LOCK_UNLOCKED;
}with
{
spin_lock_init(lock);
}-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Quoted 18 lines · Andrew Morton
Quoted 3 lines · Russell King
I'm not convinced about the practicality of converting all static initialisations to code-based initialisations though
This is the first one I recall seeing. All the other conversions were replacing
static spinlock_t lock = SPIN_LOCK_UNLOCKED;with
static DEFINE_SPINLOCK(lock);and replacing
{ lock = SPIN_LOCK_UNLOCKED; }
Quoted 5 lines
with
{ spin_lock_init(lock); }
We need to retain the spin_lock_init(&lock) because not all spin-locks are allocated at compile-time. They might be allocated from kmalloc() on startup, probably in a structure, along with other so-called global data.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
Quoted 4 lines · linux-os
We need to retain the
spin_lock_init(&lock)because not all spin-locks are allocated at compile-time. They might be allocated fromkmalloc()on startup, probably in a structure, along with other so-called global data.
Not to worry my good man, it's not going anywhere.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Quoted 9 lines · Blaisorblade
Quoted 4 lines
Are you sure this is really the best option in this instance? Sometimes, static data initialisation is more efficient than code-based manual initialisation, especially when the memory is written to anyway.
Agreed, theoretically, but this was done for multiple reasons globally, for instance as a preparation to Ingo Molnar's preemption patches. There was mention of this on lwn.net about this:
Those patches did only the conversion of
static spinlock_t lock = SPIN_LOCK_UNLOCKED;
lock = SPIN_LOCK_UNLOCKED;
to
static DEFINE_SPINLOCK(lock);
spin_lock_init(lock);If you want to do static initialization inside of structures, then you have to define a seperate MACRO similar to the static initialization of list_head's inside of structures:
static struct sysfs_dirent sysfs_root = {
.s_sibling = LIST_HEAD_INIT(sysfs_root.s_sibling),
tglx
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Quoted 12 lines · Thomas Gleixner
Quoted 10 lines · Blaisorblade
Quoted 4 lines
Are you sure this is really the best option in this instance? Sometimes, static data initialisation is more efficient than code-based manual initialisation, especially when the memory is written to anyway.
Agreed, theoretically, but this was done for multiple reasons globally, for instance as a preparation to Ingo Molnar's preemption patches. There was mention of this on lwn.net about this:
Quoted 7 lines
Those patches did only the conversion of
static spinlock_t lock = SPIN_LOCK_UNLOCKED; lock = SPIN_LOCK_UNLOCKED; to static DEFINE_SPINLOCK(lock); spin_lock_init(lock);
First: I didn't write the patch, only forwarded it, so I just guessed why it was done.
The latter is spin_lock_init(&lock); (since someone got confused about this).
However, this is a .lock = SPIN_LOCK_UNLOCKED ->spin_lock_init(&struct.lock),
so I don't understand what changes... the structure is initialized inside a function, so there's no change.
Quoted 6 lines
If you want to do static initialization inside of structures, then you have to define a seperate MACRO similar to the static initialization of list_head's inside of structures:
static struct
sysfs_direntsysfs_root= {
.s_sibling =LIST_HEAD_INIT(sysfs_root.s_sibling),
I don't see the need here... and the initialization is not in static code; it changes this code snippet:
void *port_data(int port_num)
{
//...
*port = ((struct port_list)
{ .list = LIST_HEAD_INIT(port->list),
.has_connection = 0,
.sem = __SEMAPHORE_INITIALIZER(port->sem,
0),
.lock = SPIN_LOCK_UNLOCKED,
.port = port_num,
.fd = fd,
.pending = LIST_HEAD_INIT(port->pending),
.connections =LIST_HEAD_INIT(port->connections) });
So you are all doing some confusion (in fact I guess Andrew realized this when he merged this anyway).
Signature · 16 lines
Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel