Date: Tue, 26 Sep 1995 17:22:48 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, kelly@fsl.noaa.gov, gryphon@healer.com, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org Subject: Re: ports startup scripts Message-ID: <199509270022.RAA08773@phaeton.artisoft.com> In-Reply-To: <23960.812156218@time.cdrom.com> from "Jordan K. Hubbard" at Sep 26, 95 03:56:58 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > With respect, the porting time required is proportional to the portability > > of the code. The overhead is realtive to how clean the code base is in > > the first place. > > With equal respect, "porting" a product for any ISV of reasonable size > is a fair greater challenge than simply getting the software > "running." The product needs to be separately QA'd and tech support > needs to understand any issues particular to any given platform (and > believe me, even for the same product on multiple platforms the tech > support problem gets skewed by local configuration issues). The product is QA'd with the validation suite. 2 hours were required for the validation suite, which is interesting, considering POSIX validation takes less time to run. Part of this validation is dumping the manufacturer termcap, ttys, inittab, gettydefs, etc. to tape, as well as any diagnostic information that can be obtained programatically (if the validation suite can't tell a difference on the platform, then the product can't tell a difference on the platform). Noting tape devices, formats, etc. is done by the porting engineer during the validation suite run. The other issues are manufacturer packaged modem and serial cable pinouts, both of which can be had for purchasing (the typical approach). The modem to computer connection is set up with a breakout box between the manufacturer cable and the modem. The modem is only purchased in the case of non-support of the Hayes command set. The system "flavor" (generally SYSV vs. BSD) is the only unique thing required for the support engineer. All other documentation is equivalent. Error reports to the user are not duplicated for different errors and are prefixed with product support database keywords. Don't try to tell me Lotus didn't ship their own termcap. We did, too, but we made sure we worked with the manufacturer packaged hardware and termcap as well, and didn't install ours at all by default. The worst UNIX port we ever did is AIX, and that took 5 days. > If shipping on a new platform were like a calf roping contest where > you're allowed to throw your hands up in victory after the calf's feet > are well tangled, no matter now inelegant the knot, well then sure! :-) I agree that that's not a port. On the other hand, one can not call portable any code that relies on structure packing, byte order, bit fields, comma operators, dynamic scoping of stack variables, varradic functions, or preprocessor primitives like "#if" or "#elif" or the types "const", "void", or "__declspec()", or ANSI prototypes or agregate union initialization, etc. Using any function in manual sections other than (2) is frowned upon as well, unless it's stdio, and even then you have to be careful. The one exception might be directory walking utilities, and then only under BSD and SVR4 (BSD-like directory structures). If you are using any of these things and you expect to support more than a few UNIX platforms with little effort, then you are smoking something. Yes, it's a pain in the ass to set code like this up initially, but it's not as much as a pain in the ass as rewriting the world and calling that a "port" for each new machine. Code that has been rewritten for another platform has not been ported, it's another product. If you are maintaining seperate source trees for different platforms, then you are either crazy or masochistic or both. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509270022.RAA08773>