Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
>>">>" == Ian Jackson <ian@davenant.greenend.org.uk> writes:
>> So let me see if I can summarise what the pros and cons are, that have
>> been mentioned so far:
>> Pro:
>> * Some laptop users and certain others who wish to use the console
>> in better video modes have an easier life, as they can do so with
>> the stock Debian kernel. How many people would benefit seems to be
>> disputed, but it does seem clear from the BTS logs that the VESA fb
>> is popular.
I am not sure the latter follows. Certainly, there is a (small)
vocal set of users, but popularity is still in question.
>> Con:
>> * A small increase in kernel size. This has not been quantified.
>> Allegedly, including all drivers which are in roughly the same
>> situation as VESA fb would increase the kernel size significantly.
Lack of modularity in the kernel is a bad idea, and unless
there is overwhelming need for it, I would much rather not taint the
kernel with non modular code; in this I agree with Herbert.
>> Do we have a list of other examples ? Herbert suggests
>> arpd, sch_atm, lp_console, nfs_root
>> I think it's clear that most of those are not really in the same
>> position as VESA fb, because they are much more of a minority
>> interest.
What is the dataset you are basing this assumption on? I am
not sure that they are in a different category at all.
>> nfs_root may be a good example (but there the boot disk
>> argument Herbert's making is weakened, because there are good
>> reasons why nfs_root might be useful on a rescue disk).
We have not needed it yet in the installation, and I don't see
any move in the debian installer mailing list to build in nfs_root
(doesn't nfs root help export file systems), so this is a red
herring.
>> The inclusion of quota support in the default kernel seems to make
>> this a difficult argument to sustain, if the quota support is
>> significantly bigger than VESA fb as Eduard Bloch maintains.
No, unless you can prove that quota system popularity is as
low as VESA popularity (looking at business use of Linux, that would
be a hard argument to sustain).
>> * Herbert says that there is another driver, fbcon, which cannot be
>> distributed in modularised form if VESA fb is included statically .
>> But the argument for needing to distribute fbcon as a module - that
>> it can be recompiled more easily - seems very weak to me.
I guess I differ with this assesment. I find that bad, non
modular code precluding modularity in the kernel as a strong argument
for keeping the non-modular code out.
>> Issues that seem irrelevant to me:
>> * I don't care whether it's easy to modularise VESA fb or not. If
>> it's modularised then the dispute goes away, but at the moment it
>> is not modularised and we cannot mandate that that work be done.
>> We can only decide whether the non-modular version should be
>> included.
>> Issues that seem to have been dealt with:
>> * Older non-VESA-fb kernels would present the user with a black
>> screen if a previous VESA-fb-using configuration was used. This
>> bug has now been fixed.
>> * There was a question as to whether VESA fb breaks some machines,
>> even when it is not used. It seems that no-one is arguing this any
>> more. If there is some evidence to the contrary, it would be good
>> to know.
manoj
--
"Let's show this prehistoric bitch how we do things downtown!" The
Ghostbusters
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: