$0$28985$e4fe514c@news.xs4all.nl...
> "Dan Koren" <dankoren@yahoo.com> writes:
>
>
> >How does one accomplish a system wide
> >LD_PRELOAD? Set it in the environment of
> >the first program that fires? And how
> >would one prevent an individual user
> >or shell from unsetting it?
>
> In Solaris "crle" will do that.
>
> crle -E LD_PRELOAD=dan-koren.so
>
> BTW, with clever LD_PRELOAD manipulation you can
> make it persist even if users try to remove it
> from the environment (by intercepting exec* and
> adding it back). Been there, done that.
> (That doesn't help against the runtime linker ignoring
> it in those cases it does)
>


Thanks, I will try it.



dk

"Richard L. Hamilton" <Richard.L.Hamilton@mindwarp.smart.net> wrote in
message news:11031ce48tfo751@corp.supernews.com...
> In article <420122ff$1@news.meer.net>,
> "Dan Koren" <dankoren@yahoo.com> writes:
> > "Casper H.S. Dik" <Casper.Dik@Sun.COM> wrote in message
> > news:4200c245$0$28983$e4fe514c@news.xs4all.nl...
> >> "Dan Koren" <dankoren@yahoo.com> writes:
> >>
> >> > I should have perhaps clarified that this would be used
> >> > as a system wide library to be loaded shortly after boot.
> >> > Think of it as a system wide LD_PRELOAD.
> >>
> >> Libraries are loaded into programs;
> >
> > I understand that.
> >
> >> they are not loaded into the system;
> >
> > I hope you don't mind if I say this is
> > a defficiency in the design of Unix. 30+
> > years ago the leading commercial OS's
> > (OS/360, Kronos, NOS/BE, TOPS-10/20, etc.)
> > allowed libraries to be loaded system
> > wide at boot time. I may be revealing
> > my age ;-)
> [...]
>
> SVR3 shared libraries worked like that, IIRC.
>


I'm not sure I understand what you refer to
as SVR3 shared libraries. I don't recall that
SVR3 supported dynamically linked shared libs.
Many SVR3 libraries were non-reentrant, and
most programs were linked statically with
the libraries they used.

When SVR4 came about, one of the big claims
was in fact the introduction of dynamically
linked shared libraries. Perhaps you could
elaborate a little on what libraries were
dynamically linked and shared in SVR3, and
how did they work?

Thx,


dk

"Casper H.S. Dik" <Casper.Dik@Sun.COM> wrote in message
news:42012ea0$0$28985$e4fe514c@news.xs4all.nl...
> "Dan Koren" <dankoren@yahoo.com> writes:
>
> >> You cannot load a shared library except in a
> >> process, so this makes no sense.
>
> > Only if one follows the textbooks ;-)
>
> Well, you may call it a shared library but that
> would not make it one.
>
> LD_PRELOAD with something in the init section
> would get control very early but not the earliest
> (ld.so and libc.so likely win)
>
> > The picture from 1,000,000 ft is simply that I
> > need a library that performs some magic tricks
> > to be present and active in every context before
> > any user level process starts running, so it can
> > intercept the loading of any text file in the
> > system, and instrument it in a certain fashion.
>
> Have you looked at dtrace in Solaris 10? It does
> allow for global (non destructive) instrumentation.


Yes, I've looked at dtrace. It is a nifty tool,
but it does not do what I need done (and it is
also not available on HP-UX).


> > It would be a little complicated, and possibly
> > inappropriate, to discuss the details in a
> > public forum. If you are interested in the
> > details of this project, I would be happy
> > to elaborate in private e-mail.
>
> In appropriate as in "secret" or as in going
> into too many details?


I cannot disclose what the instrumentation is
supposed to do, or the nature and the goals of
the experiment. All I can say is that part of it
relies on the ability to mangle code on the fly
(not in the C++ sense).


> I don't think there is such thing as too much
> detail when asking for help with a technical
> problem.


You are absolutely right. I apologize to all
for not being able to say more about the
nature of this experiment.


> In the end, and this may depend on the nature
> of the instrumentation, the answer could be as
> simple as "oh, but then you will need to use
> the FOO widget".


You might be right, and I've seen many such
situations myself. In this case however, it
does appear that there is no existing FOO
widget that would do the job.

Many thanks again for your help.


dk

"Dan Koren" <dankoren@yahoo.com> writes:

> "Dan Espen" <daneNO@SPAM.mk.telcordia.com> wrote in message
> news:icfz0es76x.fsf@home-1.localdomain...
>> "Dan Koren" <dankoren@yahoo.com> writes:
>>
>> > "Casper H.S. Dik" <Casper.Dik@Sun.COM> wrote in message
>> > news:4200c245$0$28983$e4fe514c@news.xs4all.nl...
>> >> "Dan Koren" <dankoren@yahoo.com> writes:
>> >>
>> >> > I should have perhaps clarified that this would be used
>> >> > as a system wide library to be loaded shortly after boot.
>> >> > Think of it as a system wide LD_PRELOAD.
>> >>
>> >> Libraries are loaded into programs;
>> >
>> > I understand that.
>> >
>> >> they are not loaded into the system;
>> >
>> > I hope you don't mind if I say this is
>> > a defficiency in the design of Unix. 30+
>> > years ago the leading commercial OS's
>> > (OS/360, Kronos, NOS/BE, TOPS-10/20, etc.)
>> > allowed libraries to be loaded system
>> > wide at boot time. I may be revealing
>> > my age ;-)
>>
>> Are you sure that preloading a load module
>> on MVS _runs_ that load module?
>>
>> If you want to accomplish something similar
>> to what an MVS preload
>> does, don't do anything. UNIX will commit
>> the used parts to system wide shared
>> memory buffers on the first use.
>>
>> Having used both MVS and UNIX, I think you
>> are way off base with your deficiency
>> comment.
>
>
> There was *NO* mention of MVS in my article.

OS/360?

carnot% cd /tmp
carnot% cat > koren.c
#include <stdio.h>
void
hello()
{
puts("hello\n");
}
void
goodbye()
{
puts("goodbye\n");
}
carnot% cc -G -o koren.so koren.c -lc -zinitarray=hello
-zfiniarray=goodbye
carnot% setenv LD_PRELOAD `pwd`/koren.so
carnot% sleep 1
hello

goodbye
carnot%

- Bart "One test is worth one thousand expert opinions."

"Dan Espen" <daneNO@SPAM.mk.telcordia.com> wrote in message
news:icacqms1to.fsf@home-1.localdomain...
> "Dan Koren" <dankoren@yahoo.com> writes:
>
> > "Dan Espen" <daneNO@SPAM.mk.telcordia.com> wrote in message
> > news:icfz0es76x.fsf@home-1.localdomain...
> >>
> >> Having used both MVS and UNIX, I think you
> >> are way off base with your deficiency
> >> comment.
> >
> > There was *NO* mention of MVS in my article.
>
> OS/360?


Nope.

OS/360 and MVS were different OS's (although the
latter was indeed descended from the former).

The genealogy was roughly like this:

OS/360 MFT --> OS/360 MVT
| |
| |
V V
OS/370 SVS1 -> OS/370 SVS2 --> OS/370 MVS.


One additional dimension was TSO
vs. non-TSO systems.

Enough things changed between each two of
these that they should be considered as
different systems, not unlike Unix going
from System 7 to SVR3 to SVR4.


dk

This is great! Thanks for your help.

BTW is carnot exploding any time soon? ;-)


dk

<barts@smaalders.net> wrote in message
news:1107406374.334072.242610@o13g2000cwo.googlegr oups.com...
> carnot% cd /tmp
> carnot% cat > koren.c
> #include <stdio.h>
> void
> hello()
> {
> puts("hello\n");
> }
> void
> goodbye()
> {
> puts("goodbye\n");
> }
> carnot% cc -G -o koren.so koren.c -lc -zinitarray=hello
> -zfiniarray=goodbye
> carnot% setenv LD_PRELOAD `pwd`/koren.so
> carnot% sleep 1
> hello
>
> goodbye
> carnot%
>
> - Bart "One test is worth one thousand expert opinions."
>

In article <4201a25c$1@news.meer.net>, "Dan Koren" <dankoren@yahoo.com>
wrote:

> "Richard L. Hamilton" <Richard.L.Hamilton@mindwarp.smart.net> wrote in
> message news:11031ce48tfo751@corp.supernews.com...
> > In article <420122ff$1@news.meer.net>,
> > "Dan Koren" <dankoren@yahoo.com> writes:
> > > "Casper H.S. Dik" <Casper.Dik@Sun.COM> wrote in message
> > > news:4200c245$0$28983$e4fe514c@news.xs4all.nl...
> > >> "Dan Koren" <dankoren@yahoo.com> writes:
> > >>
> > >> > I should have perhaps clarified that this would be used
> > >> > as a system wide library to be loaded shortly after boot.
> > >> > Think of it as a system wide LD_PRELOAD.
> > >>
> > >> Libraries are loaded into programs;
> > >
> > > I understand that.
> > >
> > >> they are not loaded into the system;
> > >
> > > I hope you don't mind if I say this is
> > > a defficiency in the design of Unix. 30+
> > > years ago the leading commercial OS's
> > > (OS/360, Kronos, NOS/BE, TOPS-10/20, etc.)
> > > allowed libraries to be loaded system
> > > wide at boot time. I may be revealing
> > > my age ;-)
> > [...]
> >
> > SVR3 shared libraries worked like that, IIRC.
> >
> > The current dynamic linking environment is far more flexible.
> >
> > That you may have to get a bit devious to do the odd sort of
> > thing you want to do is perhaps not a deficiency at all.
> >
>
> This is obviously a matter of taste and
> development philosophy. I like an OS to
> provide mechanisms, not policies. It is
> somewhat difficult to completey separate
> the two, however most commercial OS's do
> not even try.
>
>
>
> dk

Well, you free to run NOS/BE on a CDC system or a DEC-2060 running
TOPS-20 or TENEX or ITS in your garage. You'll have to maintain all of
it yourself. No one's stopping you.

Or you could cobble a Linux kernel to do whatever you want on whatever
hardware you want. No one's stopping you.

It seems more like a "why can't I buy a car that runs on ethanol" issue
than anything to do with the currently available Solaris 10. If you're
a paying customer with enough money, schedule an appointment with Scott.
Otherwise, I guess you'll have to do without, roll your own, or just
move on.

[Having joined the "in my day" crowd, I sorta sympathize. But I think
it's time to get a life and move on.]

--
DeeDee, don't press that button! DeeDee! NO! Dee...

"Dan Koren" <dankoren@yahoo.com> writes:

> "Dan Espen" <daneNO@SPAM.mk.telcordia.com> wrote in message
> news:icacqms1to.fsf@home-1.localdomain...
>> "Dan Koren" <dankoren@yahoo.com> writes:
>>
>> > "Dan Espen" <daneNO@SPAM.mk.telcordia.com> wrote in message
>> > news:icfz0es76x.fsf@home-1.localdomain...
>> >>
>> >> Having used both MVS and UNIX, I think you
>> >> are way off base with your deficiency
>> >> comment.
>> >
>> > There was *NO* mention of MVS in my article.
>>
>> OS/360?
>
>
> Nope.
>
> OS/360 and MVS were different OS's (although the
> latter was indeed descended from the former).
>
> The genealogy was roughly like this:
>
> OS/360 MFT --> OS/360 MVT
> | |
> | |
> V V
> OS/370 SVS1 -> OS/370 SVS2 --> OS/370 MVS.

Right, next you'll be telling me
z/OS is different than esa/390.

The names change to protect the innocent
but the JCL remains as ugly as it ever was.
Even including the non-functional IF statement.

> One additional dimension was TSO
> vs. non-TSO systems.
>
> Enough things changed between each two of
> these that they should be considered as
> different systems, not unlike Unix going
> from System 7 to SVR3 to SVR4.

Marketing.

In my little corner of the world, I've
decided to put a stop to the constant revision
of our end user documentation changing IBMs OS
names to the flavor of the month.

We stopped at MVS and until it's noticably
different, it will remain MVS.

BTW, load doesn't execute on any of the flavors.

"Michael Vilain" <vilain@spamcop.net> wrote in message
news:vilain-FCB968.01321203022005@news.giganews.com...
> In article <4201a25c$1@news.meer.net>, "Dan Koren" <dankoren@yahoo.com>
> wrote:
>
> > "Richard L. Hamilton" <Richard.L.Hamilton@mindwarp.smart.net> wrote in
> > message news:11031ce48tfo751@corp.supernews.com...
> > > In article <420122ff$1@news.meer.net>,
> > > "Dan Koren" <dankoren@yahoo.com> writes:
> > > > "Casper H.S. Dik" <Casper.Dik@Sun.COM> wrote in message
> > > > news:4200c245$0$28983$e4fe514c@news.xs4all.nl...
> > > >> "Dan Koren" <dankoren@yahoo.com> writes:
> > > >>
> > > >> > I should have perhaps clarified that this would be used
> > > >> > as a system wide library to be loaded shortly after boot.
> > > >> > Think of it as a system wide LD_PRELOAD.
> > > >>
> > > >> Libraries are loaded into programs;
> > > >
> > > > I understand that.
> > > >
> > > >> they are not loaded into the system;
> > > >
> > > > I hope you don't mind if I say this is
> > > > a defficiency in the design of Unix. 30+
> > > > years ago the leading commercial OS's
> > > > (OS/360, Kronos, NOS/BE, TOPS-10/20, etc.)
> > > > allowed libraries to be loaded system
> > > > wide at boot time. I may be revealing
> > > > my age ;-)
> > > [...]
> > >
> > > SVR3 shared libraries worked like that, IIRC.
> > >
> > > The current dynamic linking environment is far more flexible.
> > >
> > > That you may have to get a bit devious to do the odd sort of
> > > thing you want to do is perhaps not a deficiency at all.
> > >
> >
> > This is obviously a matter of taste and
> > development philosophy. I like an OS to
> > provide mechanisms, not policies. It is
> > somewhat difficult to completey separate
> > the two, however most commercial OS's do
> > not even try.
>
> Well, you free to run NOS/BE on a CDC system or a DEC-2060 running
> TOPS-20 or TENEX or ITS in your garage. You'll have to maintain all of
> it yourself. No one's stopping you.
>
> Or you could cobble a Linux kernel to do whatever you want on whatever
> hardware you want. No one's stopping you.
>
> It seems more like a "why can't I buy a car that runs on ethanol" issue
> than anything to do with the currently available Solaris 10. If you're
> a paying customer with enough money, schedule an appointment with Scott.
> Otherwise, I guess you'll have to do without, roll your own, or just
> move on.
>
> [Having joined the "in my day" crowd, I sorta sympathize. But I think
> it's time to get a life and move on.]
>


If we followed your line of reasoning,
one would never engage in discussion
of OS and system architecture, right?


dk