linux-kernel - uvesafb in 2.6.27-rc9 uses mode_option, in 2.6.27 mode, but the docs aren't updated

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-next>] [day] [month] [year] [list]

Date:	Tue, 7 Oct 2008 18:54:10 +0000
From:	root <thunder7@...all.nl>
To:	linux-fb-devel@...ts.sourceforge.net
Cc:	linux-kernel@...r.kernel.org
Subject: uvesafb in 2.6.27-rc9 uses mode_option, in 2.6.27 mode, but the
	docs aren't updated

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?

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.

Kind regards,
Jurriaan
--
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/