[lkml]   [2007]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject"obsolete" versus "deprecated", and a new config option?

    a couple random thoughts on the notion of obsolescence and

    first, there are places in the kernel (primarily Kconfig files) and
    the documentation that unnecessarily conflate these two properties.
    as a simple example, consider drivers/pcmcia/Kconfig:
    config PCMCIA_IOCTL
    bool "PCMCIA control ioctl (obsolete)"
    depends on PCMCIA
    default y
    If you say Y here, the deprecated ioctl interface to the PCMCIA
    subsystem will be built. It is needed by cardmgr and cardctl
    (pcmcia-cs) to function properly.

    You should use the new pcmciautils package instead (see
    <file:Documentation/Changes> for location and details).

    If unsure, say Y.

    so is that ioctl obsolete or deprecated? those aren't the same
    things, a good distinction being drawn here by someone discussing

    "Devfs is deprecated. This means it's still available but you should
    consider moving to other options when available. Obsolete means it
    shouldn't be used. Some 2.6 docs have confused these two terms WRT

    yes, and that confusion continues to this day, when a single feature
    is described as both deprecated and obsolete. not good. (also, i'm
    guessing that anything that's "obsolete" might deserve a default of
    "n" rather than "y", but that's just me. :-)

    in any event, what about introducing a new config variable,
    OBSOLETE, under "Code maturity level options"? this would seem to be
    a quick and dirty way to prune anything that is *supposed* to be
    obsolete from the build, to make sure you're not picking up dead code
    by accident.

    i think it would be useful to be able to make that kind of
    distinction since, as the devfs writer pointed out above, the point of
    labelling something "obsolete" is not to *discourage* someone from
    using a feature, it's to imply that they *shouldn't* be using that
    feature. period. which suggests there should be an easy, one-step
    way to enforce that absolutely in a build.



    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: 2007-01-17 18:51    [W:0.023 / U:94.460 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site