dlw@odi.com (Dan Weinreb) (06/23/89)
A few weeks ago, I believe someone mentioned that the new version of RTI's Ingres makes use of one of the System V IPC features (shared memory segment or semaphores; I'm not sure which, but it doesn't matter for purposes of this question). Now, in the standard Unix kernel distributed by Sun Microsystems, the System V IPC features are not assembled in; if you want them, you have to build a kernel that explicitly includes them. It seems to me that this might mean that in order to install RTI Ingres at a Sun customer site, the customer might need to build a new kernel. I realize that building a new kernel isn't difficult for someone who has any experience in these matters. But at some customer sites I'd expect there to be only a few local "wizards" who know about building kernels and who have permission to do so. In actual practice, would anyone expect this to be a problem, or is it unlikely to ever cause problems? Please note that I don't intend this to be a criticism of anyone. I'd just like to understand the costs incurred by real users when they have to deal with software that uses System V features, when the System V features can only be obtained via rebuilding the kernel. Thanks. Dan Weinreb Object Design, Inc. dlw@odi.com
johnl@ima.ima.isc.com (John R. Levine) (06/28/89)
In article <386@odi.ODI.COM> dlw@odi.com writes: >A few weeks ago, I believe someone mentioned that the new version of >RTI's Ingres makes use of one of the System V IPC features ... >... Now, in the standard Unix kernel distributed by Sun Microsystems, the >System V IPC features >are not assembled in; ... In the SunOS 4.0 kernel, the Sys V stuff is included by default, and you have to rebuild your kernel if for some reason you want to get rid of it. The IPC stuff seems, even by Sun standards, not to be very robust but that is a separate issue. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869 { bbn | spdcc | decvax | harvard | yale }!ima!johnl, Levine@YALE.something Massachusetts has 64 licensed drivers who are over 100 years old. -The Globe
reg@unify.UUCP (Russell Grau) (06/29/89)
In article <386@odi.ODI.COM> dlw@odi.com writes: >It seems to me that this might mean that in order to install RTI Ingres >at a Sun customer site, the customer might need to build a new kernel. > >I realize that building a new kernel isn't difficult for someone who >has any experience in these matters. But at some customer sites I'd >expect there to be only a few local "wizards" who know about building >kernels and who have permission to do so. In actual practice, would >anyone expect this to be a problem, or is it unlikely to ever cause >problems? > >Please note that I don't intend this to be a criticism of anyone. I'd >just like to understand the costs incurred by real users when they >have to deal with software that uses System V features, when the >System V features can only be obtained via rebuilding the kernel. Thanks. > >Dan Weinreb Object Design, Inc. dlw@odi.com Dan - Unify Corporation has been using the shared memory calls under Unix Sys V for over 3 years with their ACCELL/UNIFY dbms products. There have been times when it could cause a problem. Those generally show up when someone has zero experience using Unix and zero experience using dbms systems or following directions. The question should be, how good are the directions for the machine that the dbms software is to be installed on? How detailed are the instructions for the items/values in the kernal source files that need to be changed? Are the values where the directions say they should be? Rebuilding a kernel should not be an arduous task. Check the quality of instructions *before* you begin. If you have any questions, first, refer to the OS manual for guidence about re-genning the kernel, then secondly call the dbms support line. Reading the OS manual about the reconfiguration of a kernal is *always* a good bet before you begin any session. Russell Grau (916) 920-9092 reg@unify.UUCP Disclaimer - "All opinions are my own, and occasionally someone else's" {{ucdavis,csun,lll-crg}!csusac,pyramid,sequent}!unify!reg -- Russell Grau (916) 920-9092 reg@unify.UUCP Disclaimer - "All opinions are my own, and occasionally someone else's" {{ucdavis,csun,lll-crg}!csusac,pyramid,sequent}!unify!reg
david@cullsj.UUCP (David Taylor) (06/29/89)
In article <4121@ima.ima.isc.com>, johnl@ima.ima.isc.com (John R. Levine) writes: > In article <386@odi.ODI.COM> dlw@odi.com writes: > >A few weeks ago, I believe someone mentioned that the new version of > >RTI's Ingres makes use of one of the System V IPC features ... > >... Now, in the standard Unix kernel distributed by Sun Microsystems, the > >System V IPC features >are not assembled in; ... > > In the SunOS 4.0 kernel, the Sys V stuff is included by default, and you > have to rebuild your kernel if for some reason you want to get rid of it. > -- Kernel configuration files may be prepared from templates supplied with the SunOS distribution. Options may be added or deleted by editing a copy of the template. Different templates exist for different systems. There is a GENERIC template a stand-alone 3/60 template (SDST60), etc. In the SunOS 3.5 we received, all of the kernel configuration file templates enabled the IPC options. In the SunOS 4.0 we received, IPC was only enabled in the GENERIC template, but not in any of the other templates. I followed the Sun manual and used the SDST60 template for my stand-alone 3/60. As a result, I saw an application that used IPC successfully under 3.5 break under 4.0. Diagnosing the problem took a full day, but the fix - rebuilding the kernel - was straightforward and painless. This might not be the case for a kernel that has been highly customized. Note that anyone building a kernel from any of the non-GENERIC 4.0 templates (as manual suggests) could come to the same conclusion as dlw@odi.com did above. Anyone building a kernel from any 3.5 template or the GENERIC 4.0 template could reach the same conclusion as John Levine.
bab@unify.UUCP (Bob Batchelder) (06/30/89)
In article <386@odi.ODI.COM> dlw@odi.com writes: >A few weeks ago, I believe someone mentioned that the new version of >RTI's Ingres makes use of one of the System V IPC features (shared .... >kernel distributed by Sun Microsystems, the System V IPC features >are not assembled in; if you want them, you have to build a kernel .... >kernels and who have permission to do so. In actual practice, would >anyone expect this to be a problem, or is it unlikely to ever cause >problems? .... Well, your correct, not all kernels are sent configured for SYS V IPC features. Some which are, do not expect a "large" configuration to be required. Shared memory segment may be limited to a small size. We use shared memory with our products and so we have provided machine specific notes for those machines which need to be reconfigured to work well. In some instances, we have sent the user to the hardware vendor for help. The results, which I am sure RTI will find, have been quite good. The UNIX customer seems to be hardened to unexpected extras. ;-) I would not expect this to cause problems for them. The benefits of using the SYS V features will far outweigh the slight inconvenience for any of their customers. Bob Batchelder Quality Assurance (Where a quality time is assured.) Unify Corp.
nick@bilpin.UUCP (Nick Price) (07/04/89)
In article <386@odi.ODI.COM>, dlw@odi.com (Dan Weinreb) writes: > A few weeks ago, I believe someone mentioned that the new version of > RTI's Ingres makes use of one of the System V IPC features (shared > memory segment or semaphores; I'm not sure which, but it doesn't etc etc > Dan Weinreb Object Design, Inc. dlw@odi.com Most (ALL?) DBMS systems under Unix require IPC of some sort. Ingres requires shared memory and semaphores for the shared memory lock manager which seems to be the favoured lock manager for most Ingres/Unix systems. Prior to this lock manager being available RTI shipped a lock daemon (still do) which was fairy slow but easily installable and a lock driver (kernel pseudo device driver). The driver obviously required linking in the kernel and was sometimes a problem to install. DBMS vendors are not always the best people to document a kernel build on a forein box! These days Unix manufacturers generally ship configurable kernels and a bullet proof interface to re-link and reboot, so installing IPC should not be a problem, however their default supplied values are not always sufficient. ORACLE for example is generally happier if it can place it's SGA (a large shared memory area) in a single segment, or can attatch two or more segments contiguously. This generally requires a few tries to get it right. Moreover I wonder how many installations are running poorly because IPC parameters are not set up optimally for the DBMS? I have certainly seen quite a few over the last few years. In summary - *don't* complain if the Unix vendor doesn't ship IPC configured in your default kernel. If you don't need it then you won't notice that it's missing and you are saving physical memory which costs money. *Don't* complain if DBMS vendors utilise IPC. DBMS's are complex system products, and as such you should expect to spend some considerable time getting things installed and running *well*. *Do* complain if the Unix supplier doesn't ship a reconfigurable kernel or an interface to rebuild it. If they don't look for another box to run your DBMS. :^) -- _______________________________________________________________________________ Nick Price SRL Data || Apple link : UK0001 1 Perren Street London NW5 3ED || UUCP : nick@bilpin.uucp Phone: +44 1 485 6665 || Path : mcvax!ukc!icdoc!bilpin!nick