Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!mcsun!ukc!cam-eng!tpm From: tpm@eng.cam.ac.uk (tim marsland) Newsgroups: comp.sys.hp Subject: Re: rpc registration and how to tell of a cnode death ? Summary: why amd is hard to rewrite Keywords: amd nfs NFS Message-ID: <9500@rasp.eng.cam.ac.uk> Date: 29 May 90 22:06:51 GMT References: <3300@umbc3.UMBC.EDU> <1720009@hpbbi4.HP.COM> Sender: tpm@eng.cam.ac.uk Reply-To: tpm@eng.cam.ac.uk (tim marsland) Organization: Cambridge University Engineering Department, UK Lines: 94 In article <1720009@hpbbi4.HP.COM> markl@hpbbi4.HP.COM (#Mark Lufkin) writes: >> What!!? Are you suggesting that Greg rewrites `amd' to use NCS?? > > I must admit I have no idea what 'amd' is or where it comes > from but the idea is not as stupid as you might think Well, speaking for myself, not knowing anything about a program generally stops me from posting replies to people's questions about it :-) > ... it does > not take long to convert a program (it has been done in house ... > could have something to do with the fact that we are pushing NCS > now though and having SUNrpc based applications does not look > good :-) Applications like NFS you mean? Or is that going now? This is one of the more serious undercurrents which underlies this discussion. > Being serious, the exercise is not as stupid as you would > like to imply. Also being serious, I concur that one can often rewrite programs to use different RPC paradigm's. However, I'm not exactly sure how useful gratuitous rewriting is in the context of the original query (summary: "How do I register amq?"). Note that `amd' is only(!) about 17000+ lines of cunning C that has been ported to at least ten different vendors Unix variants ;-) However, the main reason why I was so shocked by the suggestion (and shocked I was) is not the idea of rewriting per se, but more that `amd' is itself an NFS server i.e. it has to be based around SunRPC. Specifically, rewriting `amd' to use a different RPC paradigm would have meant rewriting the NFS code in the kernel of the local machine and of all the mount daemons of the file servers it was accessing, *as* *well* *as* amd itself. Quite a few man-months ``conversion'' work for poor Greg methinks :-) Perhaps now you understand why I tried to imply rewriting was stupid in this case, and the general ferocity of my flame? > The reasons why NCS was chosen over the Netwise/SUNrpc offering were: > There is a fuller description the following documents: > > Apollo NCA and SUN ONC: A Comparison (Nathaniel Mishkin) > > A Comparison of Commercial RPC Systems (Joshua Levy) > A response to the above by Nathaniel Mishkin > > I do not have any of these electrponically - if I find them I will > make them available - if anyone else has them, they could do the > same (the last two were in comp.misc some time back. and > Just as a summary of why OSF chose NCS over SUNrpc/Netwise offering: > ... This is more like it Mark -- thanks. I'd very much like to read these documents, and your summary of the factors that influenced the decision is much appreciated. >> >> Q-2) If your on a cluster server, is there a way you can tell when/how a cnode >> >> dies (loses contact with the server) ? This would seem to be so unusual of a >> >> request. >> >> > Diskless nodes don't core dump (unless >> > they have local swap) so you will not be able to get more information >> > on why the crash occurred. >> >> That's really neat. Any reason why? > > Easy ... the crash is put into swap, the swap is on the server which > we have just lost contact with ... That's not what I meant i.e. the crash might not be *caused* by a network error. For example, there might have been a bug in a pseudo-device I was trying to add to the kernel (say). Is it still the case that the client can't core dump when it panics for non-network-related problems? > I will admit to being biased in my opinions but then so is > everyone else (and the world would be a boring place if we weren't). Yes, but.. this is a technical forum, not a marketing forum :), so we've all got to try and keep our opinions under control wherever possible :-) > OK, that's enough from me. I will now shut for a while and try > not to offend anyone else (seems to be difficult these days). Hey, no problem Mark -- it's been fun. Just hope everyone else has enjoyed it. I'll shut up now too. tim marsland, information engineering division, cambridge university engineering dept.,