lkml.org 
[lkml]   [2001]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Cleanup kbuild for aic7xxx
    Keith Owens wrote:
    >
    > On Fri, 22 Jun 2001 13:39:45 -0600,
    > "Justin T. Gibbs" <gibbs@scsiguy.com> wrote:
    > >>The existing build process for aic7xxx on Linux has several problems.
    > >>
    > >>* Users have to manually select "rebuild firmware". Relying on users
    > >> to perform any action other than make *config is unacceptable. It is
    > >> far too error prone.
    > >
    > >Users don't have to manually select "rebuild firmware". They can
    > >rely on the generated files already in the aic7xxx directory. This
    > >is why the option defaults to off.

    For the SGI patched kernels based on either 2.4.5 or 2.4.6-pre1, I have
    had to manually select this for a 7892 controller. Without manually
    selecting it, it guarantees boot failure. I don't know if this is due to
    the SGI modifications or not. The real problem I found is that during
    boot failure, there was no meaningful debug message.

    >
    > You rely on a timestamp check to tell the users "suggest you rebuild
    > firmware". That timestamp check is inherently unreliable when files
    > are both generated and shipped.
    >
    > >>* Rebuilding the firmware requires lex, yacc and libdb. Not everybody
    > >> has these installed.
    > >
    > >Then they shouldn't check the box "rebuild firmware".
    >
    > See above. Users think they need to turn on the firmware build, then
    > complain when it breaks.
    >
    > >>* The check for which libdb to use assumes that the presence of a db.h
    > >> is enough, but the overlap between glibc-devel and dbx-devel packages
    > >> means that finding a db.h is not enough, you have to confirm that the
    > >> corresponding libdb exists.
    > >
    > >Such is Linux. Those who understand what it means to rebuild the
    > >firmware will have the necessary tools, check the box in config,
    > >and have it work.

    But there is insufficient menu dialog associated with rebuild firmware.

    >
    > Wrong. Such is the way it _used_ to be. As the use of Linux expands,
    > more and more people are building their own kernels without knowing all
    > the internals. This is good, we get more users. But kernel build code
    > can no longer assume that anybody building a kernel is automatically an
    > expert.
    >
    > >>* It checks if the firmware is up to date by comparing the timestamps
    > >> on aic7xxx_seq.h and aic7xxx_reg.h against aic7xxx.seq and
    > >> aic7xxx.reg. Alas, when a patch hits those files there is no
    > >> guarantee which order the files are listed in the patch so the final
    > >> timestamp order is unreliable. diff lists files in alphabetical
    > >> order but other source repository systems can generate patches in any
    > >> order. This is a problem for all generated files, not just aic7xxx.
    > >
    > >So you might get a harmless warning if you haven't checked the box. This
    > >is not fatal and I have yet to hear one complaint about it.

    Missing firmware rebuild is fatal for my system, SMP x86 with integrated
    7892. Messages and config menu information is inadequate, it requires a
    bit of pounding the head on the wall to figure it out.

    >
    > http://marc.theaimsgroup.com/?l=linux-kernel&m=99124017310488&w=2
    > was fatal, you even replied to it.
    >
    > >>* Shipping files which are also overwritten by users causes problems
    > >> for source control systems and can cause spurious differences when
    > >> generating patches. This is a problem for all generated files, not
    > >> just aic7xxx.
    > >
    > >Those using revision control should know how to use revision control.
    > >The driver is developed under revision control and the current setup
    > >causes me no grief. Of course, I don't keep the generated files in
    > >revision control because there is no benefit in doing so.
    >
    > Users take patches from Linus or Alan Cox which include the generated
    > patches and add the patches to local source repositories. That
    > includes the generated files. If it comes from Linus or AC it is a
    > "master" copy. End users do not have the luxury of excluding the
    > generated files from revision control because it is not their input.
    > And if they do exclude the files then their users are forced to
    > generate the firmware. Excluding the aic7xxx generated files from
    > source revision works for you because you always generate the firmware,
    > it does not work for anybody else.
    >
    > >For those
    > >that decide to keep the generated files in revision control, they
    > >should pull any update to the generated files from the vendor (they
    > >are always provided in my patches) and *never check the box*.
    >
    > Users must not be forced to go hunting for files from a vendor when the
    > rst of the code is in the kernel. Especially when that vendor is not
    > listed in MAINTAINERS and there is no contact data in the aic7xxx
    > directory.
    >
    > >>The patch below fixes all of the above issues. It does not touch the
    > >>aic7xxx code nor sequencer input, just the generated files and the
    > >>kbuild related files. The patch is approx 100Kb but most of it is the
    > >>rename of aic7xxx_{seq,reg}.h to aic7xxx_{seq,reg}.h_shipped.
    > >
    > >I don't see this as an improvement.
    >
    > I do, and I am the kernel build maintainer. I don't tell you how to
    > code aic7xxx drivers, but I can and will fix kbuild problems. The
    > current aic7xxx kbuild is a problem.
    >
    > >>After applying this patch, normal users will not have to worry about
    > >>generating aic7xxx firmware.
    > >
    > >This is already true today.
    >
    > Not true, the timestamp check produces spurious prompts.
    >
    > >>In particular they will not have to
    > >>select "rebuild firmware" nor will they need lex, yacc or libdb.
    > >
    > >Already true today.
    >
    > Wrong. See
    > http://marc.theaimsgroup.com/?l=linux-kernel&m=99323170127833&w=2
    >
    > >>Only people who change one of these files
    > >
    > >Today, this only applies to those that *check the rebuild firmware*
    > >box.
    >
    > Which the broken timestamp check encourages people to do.
    >
    > >What again are you trying to fix? It looks to me like you are simply
    > >trying to make it harder for people actually working on the aic7xxx
    > >driver to have proper dependencies.
    >
    > The patch still works for anybody changing the aic7xxx firmware or the
    > aicasm code. Any change to the generated files or the aicasm files now
    > forces a rebuild, the option is not required. Only people changing
    > aic7xxx firmware are affected, instead of everybody.
    >
    > Bottom line: the current method relies on unreliable timestamps,
    > produces spurious warning messages and causes problems for everybody
    > using source control except for you. The new method is clean. And as
    > kbuild maintainer, that is the way I want it to be done.
    >
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:55    [W:5.857 / U:0.864 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site