2.6.1-mm4
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 20040119224219.65991501.rusty@rustcorp.com.au.suse.lists.linux.kernel
Quoted 2 lines · Rusty Russell
Migrating to
module_param()is the Right Thing here IMHO, which actually takes the damn address,
The main problem is that module_parm renames the boot time arguments and makes them long and hard to remember. E.g. the new argument needed to make the mouse work on KVMs is mindboogling, could be nearly a Windows registry entry.
-Andi
In message <[email protected]> you write:
Quoted 7 lines
Quoted 2 lines · Rusty Russell
Migrating to
module_param()is the Right Thing here IMHO, which actually takes the damn address,The main problem is that
module_parmrenames the boot time arguments and makes them long and hard to remember.
Um, if the module name is neat, and the parameter name is neat, the combination of the two with a "." between them will be nest.
Quoted 2 lines
E.g. the new argument needed to make the mouse work on KVMs is mindboogling, could be nearly a Windows registry entry.
I have no idea what you are talking about. 8(
Please explain,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Quoted 4 lines · Rusty Russell
Quoted 2 lines
E.g. the new argument needed to make the mouse work on KVMs is mindboogling, could be nearly a Windows registry entry.
I have no idea what you are talking about. 8(
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs
That's the name of a registry entry. I don't think iwe're quite THAT bad. ;)
Quoted 9 lines · Rusty Russell
In message <[email protected]> you write:
Quoted 7 lines
Quoted 2 lines · Rusty Russell
Migrating to
module_param()is the Right Thing here IMHO, which actually takes the damn address,The main problem is that
module_parmrenames the boot time arguments and makes them long and hard to remember.
Quoted 7 lines
Um, if the module name is neat, and the parameter name is neat, the combination of the two with a "." between them will be nest.
Quoted 2 lines
E.g. the new argument needed to make the mouse work on KVMs is mindboogling, could be nearly a Windows registry entry.
I have no idea what you are talking about. 8(
Inbetween the module changes and the input changes there was a situation, where you'd have to pass
psmouse.psmouse_maxproto=imps2
as a kernel argument. This should (I hope so, I have to check) be fixed now.
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 8 lines · On Wed, 21 Jan 2004 09:40:09 +0100 Vojtech Pavlik <[email protected]> wrote:
Inbetween the module changes and the input changes there was a situation, where you'd have to pass
psmouse.psmouse_maxproto=imps2
as a kernel argument. This should (I hope so, I have to check) be fixed now.
No, 2.6.1 requires it.
And worst is that you have to reboot to change mouse settings at all. That just doesn't make any sense. Can you please add an runtime sysfs interface for this?
-Andi
Quoted 9 lines · Andi Kleen
Quoted 6 lines · On Wed, 21 Jan 2004 09:40:09 +0100 Vojtech Pavlik <[email protected]> wrote:
Inbetween the module changes and the input changes there was a situation, where you'd have to pass
psmouse.psmouse_maxproto=imps2
Quoted 8 lines
Quoted 2 lines
as a kernel argument. This should (I hope so, I have to check) be fixed now.
No, 2.6.1 requires it.
And worst is that you have to reboot to change mouse settings at all. That just doesn't make any sense. Can you please add an runtime sysfs interface for this?
It's planned, though not easy to implement at all. I don't think I'll be able to get this into 2.6.2. For now you can enable EMBEDDED, compile psmouse as a module, and just rmmod/insmod it with new parameters.
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 15 lines · On Wed, 21 Jan 2004 13:34:54 +0100 Vojtech Pavlik <[email protected]> wrote:
Quoted 14 lines · Andi Kleen
Quoted 8 lines · On Wed, 21 Jan 2004 09:40:09 +0100 Vojtech Pavlik <[email protected]> wrote:
Inbetween the module changes and the input changes there was a situation, where you'd have to pass
psmouse.psmouse_maxproto=imps2
as a kernel argument. This should (I hope so, I have to check) be fixed now.
No, 2.6.1 requires it.
Quoted 7 lines
Quoted 3 lines
And worst is that you have to reboot to change mouse settings at all. That just doesn't make any sense. Can you please add an runtime sysfs interface for this?
It's planned, though not easy to implement at all. I don't think I'll be able to get this into 2.6.2. For now you can enable EMBEDDED, compile psmouse as a module, and just rmmod/insmod it with new parameters.
Really. I don't want a modular mouse driver, just a mouse that keeps working over kernel releases without me requiring tracking undocumented changes every release. Thanks for the warning that you renamed it again, at least that will save some reboots next time.
Could you perhaps readd the old __setup that at least the old version keeps working? After that you can rename it again as often as you want as long as the old alias keeps working ;-)
As for the implementation of doing it at runtime - i took a look at it but got scared by sysfs livetime rules and the lack of callbacks in module_parm. I think the easiest way would be to just poll the value: make it a module_parm with the w bit enabled, add a second set of state variables and every time you access the mouse you compare the module_parm variables and the shadow variables and change the mouse setting if they differ. Not pretty, but would probably work without too much sysfs black magic.
-Andi
Quoted 1 line
Quoted 7 lines · Andi Kleen
As for the implementation of doing it at runtime - i took a look at it but got scared by sysfs livetime rules and the lack of callbacks in
module_parm. I think the easiest way would be to just poll the value: make it amodule_parmwith the w bit enabled, add a second set of state variables and every time you access the mouse you compare themodule_parmvariables and the shadow variables and change the mouse setting if they differ. Not pretty, but would probably work without too much sysfs black magic.
The second problem (after the sysfs magic) is that I'd have to completely reinitialize the mouse as well, down to the features of the mouse changing (for example no wheel anymore).
So, it's planned, but don't expect it in 2.6.2.
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
In message <[email protected]> you write:
Quoted 3 lines
As for the implementation of doing it at runtime - i took a look at it but got scared by sysfs livetime rules and the lack of callbacks in
module_parm.
FYI module_parm is just a convenience wrapper around
module_param_call(name, set, get, arg, perm)
Where get and set are the callbacks:
/* Returns 0, or -errno. arg is in kp->arg. */ typedef int (*param_set_fn)(const char *val, struct kernel_param *kp); /* Returns length written or -errno. Buffer is 4k (ie. be short!) */ typedef int (*param_get_fn)(char *buffer, struct kernel_param *kp);
With these the implementation should be fairly neat.
Hope that clarifies,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Quoted 14 lines · Vojtech Pavlik
Quoted 13 lines · Andi Kleen
On Wed, 21 Jan 2004 09:40:09 +0100
Quoted 7 lines · Vojtech Pavlik
Inbetween the module changes and the input changes there was a situation, where you'd have to pass
psmouse.psmouse_maxproto=imps2
as a kernel argument. This should (I hope so, I have to check) be fixed now.
No, 2.6.1 requires it.
Quoted 8 lines
Quoted 3 lines
And worst is that you have to reboot to change mouse settings at all. That just doesn't make any sense. Can you please add an runtime sysfs interface for this?
It's planned, though not easy to implement at all. I don't think I'll be able to get this into 2.6.2. For now you can enable EMBEDDED, compile psmouse as a module, and just rmmod/insmod it with new parameters.
No, it's just mousedev that is always built-in, psmouse can be compiled as a module (and that's the reason the whole naming mess happened - I use it as a module and haven't noticed the necessity of the prefixes when converted to the module_param()).
Signature · 1 line
Dmitry
mouse configuration in 2.6.1
In reply to Rusty RussellQuoted 11 lines · On Wed, 21 Jan 2004 15:06:57 +1100 Rusty Russell <[email protected]> wrote:
In message <[email protected]> you write:
Quoted 7 lines
Quoted 2 lines · Rusty Russell
Migrating to
module_param()is the Right Thing here IMHO, which actually takes the damn address,The main problem is that
module_parmrenames the boot time arguments and makes them long and hard to remember.Um, if the module name is neat, and the parameter name is neat, the combination of the two with a "." between them will be nest.
Unfortunately we have lots of non neat module names and many previous boot time arguments note their subsystem which adds even more redundancy.
And you're suggesting people to move to module_parm now in the stable series leads to renaming of module parameters, which breaks previously working configurations in often subtle ways. Maybe that's acceptable in a unstable development kernel, but I don't think it is in 2.6.
How about adding a "setup option alias" table and require that everybody changing an existing __setup to module_parm adds an alias there?
Quoted 4 lines
Quoted 2 lines
E.g. the new argument needed to make the mouse work on KVMs is mindboogling, could be nearly a Windows registry entry.
I have no idea what you are talking about. 8(
psmouse_base.psmouse_noext
(brought to you by the department of redundancy department)
The "new" and "improved" version is apparently:
psmouse_base.psmouse_proto=bare
which is even worse.
And 2.6.0 -> 2.6.1 silently changing to that without any documentation anywhere, silently breaking my mouse. And debugging it requires a lot of reboots because we have regressed to Windows state where every mouse setting change requires a reboot :-/
Sorry Rusty. You are probably the wrong target for the flame, but a combination of probably well intended changes including module_parm brought a total usability disaster here.
-Andi
Re: mouse configuration in 2.6.1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 31 lines · Andi Kleen
Quoted 11 lines · On Wed, 21 Jan 2004 15:06:57 +1100 Rusty Russell <[email protected]> wrote:
In message <[email protected]> you write:
Quoted 7 lines
Quoted 2 lines · Rusty Russell
Migrating to
module_param()is the Right Thing here IMHO, which actually takes the damn address,The main problem is that
module_parmrenames the boot time arguments and makes them long and hard to remember.Um, if the module name is neat, and the parameter name is neat, the combination of the two with a "." between them will be nest.
Unfortunately we have lots of non neat module names and many previous boot time arguments note their subsystem which adds even more redundancy.
And you're suggesting people to move to
module_parmnow in the stable series leads to renaming of module parameters, which breaks previously working configurations in often subtle ways. Maybe that's acceptable in a unstable development kernel, but I don't think it is in 2.6.How about adding a "setup option alias" table and require that everybody changing an existing
__setuptomodule_parmadds an alias there?Quoted 4 lines
Quoted 2 lines
E.g. the new argument needed to make the mouse work on KVMs is mindboogling, could be nearly a Windows registry entry.
I have no idea what you are talking about. 8(
Quoted 7 lines
psmouse_base.psmouse_noext
(brought to you by the department of redundancy department)
The "new" and "improved" version is apparently:
psmouse_base.psmouse_proto=bare
Actually it's psmouse.proto=bare
Quoted 13 lines
which is even worse.
And 2.6.0 -> 2.6.1 silently changing to that without any documentation anywhere, silently breaking my mouse. And debugging it requires a lot of reboots because we have regressed to Windows state where every mouse setting change requires a reboot :-/
Sorry Rusty. You are probably the wrong target for the flame, but a combination of probably well intended changes including
module_parmbrought a total usability disaster here.(quoted diff) +0
-2-Andi -
Quoted 5 lines
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- --
==================================================
Marcos Daniel Marado Torres AKA Mind Booster Noori
/"\ http://student.dei.uc.pt/~marado
\ / [email protected]
X ASCII Ribbon Campaign
/ \ against HTML e-mail and Micro$oft attachments
==================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFADnEbmNlq8m+oD34RAmatAKCBEpHzK1KzpmOQ6T8fveaL5j6bJgCeP+AA N57BBoKD2an9Cg3ifJVYvh0=
=ikyB
-----END PGP SIGNATURE-----
Re: mouse configuration in 2.6.1
Quoted 5 lines · On Wed, 21 Jan 2004 12:31:21 +0000 (WET) "Marcos D. Marado Torres"…
apparently:
Quoted 2 lines
psmouse_base.psmouse_proto=bare
Actually it's psmouse.proto=bare
In 2.6.1 it is definitely psmouse_base.psmouse_proto=bare
-Andi
Re: mouse configuration in 2.6.1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 10 lines · Andi Kleen
Quoted 5 lines · On Wed, 21 Jan 2004 12:31:21 +0000 (WET) "Marcos D. Marado Torres"…
apparently:
Quoted 2 lines
psmouse_base.psmouse_proto=bare
Actually it's psmouse.proto=bare
In 2.6.1 it is definitely psmouse_base.psmouse_proto=bare
Do you have it compiled as a module?
Quoted 7 lines
(quoted diff) +0
-2-Andi -To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- --
==================================================
Marcos Daniel Marado Torres AKA Mind Booster Noori
/"\ http://student.dei.uc.pt/~marado
\ / [email protected]
X ASCII Ribbon Campaign
/ \ against HTML e-mail and Micro$oft attachments
==================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFADnY7mNlq8m+oD34RAjSgAKDfYlvGpTiBTnlr8NXWbfpWcyAV5wCfafMb aihlrtCkWQNtIXI4EuhERos=
=oxw2
-----END PGP SIGNATURE-----
Re: mouse configuration in 2.6.1
Quoted 10 lines · On Wed, 21 Jan 2004 12:53:12 +0000 (WET) "Marcos D. Marado Torres"…
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 5 lines · Andi Kleen
Quoted 2 lines · On Wed, 21 Jan 2004 12:31:21 +0000 (WET) "Marcos D. Marado Torres"…
apparently:
Quoted 1 line
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
psmouse_base.psmouse_proto=bare
Actually it's psmouse.proto=bare
In 2.6.1 it is definitely psmouse_base.psmouse_proto=bare
Do you have it compiled as a module?
No of course not. For a module it would be psmouse_proto=bare
-Andi
Re: mouse configuration in 2.6.1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 17 lines · Andi Kleen
Quoted 14 lines · On Wed, 21 Jan 2004 12:53:12 +0000 (WET) "Marcos D. Marado Torres"…
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 9 lines · Andi Kleen
Quoted 5 lines · On Wed, 21 Jan 2004 12:31:21 +0000 (WET) "Marcos D. Marado Torres"…
apparently:
Quoted 2 lines
psmouse_base.psmouse_proto=bare
Actually it's psmouse.proto=bare
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
In 2.6.1 it is definitely psmouse_base.psmouse_proto=bare
Do you have it compiled as a module?
No of course not. For a module it would be psmouse_proto=bare
-Andi
Oh, I'm sorry, I was talking about 2.6.2-rc1.
Starting in 2.6.1-mm* and now in 2.6.2-rc1 you just have to pass psmouse.proto=bare .
- --
==================================================
Marcos Daniel Marado Torres AKA Mind Booster Noori
/"\ http://student.dei.uc.pt/~marado
\ / [email protected]
X ASCII Ribbon Campaign
/ \ against HTML e-mail and Micro$oft attachments
==================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFADnlOmNlq8m+oD34RAgdPAKDeeGMpZOq2ObzIEVHyzUb8ovBarACfdIk0 owGg+aqr2clAfXNod323y9c=
=6PbO
-----END PGP SIGNATURE-----
Re: mouse configuration in 2.6.1
In reply to Andi KleenQuoted 10 lines · Andi Kleen
On Wed, 21 Jan 2004 12:31:21 +0000 (WET)
Quoted 4 lines · Marcos D. Marado Torres
apparently:
Quoted 1 line
psmouse_base.psmouse_proto=bare
Actually it's psmouse.proto=bare
In 2.6.1 it is definitely psmouse_base.psmouse_proto=bare
You really should see psmouse.psmouse_proto=bare in 2.6.1 (and it's changed to psmouse.proto=bare in 2.6.2-rc1):
make KBUILD_MODULES=1 -f scripts/Makefile.build obj=drivers/input/mouse
gcc -Wp,-MD,drivers/input/mouse/.psmouse-base.o.d -nostdinc -iwithprefix include -D__KERNEL__ -Iinclude -D__KERNEL__ -Iinclude
-Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=pentium3 -Iinclude/asm-i386/mach-default -O2
-DMODULE -DKBUILD_BASENAME=psmouse_base -DKBUILD_MODNAME=psmouse -c -o drivers/input/mouse/.tmp_psmouse-base.o drivers/input/mouse/psmouse-base.c
As you can see KBUILD_MODNAME is just psmouse and module_param() uses it as a prefix.
Signature · 1 line
Dmitry
Re: mouse configuration in 2.6.1
In reply to Andi KleenQuoted 5 lines · Andi Kleen
(brought to you by the department of redundancy department)
The "new" and "improved" version is apparently:
psmouse_base.psmouse_proto=bare
2.6.2 will have it as:
psmouse.proto=bare
which isn't that bad.
Quoted 8 lines
And 2.6.0 -> 2.6.1 silently changing to that without any documentation anywhere, silently breaking my mouse. And debugging it requires a lot of reboots because we have regressed to Windows state where every mouse setting change requires a reboot :-/
Sorry Rusty. You are probably the wrong target for the flame, but a combination of probably well intended changes including
module_parmbrought a total usability disaster here.
Keep prepared for yet another silent change (documentation _is_ getting updated, though). And I'll don my asbestos overall ...
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Re: mouse configuration in 2.6.1
In reply to Andi KleenIn message <[email protected]> you write:
Quoted 7 lines
Unfortunately we have lots of non neat module names and many previous boot time arguments note their subsystem which adds even more redundancy.
And you're suggesting people to move to
module_parmnow in the stable series leads to renaming of module parameters, which breaks previously working configurations in often subtle ways. Maybe that's acceptable in a unstable development kernel, but I don't think it is in 2.6.
I think we're getting a little confused here.
I'm saying that people should start using module_param instead of MODULE_PARM in new code, or code being reworked. This adds a boot param where there was none before.
I'm explicitly not advocating replacing __setup() for existing code.
Quoted 2 lines
And 2.6.0 -> 2.6.1 silently changing to that without any documentation anywhere, silently breaking my mouse.
That's bad. I would have left the old __setup under #ifdef CONFIG_OBSOLETE_MODPARM (or something where it can eventually go away). And maybe a printk warning about using the old name.
Quoted 3 lines
Sorry Rusty. You are probably the wrong target for the flame, but a combination of probably well intended changes including
module_parmbrought a total usability disaster here.
Perhaps I am the wrong target, but I'm glad you brought it up.
I thought that changing __setup to module_param() would have obvious effects, and authors would make their own call on that.
FYI: __setup and module_param() *CAN* be freely mixed, unlike MODULE_PARM and module_param().
Hope that clarifies,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.