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 5:08 PM
> To: Julian Reschke
> Cc: Guido Flohr; MiNT mailing list
> Subject: RE: [MiNT] Was: /proc, will be: /sys
>
>
>
> > > 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...
>
> Yes it is. But an SLB (in Gryfs implementation) is really a process that
> started but has been stopped (with SIGSTOP). This works perfectly, and all
> the modification I could do is visual - so that ps could display this as a
> "library", not as "stopped process". Considering the lib receives SIGCONT
> when it is closed (so that it shuts down), I don't think there should be
> done anything related to queues.
>
> There's yet another problem - such lib can be killed with SIGKILL. So
> what about a field in the proc struct, that could indicate the process
> being signalled is a library, thus killing is undesired?
>
> I don't know - thus I am asking around for opinions... :-)

Sounds reasonable. And if this field can be inquired, it can also be used to
display the "right" thing in ps.

> > > 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...
>
> But still, the code for "dynamic linking" this way is linked statically
> (program is bigger).

Yes, but I am talking about a method which has been working in MagiC and
plain TOS for over a year now -- nothing that is currently being designed
and then is likely to be a MiNT-only approach...