RE: [MiNT] Was: /proc, will be: /sys

["Julian Reschke" <reschke@muenster.de>]

> From: Konrad M. Kokoszkiewicz [mailto:draco@obta.uw.edu.pl]
> Sent: Wednesday, November 17, 1999 4:55 PM
> To: Julian Reschke
> Cc: Guido Flohr; MiNT mailing list
> Subject: RE: [MiNT] Was: /proc, will be: /sys
>
>
>
> > > > OK, so why not just define a new file attribute combination
> for the SLB
> > > > instance, and this is it?
> > >
> > > The only problem is that there are some rules implemented (like +a are
> > > stopped processes etc) and I am afraid of inventing something
> that breaks
> > > these. Otherwise, what about $25 for a lib? Gryf?
> >
> > In fact, I think in addition to the attribute there is also a
> process state
> > (wait queue value?) to be defined as well, correct? Regarding the file
> > attributes -- I doubt that they are used for anything else then
> -- display,
> > right?
>
> Process state is 'stopped'. I think we can stay at this, as all libs are
> 'stopped' most of the time. Anyway, perhaps you're right, I'll look at the
> procfs.c when I'll be back home.

Isn't the file attribute not just a representation of the process state? In
that case I would find it a bit confusing to have different file attributes,
but the same run state...

> > > Otherwise I think the SLBPATH variable value should be just
> pasted into
> > > libpath, if the libpath specified by the opening program is NULL.
> > >
> > > Anyway, I still miss real, program transparent library scheme.
> >
> > Could you be a bit more specific?
>
> In which a theme I am not specific? As for the libs I miss, I meant
> dynamic linker & stuff. So that process does not actually have to actively
> "open" anything, but the system does all necessary linking automatically
> at the time the bin is loaded.

At least in my test application, I have moved the Slbopen() (or is it
Slbload()) into the function proxy. Then I can decide about static/dynamic
linking by linking to the old library, or the SLB proxy. No change in the
source code at all...