[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 2 Sep 2014 01:38:55 +0200
From: "piranna@...il.com" <piranna@...il.com>
To: musl@...ts.openwall.com
Subject: Re: static build and dlopen
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@...il.com>:
>
> On Aug 27, 2014, at 6:24 PM, Laurent Bercot <ska-dietlibc@...rnet.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
