TCBORDP%VCCSCENT.bitnet@vtvm2.cc.vt.edu (Peter W. Borders) (05/10/91)
This is a request directed to Fred van Kempen. I tried direct mail but I imagine it never got through. Mr. van Kempen, could you please post the updated programs for Init/Getty/Modem either to the newsgroup or place them on plains? I am not the only person that has been having some problems with the getty hanging. It seems to be modem dependent but it is possible that the latest versions may be more functional. I am quite happy with the package, except for that one problem. It would also be nice to have a telinit program, especially when trying to track down run away getty processes. I have no problem with changing the FS or MM to support the telinit, if need be. Thank you in advance. Pete Borders <tcbordp@vccscent> : Bitnet
waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) (05/20/91)
TCBORDP%VCCSCENT.bitnet@vtvm2.cc.vt.edu (Peter W. Borders) wrote: > This is a request directed to Fred van Kempen. I tried direct mail but > I imagine it never got through. Mr. van Kempen, could you please post > the updated programs for Init/Getty/Modem either to the newsgroup or > place them on plains? I am not the only person that has been having some > problems with the getty hanging. It seems to be modem dependent but > it is possible that the latest versions may be more functional. I am > quite happy with the package, except for that one problem. It would also > be nice to have a telinit program, especially when trying to track down > run away getty processes. I have no problem with changing the FS or MM > to support the telinit, if need be. Thank you in advance. Humm. Apart from long (a week) delays in answering my mail, everything works fine. I guess some mailer _before_ the big jump over the pond ate it... Anyway, about Getty and INIT.. I can post the current getty (3.18) and gettydefs allright, but that would not fix everything. It has been reported that the MacMINIX/MINIX-ST/AmigaMINIX serial drivers treat line errors different from the iNTEL versions of MINIX. Getty relies on the iNTEL way of treating errors to switch baudrates and such. The INIT stuff is "a bit" different. The NLMUG INIT package relies on several changes in MM and FS about the whereabouts of the "init" process. NLMUG INIT consists of two programs: the "sinit" program, which is linked to the OS image ("SINIT"), and the actual "init" program, which lives in /etc . The latter is executed by SINIT at boot time. Because "init" is no longer at slot 2, lots of things can go wrong. The best example is the allocation/deallocation of control terminals to process group leaders: only children of "init" (== now slot 3 , not 2 !!) can become procgrp leader. See the point? The solution is obvious: go over the MM and FS sources, and check if they mean "LOW_USER" (== "init") or "SINIT". In the pre-DynaLink age, I defined the following macros: #define SINIT 2 /* process where SINIT lives */ #define LOW_USER (SINIT + 1) /* the first user process */ With these defines, and a bit of work in MM/FS, you can recompile the system, and install the new INIT and SINIT. Link /etc/init to /etc/telinit, and you have run level support. I will create a package of the new stuff, and upload it to Plains tonight. Fred. -- MicroWalt Corporation, for MINIX Development waltje@uwalt.nl.mugnet.org Tel (+31) 252 230 205, Hoefbladhof 27, 2215 DV VOORHOUT, The Netherlands "An Operating System is what the _USERS_ think of it- me"