Re: [tlug] Is having no "iptables" bad?

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Dave" == Dave M G <Dave> writes:

    Dave> Also, I'm thinking that I'm likely to come across a few more
    Dave> issues like this over the next couple of weeks. So I figured
    Dave> my plan would be to add the modules the same way I did with
    Dave> the IVTV modules as they come up. Then when it seems like
    Dave> I'm not finding any more modules I need to add, I'll rebuild
    Dave> the kernel with the .config file that should, by then,
    Dave> include all the modules that I'm needing.

    Dave> Is there anything obviously wrong with that plan?

No.  Appearances to the contrary (I've read the next five or so
messages in the thread, but don't see anything there to reply to),
everybody is in agreement that that is the right plan.

General information about kernel configuration:

- The kernel configuration mechanism does have a simple notion of
  dependency.  Unless you deliberately override the configs that the
  script recommends, you will rarely find yourself with a module that
  needs other modules that you didn't know about.  Of course it
  doesn't know about your hardware, but if you choose the driver that
  runs your hardware, that will normally pull in all the "bus drivers"
  "above" it in the hierarchy.

- The configuration mechanism has a primitive but useful help
  facility.  It will generally tell you "if you don't understand the
  help, say 'yes'" (or 'no', depending on option).  "Yes" is an
  abbreviation for "'y' or 'm'" if the option can be buit as a module.
  Sometimes the default will be different from recommended; my guess
  is that the defaults are generally more up to date.  When in doubt,
  ask.

- The most important thing is to choose the .config that's closest to
  where you want to be.  Based on Godwin's information about the
  change in the process for configuring netfilter, I would recommend
  avoiding a .config for a kernel version < 2.6.17.  Either the
  .config in your own source directory for 2.6.17.7, or the one from
  Ubuntu's source package, with latter probably best (it will already
  include netfilter and iptables).

  I recommend that you not try to customize the configuration in
  Ubuntu's source tree and build there.  I had problems in the past
  doing that on Debian, and I don't see a real advantage to having all
  the Ubuntu infrastructure tweaks.  (.config determines what the
  built kernel is going to be; the difference between a distro source
  package and using make-kpkg is about *fully* automating transitions
  between kernels, but you've already decided to do part of it
  manually.)  Just copy the .config, and then rm -rf the Ubuntu source
  tree.  (Hint: If Ubuntu is like Debian, the source package actually
  consists of three files: the upstream tarball from kernel.org, a
  .diff.gz containing Ubuntu changes, and a control file with
  metadata.  The Ubuntu .config will be in the .diff.)

  NB: IIRC the kernel.org tarballs do not contain a .config at all, so
  any .configs on your system are presumably yours or Ubuntu's.

- Any distro's config is likely to contain a number of option settings
  that you don't want.  You may wish to customize the options for your
  CPU architecture (although most distros now offer a dozen different
  x86 options).  You may want to get rid of modules you definitely
  won't use (eg, a myriad of LAN drivers, ISDN, and possibly IPv6).
  There is a setting somewhere that control the speed of context
  switching, you might want to optimize that for your use case, etc.

Recommendation: spend the hour to 90 minutes it takes to go through
the whole hierarchy (you can omit hardware device drivers, etc---use
your common sense, which by now is sufficiently sensible, I think).
Besides being useful in finding options later, and learning about what
you can set, it will tell you a lot (by osmosis, even if it's not
conscious yet) about how Linus thinks about kernel architecture.  I do
this *every* time I go out to reconfigure my kernel, but that's
because it's fun in a perverse sort of way.  It doesn't really improve
the "feel" for the process, or even refresh detail much; doing it
once, *maybe* twice, is sufficient for that.  I think this is
worthwhile for you, because you like somewhat unusual peripherals, and
that means that you'll be running into driver issues every so often.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.