domo@seismo.UUCP@sphinx.co.uk (Dominic Dunlop) (07/01/87)
From: mcvax!sphinx.co.uk!domo@seismo.UUCP (Dominic Dunlop) Nice to see SAS on the net -- although your sales people play coy about if and when a UNIX implementation might see the light of day (no, I'm not asking you to comment...) In article <166@sas.UUCP> you write: >Is there any effort in the standards efforts to provide kernel (or CRT lib.) >support for this [dynamic loading/execution from data space]? No. To my knowledge it hasn't come up at all on POSIX (although I didn't attend last week's meeting in Seattle). Not least of the problems is that 1. The classic BSD implemenataion depends on a highly machine-dependent aspect of VAX memory management. 2. Quite a few people (and I'd probably number myself among them) consider this aspect of VAX memory management to be brain-damaged, or at least to be something which could be done better by throwing a few more gates at the problem (gates weren't so cheap or fast in 1978). 3. Later memory management implementations may well specifically exclude ``doing things the VAX way'' because it is judged to be unclean and/or unsafe. Certainly, many 68x00 implementations don't allow execution out of data space, and don't provide a kernel call which (in effect) allows programs to move the boundary between text and data. Consequently, any attempt to introduce the topic to POSIX would be controversial, and POSIX does not need controversy if a standard is to be ratified on schedule! To put it another way, this is a political issue... However, if you were to make a more or less formal proposal by mailing John Quarterman, moderator of comp.std.unix (std-unix@ut-sally) you could flag a valid technical issue as open, and might even get a formal reply from the working group. If you want to rope in somebody with heavy-duty experience of this issue, Catalytix Corp. of Cambridge MA (phone 617 429 2160 -- I don't have a net address) have had to fight it in bringing up their Safe-C interpreter in a variety of UN*X and other environments. (Safe-C is worth checking out if you're a developer, anyway.) The usual disclaimer: I don't speak for IEEE working group 1003.1 -- almost nobody can (in fact, the IEEE carries professional liability insurance just in case anybody wants to brief their lawyer to argue about it). These opinions are strictly my own. [ The quickest way to make a proposal to IEEE P1003.1 (the POSIX committee) is to mail a paper copy to Secretary, IEEE Standards Board Attention: P1003 Working Group 345 East 47th St. New York, NY 10017 Formal notes to the committee have to go there, anyway, or be carried to a Working Group meeting. Feel free to submit a copy to comp.std.unix if you want to. As decided at the Seattle meeting (22-26 June 1987), all proposed changes to the P1003.1 draft standard must be in the form of balloting objections, i.e., actual proposed wording for the standard with attached rationale is required. You can still send in general comments, though. Also, your note might get redirected to another subcommittee which is more directly addressing related issues. Offhand, I don't know which one that might be: perhaps one of the /usr/group Technical Committees. I play several roles related to POSIX, and they frequently get confused: a) Moderator of comp.std.unix. b) Institutional Representative from USENIX to IEEE P1003. c) Member of the USENIX Board of Directors. d) Private contractor for the P1003.1 Rationale, funded by /usr/group. a) is largely a result of b), and c) is useful in doing b). d) is completely unrelated to the other three, and is finished. I can and sometimes do submit notes to P1003 as the USENIX Institutional Representative (e.g., the tar vs. cpio note). It's one of my functions in that role to gather information from the USENIX membership and the public and also to distribute information about POSIX and other standards. So, I could submit a note for you. It will just get there faster if you do it yourself.... Dominic's disclaimer about speaking for IEEE or P1003 also applies to me, of course. -mod ] Dominic Dunlop, Sphinx Ltd. UKnet: domo@sphinx.co.uk Volume-Number: Volume 11, Nualtcyigh