[lkml]   [2002]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: How to check the kernel compile options ?
    On Thu, Feb 07, 2002 at 08:19:36PM +0100, Daniel Phillips wrote:
    > On February 7, 2002 07:26 pm, Mike Touloumtzis wrote:
    > >
    > > I installed a custom rsync just the other day, and I did it by downloading
    > > the Debian rsync source, patching it, and building a Debian package.
    > > I would certainly do the same for cat if I needed to.
    > >
    > > Sorry, I still don't see any fundamental difference.
    > Yes, and would you configure cat? Which options would you select?
    > I'm trying to avoid just saying 'you're being silly', but it's what I
    > really mean.

    I'm talking about rsync now, not cat (that was reductio ad absurdum to
    make a point). In case you haven't compiled any userspace programs in
    a while: many of them have configuration options. In the case of rsync,
    things like "--enable-profile" and "--disable-ipv6".

    I fail to see how tracking a custom compiled rsync is any different
    from tracking a custom compiled kernel. In both cases you have local
    history to track and a group of files to bundle together.

    Let's replay this discussion as I see it:

    You: Users are clamoring for the inclusion of configuration information
    in the kernel. They clearly need it, so let's include it even
    though it has no functional purpose.

    Me: Actually, I'm a user and the distribution-provided packaging tools
    work fine for this purpose. We don't bundle similar information
    into the binaries of userspace tools.

    You: Userspace tools don't have configuration options like the kernel.

    Me: Yes they do.

    Arguing that people don't custom configure anything but the kernel is
    a dead end. Also, I have already claimed that I don't need any of the
    "stuffing config info into kernels" solutions mentioned on this thread,
    so it's hard to try to convince me I need this feature.

    Some possible available avenues of argument for you are:

    -- "You don't know what you're missing".

    You can argue that moving configuration info into the kernel is
    fundamentally better than, or makes things easier than, bundling
    it into a package. This is a hard sell, since in an earlier mail
    I demonstrated that I can get at the configuration info in a kernel
    package with two commands.

    -- "You are not a typical user".

    Since I'm satisfied with the status quo, your best defense of this
    change is to argue that I am not the target audience for this change.

    As far as I can tell, the userbase of Linux, includes, in descending
    order of frequency:

    1) People who use prepackaged distribution kernels.
    2) People who build their own kernels based on distribution packaging
    systems, or have evolved their own systems of kernel management
    over the years.
    3) People who sling kernels around like loose change and forget where
    each kernel came from.

    AFAICT most of the "config info needs to go in the kernel" arguments
    seem to come from camp #3. I think those people should just get
    their acts together or start using the right tools instead.

    When I first started using Unix (on a multiuser system, back in
    school), I was struck by how messy it was. The root directories
    contained all kinds of locally added directories and forgotten crap.
    The systems were a mishmash of forgotten compiled-from-source packages,
    temporary workarounds, expedient measures, and haphazardly patcheded

    The extent to which the distributors and other measures like the FHS
    have rationalized this situation, and automated the tasks it sprung
    from, continues to amaze me. My sneaking suspicion is that people
    who want to stuff configuration info into the kernel haven't made that
    leap yet. That's why I'm being a bit of a harsh critic of the concept
    (plus, it seems to be par for the course on lkml :-).

    A final argument for using packaging/bundling tools and userspace files
    instead of files in /proc for tracking kernel metadata:

    -- Kernels are no longer single files, at least for most people.
    A _harder_ problem than this one is tracking which modules go with
    which kernel. Solving this problem solves the configuration tracking
    problem as a _side_effect_. Conversely, solving the configuration
    tracking problem without solving the module tracking problem is
    largely useless.

    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: 2005-03-22 13:24    [W:0.026 / U:2.884 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site