[lkml]   [2006]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Driver model.. expel legacy drivers?
    Hash: SHA1

    Adrian Bunk wrote:
    > On Fri, Oct 13, 2006 at 11:18:35PM -0400, John Richard Moser wrote:
    >> Here's a silly thought I had a while ago. Linux has no static ABI for
    >> device drivers, I think the general argument was between "it's slower"
    >> and "different hardware will have different requirements." Putting
    >> aside design difficulties, I've come up with an example case of a useful
    >> hardware driver ABI.
    >> As kernel development goes on, some infrastructure changes require
    >> drivers to be updated. Eventually some drivers become buggy and
    >> ill-maintained, even when they used to be legitimately working ones; and
    >> then developers have to take some of their time to fix them, or eject
    >> them from the tree.
    > The rule is simple:
    > If you break an in-kernel API, you have to fix all in-kernel users.
    > No matter how ill-maintained a driver is, that works quite good.

    Nods. I hope that keeps working then.

    >> ...
    >> This brings up a few potential questions:
    >> - Will this eventually be necessary to an absolute? Will 100M
    >> tarballs and hundreds of thousands of drivers be unmanageable in a
    >> tight, ABI-unstable monolith 10 years from now?
    > "hundreds of thousands of drivers" won't happen during my lifetime.
    > If the kernel size only doubles to 100 MB that's no problem.

    The below is purely informative. I would like to wait until around
    2.6.30 and redo the math, because I am not certain of the growth. I
    believe it would be statistically more sound to have a wider sample base
    to calculate the regression from, especially with the wide variance in
    growth between kernel versions.

    I've mapped the growth of the .tar.bz2 archives in kilobytes since
    2.6.0, they show an erratic pattern but a strong overall linear growth
    pattern. This means the actual size of the kernel is polynomial and
    integrates crudely to:


    For x == minor (i.e. 2.6.0 == 0; 2.6.18 == 18). This produces a level
    of error; however, I've graphed the error and it seems to be off by no
    more than 400k ever and show a horizontal trend (i.e. overall accurate);
    however I'll have to apply the same prediction to future kernel versions
    to get a good picture.

    The point is that compressed kernel source tree size is growing on the
    order of a second degree polynomial. I have not done measurements on
    the uncompressed tree size because I'd have to download and decompress
    every version; but I imagine it correlates, due to the nature of

    My math predicts that 2.6.57 (+39) will be 100M (in approximately 7
    years if you assume 1 kernel release every 2 months); 2.6.92 (+35) will
    breech 200M; 2.6.117 (+25) will breech 300M; and 2.6.138 (+21)) will
    breech 400M. That should suffice for predictions over the next 20 years
    based on this crude model.

    I would like to wait for more data and perform a better analysis in 2
    years; although I would be interested now in finding a way to get the
    full kernel source tree size in bytes without actually downloading and
    unpacking all the tarballs. Is there a list somewhere I can use?

    >> - Would it ACTUALLY be worthwhile, given such a scenario, to expel
    >> drivers out of the tree to glue on by a static, somewhat slower but
    >> workable ABI so nobody has to touch the code ever?
    > Documentation/stable_api_nonsense.txt describes why this is nonsense.
    > And if you anyway don't want to change the kernel API, it doesn't make
    > any difference for you whether the drives are shipped with the kernel.
    > And external drivers with various interdependencies and dependencies
    > would be an insane maintenance nightmare.

    This is probably true.
    >> - Is there actually a benefit -now- to ejecting drivers from the tree,
    >> or are the developers pretty much comfortable polishing the stuff
    >> nobody normally touches here and there?
    > The goal is to get drivers into the kernel and shipping a complete
    > kernel with all drivers.
    >> Just curious.
    > This point comes up every few months on this list, so instead of
    > starting the same old disussion on this topic please read the old
    > discussions in the list archives.
    > cu
    > Adrian

    - --
    We will enslave their women, eat their children and rape their
    -- Bosc, Evil alien overlord from the fifth dimension
    Version: GnuPG v1.4.3 (GNU/Linux)
    Comment: Using GnuPG with Mozilla -

    -----END PGP SIGNATURE-----
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-10-14 17:07    [W:0.028 / U:12.164 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site