lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 9 Oct 2008 10:56:34 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	root <thunder7@...all.nl>
Cc:	linux-fb-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
	Michal Januszewski <spock@...too.org>,
	Krzysztof Helt <krzysztof.h1@...pl>,
	akpm <akpm@...ux-foundation.org>
Subject: [PATCH] docs: Re: uvesafb in 2.6.27-rc9 uses mode_option, in 2.6.27
 mode, but the docs aren't updated

On Tue, 7 Oct 2008 18:54:10 +0000 root wrote:

> I just tested 2.6.27-rc9 on my laptop, which uses uvesafb. I notice that
> I need to update
> 
> /sbin/modprobe uvesafb mode=1400x1050
> 
> to
> 
> /sbin/modprobe uvesafb mode_option=1400x1050
> 
> but the documentation in Documentation/fb/uvesafb.txt happily talks
> about the mode option. It would be nice to have the documentation
> updated at least, but might I also question this move at all? Why call
> something 'mode_option' when 'mode' is shorter and the fact that it's an
> option really is clear from the fact you mention it on the commandline,
> like, how-do-I-call-it, yes-I-remember, an option?

True, but most framebuffer drivers use 'mode_option', so this one was
converted to be more normal.  And I was outvoted.  :(
[I wrote on 2008-FEB-05:
I would (do) say that "mode_option" is being redundant.  Yes, it's
an option, but we don't usually name options (in other parts of the
kernel) with an _option suffix.  Sure, the variable could be called
<mode_option>, but the userspace name should just be "mode".  IMHO.

Please keep Documentation/fb/modedb.txt updated if you make any
relevant changes.
]



> Or are we moving toward 'mtrr_option', 'scroll_option',
> 'vram_remap_option' etc? I don't think that really a good idea, so the
> easiest thing to do would be to revert the patch that did this rename,
> since that resyncs the Documentation to the actual module and removes
> the needless description of the 'mode' option.



From: Randy Dunlap <randy.dunlap@...cle.com>

uvesafb was switched from the 'mode' parameter to the more common (in
fb-land) 'mode_option' parameter, so update the documentation for that.

Signed-off-by: Randy Dunlap <randy.dunlap@...cle.com>
Reported-by: root <thunder7@...all.nl>
cc: Krzysztof Helt <krzysztof.h1@...pl>
cc: Michal Januszewski <spock@...too.org>
---
 Documentation/fb/uvesafb.txt |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.27-rc9-git2.orig/Documentation/fb/uvesafb.txt
+++ linux-2.6.27-rc9-git2/Documentation/fb/uvesafb.txt
@@ -52,7 +52,7 @@ are either given on the kernel command l
 
  video=uvesafb:1024x768-32,mtrr:3,ywrap (compiled into the kernel)
 
- # modprobe uvesafb mode=1024x768-32 mtrr=3 scroll=ywrap  (module)
+ # modprobe uvesafb mode_option=1024x768-32 mtrr=3 scroll=ywrap  (module)
 
 Accepted options:
 
@@ -105,7 +105,7 @@ vtotal:n
 <mode>  The mode you want to set, in the standard modedb format.  Refer to
         modedb.txt for a detailed description.  When uvesafb is compiled as
         a module, the mode string should be provided as a value of the
-        'mode' option.
+        'mode_option' parameter.
 
 vbemode:x
         Force the use of VBE mode x.  The mode will only be set if it's
@@ -182,7 +182,7 @@ from the Video BIOS if you set pixclock 
 
 --
  Michal Januszewski <spock@...too.org>
- Last updated: 2007-06-16
+ Last updated: 2008-10-09
 
  Documentation of the uvesafb options is loosely based on vesafb.txt.
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ