[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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?


Reply to: