Dear Alan, dear linux kernel hackers,
On Fri, Jan 21, 2000 at 11:16:38PM +0000, Alan Cox wrote:
>> * people may want to extract parts of the kernel to reuse them in
>> other environments, with other compilers
>
> Its very hard to do so. The only people who did it were the Linux 8086 folks.
Sure. But why make their life gratuitously harder?
Something that made things particularly hard for the 8086 folks was
that squeezing the 32-bit-designed Linux onto a 16-bit architecture.
Other people mighn't have this problem. And even if the task of porting
the whole kernel to another compiler is daunting, they may want to do it
only a subsystem or another.
Again, I can imagine people trying to compile Linux on other architectures
with, say, the DEC/OSF1 Alpha compiler, or some custom CPU-specific compiler
for their architecture du-jour, or with lcc (because they're FSF-phobic), or
with some generic C analysis tool (to prove things about the code;
to benchmark their research optimizer).
> We can address that when it occurs, in fact they can address it. Writing
> poorer systems now just "in case" is a bad choice. Its one of the big
> differences between "software engineering" and how free software evolves.
>
> Software engineering generates complex and very complete reusable objects.
> Free software generates simple, incomplete objects that do what is actually
> currently needed and can be extended later
In the particular case that raised the debate, I don't consider my patch
as overly complex or poor; it's even a clean-up, considering that there
was already a __constant_htonl, anyway. It doesn't cost anything (well, ok,
12 macros by endianness; but not gratuitous macros, either). It's local.
It's backwards-compatible. And it's future-safe, should anyone choose
to make code compatible with a non-GNU C compiler (or maybe even GCC
without optimization?) by prepending __constant_ here and there.
Requiring future modifiers to invent and implement their own incompatible
interface tomorrow when we have a good patch today isn't future-proof,
and leads to gratuitous source forking. As the kernel's "byteorder janitor",
I can but recommend the patch. At least, if you refuse it I'd much appreciate
an explanation as to why you consider it poor, and if so, why you
keep __constant_htonl around (I'd be equally satisfied if you decide to
commit to incompatibility to non-GNU C compilers, and drop the then
unnecessary work-arounds).
In the general case, I agree that writing poor code just in case is a very
bad idea, and that methodologies that lead to such things are plain Wrong.
Now, I consider that software engineering is complementary to free software,
not opposite to it. Certainly, in the setting of proprietary software, S.E.
has had to go at great lengths of big-time kludges so as to allow any dynamic
behavior or fixup despite lack of sources and binary-level
backwards-compatibility. But the culprit is conspicuously NOT software
engineering; it's proprietary software. If anything, S.E. made the software
possible at all, despite the proprietary limitations. Of course, the
development of S.E. was horribly distorted and corrupted by proprietary
software; an inextricable mass of useless and even harmful crud grew
within S.E. (like the OO hype, and many many "development methods", CORBA,
and stuff; not even the UNIX design went uncorrupted by proprietary
considerations); at the same time, whole branches of S.E. were neglected
(in case anyone cares, I've written about all that in an article available
at URL given below). But don't kill the baby with the illness.
The horrible bacteria is now regressing, and software engineering is on
the way to recovery. Let the science grow freely now.
PS: the article I talked about is
Metaprogramming and Free Availability of Sources
http://fare.tunes.org/articles/ll99/index.en.html
Best regards,
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
The more one knows, the more one knows that one knows not. Science extends
the field of our (meta)ignorance even more than the field of our knowledge.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:26 EST