Re: 2.6.1-mm4

Re: 2.6.1-mm4

[Andi Kleen]

Rusty Russell <rusty@rustcorp.com.au> writes:

> 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

Re: 2.6.1-mm4

[Rusty Russell]

In message <p73r7xwglgn.fsf@verdi.suse.de> you write:
> Rusty Russell <rusty@rustcorp.com.au> writes:
> 
> > 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.

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.

> 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.

Re: 2.6.1-mm4

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

On Wed, 21 Jan 2004 15:06:57 +1100, Rusty Russell said:

> > 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. ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: 2.6.1-mm4

[Vojtech Pavlik]

On Wed, Jan 21, 2004 at 03:06:57PM +1100, Rusty Russell wrote:
> In message <p73r7xwglgn.fsf@verdi.suse.de> you write:
> > Rusty Russell <rusty@rustcorp.com.au> writes:
> > 
> > > 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.
> 
> 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.
> 
> > 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.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

mouse configuration in 2.6.1

[Andi Kleen]

On Wed, 21 Jan 2004 15:06:57 +1100
Rusty Russell <rusty@rustcorp.com.au> wrote:

> In message <p73r7xwglgn.fsf@verdi.suse.de> you write:
> > Rusty Russell <rusty@rustcorp.com.au> writes:
> > 
> > > 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.
> 
> 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?

> > 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: 2.6.1-mm4

[Andi Kleen]

On Wed, 21 Jan 2004 09:40:09 +0100
Vojtech Pavlik <vojtech@suse.cz> 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

Re: mouse configuration in 2.6.1

[Marcos D. Marado Torres]

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

On Wed, 21 Jan 2004, Andi Kleen wrote:

> On Wed, 21 Jan 2004 15:06:57 +1100
> Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> > In message <p73r7xwglgn.fsf@verdi.suse.de> you write:
> > > Rusty Russell <rusty@rustcorp.com.au> writes:
> > >
> > > > 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.
> >
> > 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?
>
> > > 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

Actually it's 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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> 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
\ /                       marado@student.dei.uc.pt
 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

[Vojtech Pavlik]

On Wed, Jan 21, 2004 at 01:23:37PM +0100, Andi Kleen wrote:

> (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.

> 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.

Keep prepared for yet another silent change (documentation _is_ getting
updated, though). And I'll don my asbestos overall ...

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: 2.6.1-mm4

[Vojtech Pavlik]

On Wed, Jan 21, 2004 at 01:27:44PM +0100, Andi Kleen wrote:
> On Wed, 21 Jan 2004 09:40:09 +0100
> Vojtech Pavlik <vojtech@suse.cz> 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?

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.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: mouse configuration in 2.6.1

[Andi Kleen]

On Wed, 21 Jan 2004 12:31:21 +0000 (WET)
"Marcos D. Marado Torres" <marado@student.dei.uc.pt> wrote:

> apparently:
> >
> > 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: 2.6.1-mm4

[Andi Kleen]

On Wed, 21 Jan 2004 13:34:54 +0100
Vojtech Pavlik <vojtech@suse.cz> wrote:

> On Wed, Jan 21, 2004 at 01:27:44PM +0100, Andi Kleen wrote:
> > On Wed, 21 Jan 2004 09:40:09 +0100
> > Vojtech Pavlik <vojtech@suse.cz> 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?
> 
> 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

>

Re: mouse configuration in 2.6.1

[Marcos D. Marado Torres]

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

On Wed, 21 Jan 2004, Andi Kleen wrote:

> On Wed, 21 Jan 2004 12:31:21 +0000 (WET)
> "Marcos D. Marado Torres" <marado@student.dei.uc.pt> wrote:
>
> > apparently:
> > >
> > > 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?

> -Andi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> 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
\ /                       marado@student.dei.uc.pt
 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: 2.6.1-mm4

[Dmitry Torokhov]

On Wednesday 21 January 2004 07:34 am, Vojtech Pavlik wrote:
> On Wed, Jan 21, 2004 at 01:27:44PM +0100, Andi Kleen wrote:
> > On Wed, 21 Jan 2004 09:40:09 +0100
> >
> > Vojtech Pavlik <vojtech@suse.cz> 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?
>
> 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()).

-- 
Dmitry

Re: mouse configuration in 2.6.1

[Andi Kleen]

On Wed, 21 Jan 2004 12:53:12 +0000 (WET)
"Marcos D. Marado Torres" <marado@student.dei.uc.pt> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 21 Jan 2004, Andi Kleen wrote:
> 
> > On Wed, 21 Jan 2004 12:31:21 +0000 (WET)
> > "Marcos D. Marado Torres" <marado@student.dei.uc.pt> wrote:
> >
> > > apparently:
> > > >
> > > > 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

[Marcos D. Marado Torres]

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

On Wed, 21 Jan 2004, Andi Kleen wrote:

> On Wed, 21 Jan 2004 12:53:12 +0000 (WET)
> "Marcos D. Marado Torres" <marado@student.dei.uc.pt> wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Wed, 21 Jan 2004, Andi Kleen wrote:
> >
> > > On Wed, 21 Jan 2004 12:31:21 +0000 (WET)
> > > "Marcos D. Marado Torres" <marado@student.dei.uc.pt> wrote:
> > >
> > > > apparently:
> > > > >
> > > > > 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
>

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
\ /                       marado@student.dei.uc.pt
 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

[Dmitry Torokhov]

On Wednesday 21 January 2004 07:42 am, Andi Kleen wrote:
> On Wed, 21 Jan 2004 12:31:21 +0000 (WET)
>
> "Marcos D. Marado Torres" <marado@student.dei.uc.pt> wrote:
> > apparently:
> > > 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.

-- 
Dmitry

Re: 2.6.1-mm4

[Vojtech Pavlik]

On Wed, Jan 21, 2004 at 01:46:57PM +0100, Andi Kleen wrote:

> 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.

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.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: mouse configuration in 2.6.1

[Rusty Russell]

In message <20040121132337.7f8d3c79.ak@suse.de> you write:
> 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.

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.

> 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.

> 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.

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.

Re: 2.6.1-mm4

[Rusty Russell]

In message <20040121134657.6cd27cbd.ak@suse.de> you write:

> 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.