Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console
#include hallo.h * Herbert Xu [Sun, Nov 03 2002, 10:29:54PM]: The calls cannot be made _ever_ once the kernel has been booted unless you resort to such trickery as using a BIOS emulator like Gerg alluded too. The kernel simply has no mechanism for calling real mode x86 BIOS code. The fact that the mode switching has to be compiled in statically does not preclude the modularisation of vesafb since it is already a separate piece of code goverened by a different CONFIG option. Well, could you explain the connection between a config option and the actuall feasibility? Which I do not belive is correct. Once the VESA call has been made to switch the framebuffer from cell mode (ie text mode) to bitmap mode the normal text console driver will stop working completely. If the kernel does not immediately boot and begin using vesafb+fbcon it will no longer be able to display anything. If VESAFB is modularised, then you would load it from the initrd just s/If/When/, that is the question. I do not see anybody working on modularizing it, do you? From my point of view, the things are clear: No kernel developer really needs it or has too much spare time to work on modularisation of VESAFB. The driver is so small that there is no problem including it into the kernel. We can either wait for a wonder that will never happen, or you can rewrite the driver by yourself, or admit that including it is not that bad and just do it. As a proof that this already works, just look at how TGAFB is loaded on alpha. It is completely analogous to this situation except that the video mode switching is already done. Really? I do not know about compatibility modes on Alpha such as the sick oldcompatible real mode on i386. Gruss/Regards, Eduard. -- Debian: All the power, no red hats, no green chameleons.
Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
#include hallo.h * Manoj Srivastava [Sat, Oct 26 2002, 12:10:06AM]: Maintainability? There is more to clean code than mere aesthetics. As the kernel moves towards initrds and modularity, crufty Yes, you and Xu are of the same kind. You place some ideals (code perfectness, even with harmless code) over user's wishes. Ian Guesswork. No-one in this argument has any concrete data. Yes. But the mainainer, being close to the package, and presumably interacting with more users than non maintainers, often has a better feel for subjective guess work like this. Exactly this is the question and the answer (here) is: NO. Ian Do business users often turn on quotas on desktop machines ? I'd be Ian surprised. For servers, of course, most people will (or should!) Ian build their own kernels. Then I think you should be prepared to be surprised; Dec/Compaq, the university of massachusetts at amherst (various departments), and several other companies I a=have ahd contact with all had soft and hard quotas turned on. Well, on how machines? Sure they should be enabled on large servers, the number of them is not impressive. The maintainer has come up with a reasonable stance that the solution requires suboptimal code; prevents inclusion of modular code that other users may like, there is a reasonable alternative (vga16), and in his considered judgement fulfillment of the wishlist is bad. When the maintainer does not give much on the user's wishes if they do not match their own's, I will fight against this rule (*). I showed that vga16 is an excuse and not a replacement. (*): A fresh case, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=121335repeatmerged=yes Prety easy to fix in the kernel and it would work for any program. But how refuses to accept this simple fix, because of the same only-my-upstream-code-as-modules-is-perfect-dogma? The ctte has no grounds to override the maintainer based on mere guesswork, since they can't in honesty claim to have better guesses than the maintainer. Reminds me on the Ivanova's God speech, but those days it was funny(**). Gruss/Regards, Eduard. PS: (**) On your way back I'd like you to memorize the Babylon 5 mantra. Ivanova is always right. I will listen to Ivanova. I will not ignore Ivanova's recommendations. Ivanova is god. And, if this ever happens again, Ivanova will personally rip your lungs out. Babylon control out.
Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
#include hallo.h * Herbert Xu [Fri, Oct 25 2002, 10:00:20PM]: Firstly I argue that VESA FB is only needed by a very small proportion of our i386 users. This stems from the fact that the great majority of I strongly object to this attitude. Shall we start argumenting for What attitude? The sentence you quoted is just a premise for the conclusion below. Exactly, you argument with minority not knowing the numbers. Well the laptop users that you know seem to be rather different from those that I know. The people who I know either use X or are quite happy with text in vga16. VGA16 as replacement is a joke - and you know this. It's quite useable for laptops in text mode at least. Useable - sure, but how? Sticked to 640x480, too large font, a nightmare for console user. And it is not sharpen on LCD monitors while you can set a vesafb resolution that you need. it as a matter of principle. There is a number of other device drivers in the kernel which have not be modularised. They're similar to VESA FB Examples please. Good examples. arpd, sch_atm, lp_console, nfs_root, ... As said, _good_ examples. How many users need that features? Note, am talking about masses of home and soho systems, not terminal servers. You have already began to do so with much larger pieces of code, ie. quota support. Remember, we are talking about support for a hardware Well It's my job as the maintainer to make such decisions. I have decided that quota is of general interest and irreplaceble while vesafb is not. I do not know any single user that uses quota on the personal box, only few servers. Who exactly needs this flexibility? Your kernel packages are for _users_. The flexibility to modularise fbcon. You may wish to use an alternative implementation for instance. As said, WHO needs it? As said, it is said to be not trivial. I certainly see no obvious stumbling block. Unfortunately I have so many things to do and the fact that you keep bitching certainly isn't a great motivating factor. Sure. But I am not the first and not the last person bitching about your bullheaded decisions. EOD. Gruss/Regards, Eduard. -- weasel for i in *; do if ( cat $i | grep -q hallo ); then echo $i; fi; done [einen Tag später] -:- Topic (#debian.de): changed by _shorty_: Award fuer useless use of cat an Weasel verliehen. :)
