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:
> >> * 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.
On Fri, Oct 25, 2002 at 02:23:47PM -0500, Manoj Srivastava wrote:
> I am not sure the latter follows. Certainly, there is a (small)
> vocal set of users, but popularity is still in question.
Without a way of measuring how much popular support VESA FB would get
from non-vocal users (and from users who have given up because of the
lack of vesa support) I don't see this as a meaningful distinction.
> >> 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.
I understood him to mean that (with the exception of nfs_root), these
options are not likely to be relevant in a low-end context.
[In contrast, people who would need something like arpd, or sch_atm
would have no lack of resources to rebuild the kernel.]
> >> * 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.
This is an argument for the kernel architects. We're not kernel
architects, however -- we're distributors.
The kernel architects, for whatever reason, have decreed that if you
want both vesafb and fbcon in a current version of Linux, you have to
have them both compiled in statically.
Our choice is: do we want to distribute this or not?
--
Raul
Reply to: