mailing list of musl libc
 help / color / mirror / code / Atom feed
From: "piranna@gmail.com" <piranna@gmail.com>
To: musl@lists.openwall.com
Subject: Re: static build and dlopen
Date: Tue, 2 Sep 2014 01:38:55 +0200	[thread overview]
Message-ID: <CAKfGGh3-CDeu+tCK3BssT3PAQC5+SLrwnCkBOFZu14vQS00w4w@mail.gmail.com> (raw)
In-Reply-To: <9C22AC43-6E0E-4CEE-ACA6-9CE07B4DACC7@gmail.com>

Sorry for the delay, I have been busy these days.

First of all, you were right: It possible to use dynamically linked
executables for PID 1, seems I was missing one of the libraries
(probably /lib/ld-linux.so.2... :-/ ). Now a Node.js script is working
as PID 1 and in fact, the /usr/bin/env she-bang is working too, that's
amazing :-D Sorry for have been doing so dumb questions this days,
it's the first time I'm digging so down on Operating System
architecture and I've missed this point (other guys go to the beach on
their holidays... :-P ). Now my changes are uploaded and QEmu is also
able to mount a hard disk image and access to it, all of it from
Node.js (with the help of some compiled Node.js modules, of course).

Regarding to the kernel low-level access, the compiled modules are
working just as bridges between C & Javascript. There are not so much
of them, but you can mount filesystems
(https://github.com/groundwater/node-src-mount), configure network
interfaces (https://github.com/groundwater/node-src-sockios,
https://github.com/groundwater/node-bin-ifconfig), ioctl
(https://github.com/groundwater/node-src-ioctl)... Oh, and also
shutdown the machine
(https://github.com/groundwater/node-bin-shutdown,
https://github.com/groundwater/node-src-reboot) ;-) Obviously at this
moment is really pre-alpha, but seems stable and could be useful to
gain some performance on Node.js machines since all the bloatware is
removed, but the idea is to take advantage of Node.js features,
capabilities and LXC containers (like Docker) to make isolation and
the feeling of the developer that "all the machine is theirs" as added
killer features :-) Obviously all of them must be run with setuid 0,
but at this moment I only needed it only for mounting the filesystem,
no more.

Oh, and if you want harder drugs, you should take a look at
http://runtimejs.org, where some developers works somewhat actively
(like groundwater) on both projects: where NodeOS aims to create a
Linux based operating system where all the user-space is build on top
of Node.js, runtime.js aims to develop an OS kernel in pure Javascript
on top of raw v8 isolates and get some extra performance by delegating
memory protection to them so all process can run on ring 0 (no
context-switchs) and message-based IPC by just exchanging a pointer.
Innovative? yes. Crazy? maybe. Awesome? don't doubt it ;-)

2014-08-28 1:36 GMT+02:00 Brent Cook <busterb@gmail.com>:
>
> On Aug 27, 2014, at 6:24 PM, Laurent Bercot <ska-dietlibc@skarnet.org> wrote:
>
>>> Node.js spends a lot of time throwing uncaught exceptions; I suspect
>>> transitioning to S5 will be less common than node just dying.
>>
>> Then it's all the more reason to *not* run it as process 1.
>> If Node.js dies unexpectedly, you want to restart it automatically,
>> or at least to reboot; you do not want a kernel panic and a
>> maintenance call.
>>
>>
>>> Perhaps this would be ok with a stateless netbooted ramdisk as a
>>> root fs.
>>
>> Kernel + libc + Node + all the needed node modules, netbooted ?
>> Now I know why the terminals at my train station are so slow. :P
>>
>> --
>> Laurent
>>
>
> IIRC the pfsense ands m0n0wall firewalls run PHP as process 1, so I
> guess something like this is not unheard of. But, they do run from a
> ramdisk as well.



-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux


  reply	other threads:[~2014-09-01 23:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-27 14:14 piranna
2014-08-27 15:27 ` Szabolcs Nagy
2014-08-27 17:01   ` piranna
2014-08-27 17:20     ` Justin Cormack
2014-08-27 20:07       ` piranna
2014-08-27 16:43 ` Rich Felker
2014-08-27 17:10   ` piranna
2014-08-27 18:48     ` Laurent Bercot
2014-08-27 20:19       ` piranna
2014-08-27 20:51         ` Rich Felker
2014-08-27 20:59         ` Laurent Bercot
2014-08-27 21:04           ` Rich Felker
2014-08-27 22:54           ` Kurt H Maier
2014-08-27 23:24             ` Laurent Bercot
2014-08-27 23:36               ` Brent Cook
2014-09-01 23:38                 ` piranna [this message]
2014-09-02  0:38                   ` Rich Felker
2014-09-02  0:49                     ` piranna

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKfGGh3-CDeu+tCK3BssT3PAQC5+SLrwnCkBOFZu14vQS00w4w@mail.gmail.com \
    --to=piranna@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).