[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]



Manoj Srivastava writes ("Re: [herbert@gondor.apana.org.au: Re: Bug#161931:  kernel-image-2.4.19-k7: VESA driver for console]"):
> 	I am not sure the latter follows. Certainly, there is a (small)
>  vocal set of users, but popularity is still in question.

Well, certainly it's not decisive, but we're unlikely to get better
information.  We're going to have to decide on the basis of the
information we have available, I think.

>  >> 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.

This argument seems aesthetic, possibly even emotional, to me.  Is
there actually any _problem_ with the non-modular code ?

(I should say that personally, I find kernel modules a mixed blessing,
and on my own systems often avoid them because of their extra
complexity.  That's not to say that they're not useful in distribution
kernels, of course, but I think I should warn you about my prejudices ...)

>  >>    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.

Guesswork.  No-one in this argument has any concrete data.

>  >>    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).

Do business users often turn on quotas on desktop machines ?  I'd be
surprised.  For servers, of course, most people will (or should!)
build their own kernels.

Ian.



Reply to: