[lkml]   [2008]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Additional kconfig targets (cloneconfig, nonint_oldconfig etc)
    On Tue, 29 Apr 2008 20:35:31 +0200
    Sam Ravnborg <> wrote:

    > Recently there has been request for a number of new
    > kconfig related targets.
    > In general it boils down to the following:
    > We need to be flexible in what configuration
    > we start out from and how we apply it.
    > We need to be able to apply it in following ways:
    > 1) automated - select defaults for all new symbols
    > => It is used for "make defconfig, make *_defconfig" today
    > 2) interactive - asking user for all new symbols
    > and error out if stdin is redirected
    > 3) list unknown - list all new symbols and do not
    > create a new config
    > With oldconfig today we have two modes:
    > -> One mode where we are very chatty and show
    > all output.
    > -> And the 'silent' mode where we only start being
    > chatty when we see a new symbol.
    > I plan to drop the 'very chatty' mode as I
    > do not see it usefull.

    I'd certainly agree with that.

    > So in essense 'make oldconfig' and 'make silentoldconfig'
    > become equal.
    > The commands we have today for kconfig is:
    > # Command line variants
    > make oldconfig
    > make silentoldconfig
    > make defconfig
    > make XXX_defconfig
    > (The other frontends are left out on purpose).
    > The challenge here is to come up with a syntax that
    > allows us to select between the three behaviours,
    > while keeping backward compatibility.
    > The best suggestion I have so far is to say that:
    > a) if defconfig is specified then we use method 1)
    > b) if oldconfig is specified then we use method 2)
    > c) if newconfig is specified then we use method 3)

    'newconfig' sounds to me like you're creating a new config; the exact
    opposite of what it does. I'd suggest 'listnewconfig' or some such thing.
    Then again, 'defconfig' and 'oldconfig' are primarily what I care about,
    as I haven't been in a situation where I would have found method 3) to
    be useful.

    > And we add support for a new 'commandline' parameter
    > 'K' so I can say:
    > make K=/proc/config.gz defconfig
    > make K=i386_defconfig defconfig
    > make K=i386_defconfig oldconfig
    > make K=/proc/config.gz newconfig
    > So K is used to specify what config file we use
    > to start out from.

    Sounds good, I highly prefer specifying the config via env variable
    rather than embedded in the target (ie, 'make olpc_defconfig').

    > Care should be taken to keep the known good
    > targets working as before.
    > Andres Salomon already did some preparational work
    > for this but I need to find a good way to handle the K=
    > parameter.
    > Dave J also posted patches that is useful for 'newconfig'.
    > But I wanted to ask for opinions before diving into
    > implmenting this.
    > Sam
    > [Random notes..]
    > # Enviroment variables affecting kconfig
    > #input files (aparts from the mandatory ones)
    > all.config
    > allno.config
    > allmod.config
    > allyes.config
    > allrandom.config

     \ /
      Last update: 2008-04-29 23:23    [W:0.024 / U:0.276 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site