Messages in this thread | | | Date | Sat, 22 Jan 2000 01:25:46 +0100 | From | Francois-Rene Rideau <> | Subject | Re: Constant byteorder macros. |
| |
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/
| |