Re: Coding style - a non-issue

[Gérard Roudier]

Hi Keith,

When I have had to prepare a Makefile for sym-2 as a sub-directory of
drivers/scsi (sym53c8xx_2), it didn't seem to me that a non-ugly way to do
so was possible. I mean that using sub-directory for scsi drivers wasn't
expected by the normal kernel build procedure. Looking into some network
parts that wanted to do so, I only discovered hacky stuff. This left me in
the situation I had to do this in an ugly way.

As you cannot ignore the scsi driver directory is a mess since years due
to too many sources files in an single directory. Will such ugly-ness be
cleaned up in linux-2.5?

By the way, in my opinion, a software that is as ugly as you describe but
not more looks excellentware to me. :-)

  Gérard.

On Sat, 1 Dec 2001, Keith Owens wrote:

> On 30 Nov 2001 18:15:28 +0100,
> Henning Schmiedehausen <[e-mail]> wrote:
> >Are you willing to judge "ugliness" of kernel drivers? What is ugly?
> >... Is the aic7xxx driver ugly because it needs libdb ? ...
>
> Yes, and no, mainly yes.  Requiring libdb, lex and yacc to to generate
> the firmware is not ugly, user space programs can use any tools that
> the developer needs.  I have no opinion either way about the driver
> code, from what I can tell aic7xxx is a decent SCSI driver, once it is
> built.
>
> What is ugly in aic7xxx is :-
>
> * Kludging BSD makefile style into aix7ccc/aicasm/Makefile.  It is not
>   compatible with the linux kernel makefile style.
>
> * Using a manual flag (CONFIG_AIC7XXX_BUILD_FIRMWARE) instead of
>   automatically detecting when the firmware needs to be rebuilt.  Users
>   who set that flag by mistake but do not have libdb, lex and yacc
>   cannot compile a kernel.
>
> * Not checking that the db.h file it picked will actually compile and
>   link.
>
> * Butchering the modules_install rule to add a special case for aic7xxx
>   instead of using the same method that every other module uses.
>
> * Including endian.h in the aic7xxx driver, but endian.h is a user
>   space include.  Code that is linked into the kernel or a module
>   MUST NOT include user space headers.
>
> * Not correctly defining the dependencies between generated headers and
>   the code that includes those headers.  Generated headers require
>   explicit dependencies, the only reason it works is because aic7xxx ...
>
> * Ships generated files and overwrites them under the same name.
>   Shipping generated files is bad enough but is sometime necessary when
>   the end user might not have the tools to build the files (libdb, lex,
>   yacc).  Overwriting the shipped files under the same name is asking
>   for problem with source repositories and generating spurious diffs.
>
> All of the above problems are caused by a developer who insists on
> doing his own makefile style instead of following the kernel standards
> for makefiles.  Developers with their own standards are BAD!
>
> BTW, I have made repeated offers to rewrite the aic7xx makefiles for
> 2.4 but the aic7xxx maintainer refuses to do so.  I _will_ rewrite them
> in 2.5, as part of the kernel build 2.5 redesign.
>
> Keith Owens, kernel build maintainer.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/