Mario Frasca writes:
>
> login.c: fchown is not defined in my environment, the two lines around
> #46 were commented out in the previous version. I commented them out
> again, but I believe there is an other solution?
fchown was commented out because there was a kernel bug in the code
for fchown. This has now been fixed (see the online bug tracking system).
If you don't have fchown, this is almost certainly because you did not
build your libc against the correct ELKS kernel.
>
> ps.c: and I can't compile it, what are these two <linuxmt/mem.h> and
> <linuxmt/sched.h> ?
These include files should be in your ELKS kernel tree. /usr/bcc/include
should contain links to elks/include/linuxmt and elks/include/arch. Check.
If it doesn't then build these links by hand.
>
> init.c: here is my new version. I am prepared to receive lots of
> complains, it works good enough for me, but I can imagine some of you
> expect more. it uses /etc/inittab, this works nicely, and is designed
> to allow changing the current runlevel, but somehow that doesn't work,
> anyone wanting to help? I tried to minimize memory usage, the way I
> chose was to hold very little information about the 8 possible children
> and read /etc/inittab each time something happens to a child. If you
> feel that 8 children are too few for your init process, you can increase
> that value or we could make that more flexible... But I thought someone
> (Al?) said that in ELKS a process statically allocates memory on startup
> so I don't think this added flexibility makes much sense.
>
> well, here is the source, I can't check it in into CVS myself.
I will check it, and then commit it when I am back at work this week.
All memory is allocated at runtime at the moment, true, so the flexibility
you describe does not help much.
Thanks,
Al
