Return to BSD News archive
Newsgroups: comp.os.386bsd.misc
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!gatech!news.byu.edu!cwis.isu.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: QIC NEWS Vol.1 no.5
Message-ID: <1993Apr27.181636.18809@fcom.cc.utah.edu>
Keywords: QIC FDC
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <jmonroyC5zE4L.2Ms@netcom.com>
Date: Tue, 27 Apr 93 18:16:36 GMT
Lines: 59
In article <jmonroyC5zE4L.2Ms@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes:
> <3>__ Advance Proposal.
>
> Coordination between all groups on shared libraries
> is the first of the proposals suggested. This extends not
> only to 386bsd, Linux & MACH386, but also Coherent, Minix
> & OS/2.
Certainly what you meant to say must have been "common libraries"?
> Another good possible point to share is a fdc_base_code
> set. As you may or may not be aware, the QIC uses the FDC
> (Floppy Disk Controller), so it would be advantageous as a set.
The original expectation you put forth was for floppy driver code; QIC-40/80
was a followon. I hope you are not only now considering distribution of new
FDC code as part of you QIC-40/80 project.
> Of course, we know about objects and know that they are
> nice. Plans should be made for objects as well as in-line
> assembly, and any other appropriate software devices that qualify.
I object strongly to the use of inline assembly in all but development tools
(like the compiler) which are already firmly tied to the processor. I am
aware of porting projects to EISA based R400 and DEC Alpha platforms for
386BSD; I suspect similar projects in the Linux community. Both of these
architectures require a divorce of BUS I/O and processor architecture. You
should "practice what you preach" with regard to "good design". If you
feel optimization is necessary, optimize the C source code based on what
you know the compiler will output as assembly instead of directly coding
the assembly. That way it will be "optimal" for your target (386/486) but
not fail to work in other environments.
> platform: AT/ISA/EISA (MCA for OS/2 that need it)
> OS: 386bsd, Linux, Mach386, OS/2 (for the immediate)
> Language(s): C, C++, ASM (gas,masm)
>
> Files Break Up:
[ ... ]
I also object to the per-OS stratification of files; this is not portable
programming. At worst, the stratification should still take place, but
should be hidden from the user in a GNU-style "config" utility (an obvious
worst case if there ever was one). At best, you should divorce both the
hardware and OS specific code from the main (presumably portable) code in
one or two small conditionally compiled files (look at the "imake" sources
to see a passable example of how this is done).
Terry Lambert
terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------