THIS_MODULE->name="";

THIS_MODULE->name="";

[Ron Henry]

Should there be a check in sys_module_init to check for a 0 lenth name
being specified in struct module? If THIS_MODULE->name=""; is added
within a kernel module, future attempts to load, unload and query a module
will fail. I can't think of any reason why someone should need to ability
to set a 0 length name.

-Ron

"the illiterate of the future are not those who can neither read or write
but those that cannot learn, unlearn and relearn"

[RFC] Rename _bh to _softirq

[Maksim (Max) Krasnyanskiy]

Hi Folks,

Old BHs have been almost completely replaced with tasklets and softirqs.
Should we then rename _bh to _softirq ?
i.e
         local_bh_disable()      ->      local_softirq_disable()
         spin_lock_bh()          ->      spin_lock_softirq()
         bh_lock_sock()          ->      softirq_sock_lock()
         etc

Or maybe just 'si' if softirq is too long.

bh prefix and postfix seem to be confusing now.



Max

http://bluez.sf.net
http://vtun.sf.net

Re: [RFC] Rename _bh to _softirq

[Jeff Garzik]

Maksim (Max) Krasnyanskiy wrote:
> Hi Folks,
> 
> Old BHs have been almost completely replaced with tasklets and softirqs.


In 2.5?  They have been replaced by work queues...  though in some cases 
manual conversion to tasklets is more appropriate.

	Jeff

Re: [RFC] Rename _bh to _softirq

[Ingo Molnar]

On Mon, 14 Oct 2002, Maksim (Max) Krasnyanskiy wrote:

> Old BHs have been almost completely replaced with tasklets and softirqs.
> Should we then rename _bh to _softirq ?
> i.e
>          local_bh_disable()      ->      local_softirq_disable()
>          spin_lock_bh()          ->      spin_lock_softirq()
>          bh_lock_sock()          ->      softirq_sock_lock()
>          etc

i wanted to do this as part of the irqlock cleanups, but generally we dont
change existing interfaces unless it's really universally agreed upon. Eg.  
we had cli() around for a *long* time although it's an x86 (-mostly)
instruction name. But yes, i agree, and there are a number of other
renames that would make perfect sense.

	Ingo

Re: [RFC] Rename _bh to _softirq

[Maksim (Max) Krasnyanskiy]

At 09:21 PM 10/14/2002 +0200, Ingo Molnar wrote:

>On Mon, 14 Oct 2002, Maksim (Max) Krasnyanskiy wrote:
>
> > Old BHs have been almost completely replaced with tasklets and softirqs.
> > Should we then rename _bh to _softirq ?
> > i.e
> >          local_bh_disable()      ->      local_softirq_disable()
> >          spin_lock_bh()          ->      spin_lock_softirq()
> >          bh_lock_sock()          ->      softirq_sock_lock()
> >          etc
>
>i wanted to do this as part of the irqlock cleanups, but generally we dont
>change existing interfaces unless it's really universally agreed upon. Eg.
>we had cli() around for a *long* time although it's an x86 (-mostly)
>instruction name. But yes, i agree, and there are a number of other
>renames that would make perfect sense.

We can keep compatibility defines, just like we have for cli().
i.e.
         #define local_bh_disable local_softirq_disable

Max

Re: [RFC] Rename _bh to _softirq

[Maksim (Max) Krasnyanskiy]

At 03:12 PM 10/14/2002 -0400, Jeff Garzik wrote:
>Maksim (Max) Krasnyanskiy wrote:
>>Hi Folks,
>>Old BHs have been almost completely replaced with tasklets and softirqs.
>
>In 2.5?  They have been replaced by work queues...
>though in some cases manual conversion to tasklets is more appropriate.
Task queues were replaced with work queues. I'm taking about things like 
NET_BH, TIMER_BH, etc.
In general what's been called "bottom half" is now referred to as "softirq".

Max

Re: [RFC] Rename _bh to _softirq

[kuznet]

Hello!

>         But yes, i agree, and there are a number of other
> renames that would make perfect sense.

Oh, do you dislike names with history? I love them. :-)
Well, bh is short, looks nice and cryptic enough.

After true BHs have gone, just say that "bh" is alias for "softirq".

Alexey

Re: [RFC] Rename _bh to _softirq

[Maksim (Max) Krasnyanskiy]

At 05:57 AM 10/15/2002 +0400, kuznet@ms2.inr.ac.ru wrote:
>Hello!
>
> >         But yes, i agree, and there are a number of other
> > renames that would make perfect sense.
>
>Oh, do you dislike names with history? I love them. :-)
>Well, bh is short, looks nice and cryptic enough.
>
>After true BHs have gone, just say that "bh" is alias for "softirq".
Sure. Just like I said we can keep compatibility defines
         #define local_bh_disable local_softirq_disable

But primary interface should be changed IMO.

Max

Re: [RFC] Rename _bh to _softirq

[David S. Miller]

   From: "Maksim (Max) Krasnyanskiy" <maxk@qualcomm.com>
   Date: Tue, 15 Oct 2002 09:34:02 -0700
   
   But primary interface should be changed IMO.

I totally disagree.

Keep _bh, it's cool.

Re: [RFC] Rename _bh to _softirq

[Maksim (Max) Krasnyanskiy]

At 10:44 AM 10/15/2002 -0700, David S. Miller wrote:
>    From: "Maksim (Max) Krasnyanskiy" <maxk@qualcomm.com>
>    Date: Tue, 15 Oct 2002 09:34:02 -0700
>
>    But primary interface should be changed IMO.
>
>I totally disagree.
Care to explain why ?

>Keep _bh, it's cool.
But pretty much meaningless. _softirq on the other hand clearly shows what 
it does.
We don't give names to a functions based on the coolness, do we ? ;-)

btw _si would be equally cool.

Max

Re: [RFC] Rename _bh to _softirq

[David S. Miller]

   From: "Maksim (Max) Krasnyanskiy" <maxk@qualcomm.com>
   Date: Tue, 15 Oct 2002 12:24:18 -0700

   We don't give names to a functions based on the coolness, do we ?
   ;-)

cli() was cool too.

Just because you don't see that a base handler really is an
alias for softirq these days, doesn't mean we should delete
it.

Re: [RFC] Rename _bh to _softirq

[Oliver Xymoron]

On Tue, Oct 15, 2002 at 12:24:18PM -0700, Maksim (Max) Krasnyanskiy wrote:
> At 10:44 AM 10/15/2002 -0700, David S. Miller wrote:
> >   From: "Maksim (Max) Krasnyanskiy" <maxk@qualcomm.com>
> >   Date: Tue, 15 Oct 2002 09:34:02 -0700
> >
> >   But primary interface should be changed IMO.
> >
> >I totally disagree.
> Care to explain why ?
> 
> >Keep _bh, it's cool.
> But pretty much meaningless.

No, now it clearly means buffer head.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

Re: [RFC] Rename _bh to _softirq

[David S. Miller]

   From: "Maksim (Max) Krasnyanskiy" <maxk@qualcomm.com>
   Date: Tue, 15 Oct 2002 13:23:28 -0700

   _bh is not a "base handler" it stands for "bottom half".
   
All of these phrases mean the same thing to me.

Do you want to know what is different?  "tasklets",
they are a totally different abstraction, as are
"work queues".

"base handler" and "bottom half" all refer to an execution
context, and these days that means softirq.

   
   
   
   

Re: [RFC] Rename _bh to _softirq

[Maksim (Max) Krasnyanskiy]

At 12:42 PM 10/15/2002 -0700, David S. Miller wrote:
>    From: "Maksim (Max) Krasnyanskiy" <maxk@qualcomm.com>
>    Date: Tue, 15 Oct 2002 12:24:18 -0700
>
>    We don't give names to a functions based on the coolness, do we ?
>    ;-)
>
>cli() was cool too.
But we did rename it.

>Just because you don't see that a base handler really is an
>alias for softirq these days, doesn't mean we should delete it.
Dave, you just confirmed that _bh is indeed confusing. And some
people don't even know what it is ;-).
_bh is not a "base handler" it stands for "bottom half".

Max

Re: [RFC] Rename _bh to _softirq

[Maksim (Max) Krasnyanskiy]

Oliver,

> > >   But primary interface should be changed IMO.
> > >
> > >I totally disagree.
> > Care to explain why ?
> >
> > >Keep _bh, it's cool.
> > But pretty much meaningless.
>
>No, now it clearly means buffer head.
Another point in favor of renaming :).

local_bh_disable() disables local _softirqs_ not "local buffer head".

Max

Re: [RFC] Rename _bh to _softirq

[David S. Miller]

   From: "Maksim (Max) Krasnyanskiy" <maxk@qualcomm.com>
   Date: Tue, 15 Oct 2002 14:02:22 -0700

   I guess we should then have some kinda readme that explains what
   all those things are. And the BH context covers softirqs and tasklets.

That sounds fine.

Re: [RFC] Rename _bh to _softirq

[Maksim (Max) Krasnyanskiy]

At 01:19 PM 10/15/2002 -0700, David S. Miller wrote:
>    From: "Maksim (Max) Krasnyanskiy" <maxk@qualcomm.com>
>    Date: Tue, 15 Oct 2002 13:23:28 -0700
>
>    _bh is not a "base handler" it stands for "bottom half".
>
>All of these phrases mean the same thing to me.
>
>Do you want to know what is different?  "tasklets",
>they are a totally different abstraction,
tasklets are softirqs. I mean they aren't much different. Tasklets are 
executed
from the softirq, so they have same context and stuff.

>as are "work queues"
Yep. These are different, because they are executed in process context.

>"base handler" and "bottom half" all refer to an execution
>context, and these days that means softirq.
I guess we should then have some kinda readme that explains what
all those things are. And the BH context covers softirqs and tasklets.

Max

Re: [RFC] Rename _bh to _softirq

[Ingo Molnar]

On Tue, 15 Oct 2002, Maksim (Max) Krasnyanskiy wrote:

> >No, now it clearly means buffer head.
> Another point in favor of renaming :).
> 
> local_bh_disable() disables local _softirqs_ not "local buffer head".

they seldom occur in the same neighborhood - i've never mistaken buffer 
heads for bottom halves.

	Ingo

Re: [RFC] Rename _bh to _softirq

[Ingo Molnar]

On Tue, 15 Oct 2002, David S. Miller wrote:

>    _bh is not a "base handler" it stands for "bottom half".
>
> "base handler" and "bottom half" all refer to an execution context,
> and these days that means softirq.

i think i agree with you.

- we have 'top half' contexts, which are also called 'hardirqs'.

- then we have 'bottom half' contexts, which are also called 'softirqs'.

the fact that 'bottom halves' used to be an earlier concept that had a
slightly different meaning from 'softirqs' for a limited amount of time
does not remove from the meaningfulness of the naming itself. Today
'bottom halves' and 'softirqs' are the same thing.

	Ingo

Re: [RFC] Rename _bh to _softirq

[Brad Hards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 16 Oct 2002 06:58, David S. Miller wrote:
>    From: "Maksim (Max) Krasnyanskiy" <maxk@qualcomm.com>
>    Date: Tue, 15 Oct 2002 14:02:22 -0700
>
>    I guess we should then have some kinda readme that explains what
>    all those things are. And the BH context covers softirqs and tasklets.
>
> That sounds fine.
Documentation/DocBook/kernel-hacking.tmpl

It is such a fine idea, Rusty already did it...

Brad

- -- 
http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9rIg1W6pHgIdAuOMRAv7zAJ95Eo1zgh2LWYxesk+LlWQ+U8O2OACfb8Qa
Kfx4vfcbofHxfr6muMvi1WE=
=1Ukc
-----END PGP SIGNATURE-----

Re: [RFC] Rename _bh to _softirq

[Ingo Molnar]

On Tue, 15 Oct 2002, Maksim (Max) Krasnyanskiy wrote:

> tasklets are softirqs. I mean they aren't much different. Tasklets are
> executed from the softirq, so they have same context and stuff.

well, tasklets are a subset of softirqs, in that the code triggered by a
tasklet can run only on one CPU at once. Ie. they are a special kind of
softirq that knows about global things like "I'm executing currently".

Ie., just to confuse things, they are similar to what old-BHs used to be,
with the difference that the enumeration of tasklets is much nicer
(pointer based and can be embedded in any structure), not some global
registry of integers like old-BHs were.

(tasklets can also be scheduled via two priority levels: a 'high' priority
scheduling and a 'low' priority scheduling. old-BHs used to have fixed
priority levels directly attached to their global enumeration integer
values.)

	Ingo

Re: [RFC] Rename _bh to _softirq

[Maksim (Max) Krasnyanskiy]

> > "base handler" and "bottom half" all refer to an execution context,
> > and these days that means softirq.
>
>i think i agree with you.
>
>- we have 'top half' contexts, which are also called 'hardirqs'.
>
>- then we have 'bottom half' contexts, which are also called 'softirqs'.
>
>the fact that 'bottom halves' used to be an earlier concept that had a
>slightly different meaning from 'softirqs' for a limited amount of time
>does not remove from the meaningfulness of the naming itself. Today
>'bottom halves' and 'softirqs' are the same thing.

I still think we should rename _bh thing :). At least for consistent naming.
We have things like:
         in_softirq()
         do_softirq()
         sofirq_pending()
and
         local_bh_disable()
         local_bh_enable()

Anyway, I'll go ahead and shut up :). Most people didn't seem to like that 
proposal :(.

Max