From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Wed, 3 Nov 93 05:13:09 EST Subject: Linux-Development Digest #207 Linux-Development Digest #207, Volume #1 Wed, 3 Nov 93 05:13:09 EST Contents: Re: WILL ???BSD DIE? (Alan Coopersmith) Building Mach 3.0 under Linux (Louis-D. Dubeau) Re: What's wrong with a DOS to Linux disk access? (Byron A Jeff) Re: Building Mach 3.0 under Linux (James da Silva) Re: WILL ???BSD DIE? (Mike Mike Hoffman) perl4.036 on linux fails pipe test (Neal Becker) Re: Yet another core dumps name suggestion (Olaf Schlueter) idea for TERM client (Steve Osborn) Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (nichols@ttd.teradyne.com) Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (Hal N. Brooks) Re: WANTED: COBOL compiler (Steven R Clark) Re: What's wrong with a DOS to Linux disk access? (Vinod G Kulkarni) Re: WILL ???BSD DIE? (J. Minnich) ---------------------------------------------------------------------------- From: alanc@OCF.Berkeley.EDU (Alan Coopersmith) Crossposted-To: comp.os.mach,comp.os.os2.programmer.misc,comp.os.minix,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.development,comp.os.386bsd.bugs,comp.os.386bsd.apps,comp.os.386bsd.questions,comp.os.386bsd.misc Subject: Re: WILL ???BSD DIE? Date: 2 Nov 1993 18:16:01 GMT Reply-To: alanc@ocf.berkeley.edu jmonroy@netcom.com (Jesus Monroy Jr) writes in comp.unix.bsd: )>> There are several reasons for this: )>> )>> (1) the 386BSD ftp site is taking up approximately 120M )>> of disk space, which can be better used for other )>> things. )>> ) Yes, I here NETBSD might actually need this space. ) ) Is this true? Couldn't have anything to do with agate being a machine the we actually use here at berkeley (it's the main news server used by several thousand users among other things). And what does it matter? Did he say he was removing it from the net as a whole? Anyone who mirrors agate can set up their mirror not to delete 386bsd when agate does, if they want to. You want it to stay around, start talking to the admins of the mirror sites. -- ========================================================================== Alan Coopersmith Internet: alanc@ocf.berkeley.edu U.C. Berkeley Open Computing Facilty Bitnet: alanc@ucbocf ------------------------------ Crossposted-To: comp.os.mach From: hallu@info.polymtl.ca (Louis-D. Dubeau) Subject: Building Mach 3.0 under Linux Date: Tue, 2 Nov 1993 16:58:13 GMT Hi there, I've finaly succeded in building the Mach 3.0 mk under Linux. (Well, I think I have a usable microkernel.) BTW, sory to those who asked me questions and to whom I didn't respond. Here is what I did. I hope this will help people who want to build Mach 3.0 under Linux or some other platform. I've downloaded the Mach 3.0 mk with the buildtools and the i386 specific code. I've also downloaded the documentation. IT'S VERY IMPORTANT TO READ THE DOCUMENTATION BEFORE TRYING ANYTHING. I then modified the setup.sh, bootstrap.sh and setvar.csh scripts that come with the buildtools. I build the ode tools and then the all the buildtools (rebuilding the ode tools in the process). I had to build xstrip by hand since the Makefile sets LPATH with Mach libs before Linux libs. When you build xstrip with the makefile, it link the object files with Mach's crt0.o. As you can imagine this leads directly to a core dump when you try to execute xstrip. The solution is either to patch the Makefile or to build it by hand. I tried next to build the mk. I had to change most "#ifdef __386BSD__" in the lex scripts to "#if defined(__386BSD__) || defined(__linux__)" . I also patched one of the .mk file (of odemake) to use libfl instead of libl. You can also make a symlink from libfl to libl. The next problem I had was with config. It dumped core at me every time I tried to execute it. The problem was in the memory deallocation algorithm in mkheaders.c (function doheader). The code dereferenced pointers that were already deallocated. (In some OS that could work.) I've replaced that code with a recursive deallocation algorithm. I then had to modify makeboot, in order for it to be able to recognize a Linux binary. I had to change switch((int)x.image) to switch((short int)... in the exec.c file in kernel/src/makeboot/i386. With all those modification, I got odemake to procude a bootable microkernel. I tried to load it with LILO but it didn't work. LILO loaded the image and then returned to the "LILO boot:" prompt. Now, how will I get the damn thing to boot? (Yes, I know I also need a server if I want to do something useful with the mk.) A la prochaine Louis-Dominique Dubeau -- =========================================================================== | Hallu (Louis-Dominique Dubeau) | | Membre du Comite Micro de l'AEP | | Departement de Genie Informatique | | Ecole Polytechnique de Montreal (Montreal, Quebec) | ====================== This sentence is false !!! ======================== ------------------------------ From: byron@cc.gatech.edu (Byron A Jeff) Subject: Re: What's wrong with a DOS to Linux disk access? Date: Tue, 2 Nov 1993 19:09:29 GMT In article , Marc ter Horst wrote: >In article <1993Nov1.234432.25077@cc.gatech.edu> byron@cc.gatech.edu (Byron A Jeff) writes: >>From: byron@cc.gatech.edu (Byron A Jeff) >>Subject: Re: What's wrong with a DOS to Linux disk access? >>Date: Mon, 1 Nov 1993 23:44:32 GMT > >>In article , >>Steef S.G. de Bruijn wrote: >>>Again about security: Maybe a sort of FTP server just for >>>copiing files from and to the Linux FS AFTER legally logging >>>in... >>> > >>Considering that Linux won't be running at the time, I think that's going >>to be some magic trick. > >>However since you'll have access to the password (and shadow I guess) files >>you can force the person to give a login and password before allowing file >>transfer. > >Sure, and if they've got source code it's no problem getting around the >password stuff ! > This is the same argument for spending $3000 on a security system. Anyone who really wants access can defeat the security. However it'll cost in time and effort so to that. In the same vein anyone who really wants Linux access can just bring their on Linux boot floppy to the party. The idea is not to allow for casual or easy access. Anyone who takes the time to get ahold of the source code, modify it, recompile it, then run it can't really be stopped anyway. The bottom line, as stated before, is that anyone who has physical access to any PC can get anywhere with enough time and effort. So the task is to enforce that time and effort. Later, BAJ --- Another random extraction from the mental bit stream of... Byron A. Jeff - PhD student operating in parallel! Georgia Tech, Atlanta GA 30332 Internet: byron@cc.gatech.edu ------------------------------ From: jds@cs.umd.edu (James da Silva) Crossposted-To: comp.os.mach Subject: Re: Building Mach 3.0 under Linux Date: 2 Nov 1993 14:46:58 -0500 hallu@info.polymtl.ca (Louis-D. Dubeau) writes: > With all those modification, I got odemake to procude a bootable >microkernel. I tried to load it with LILO but it didn't work. LILO loaded >the image and then returned to the "LILO boot:" prompt. > > Now, how will I get the damn thing to boot? (Yes, I know I also >need a server if I want to do something useful with the mk.) Good job so far. Now you've come to the crux of the matter! First, you need to check that all the little details are right. Mach has to be loaded at the right address and invoked in the right manner. Mach is expecting to be invoked in protected mode with valid segment registers set up to a "flat" address space, and it is expecting parameters passed from the boot program on its stack. Look at the following files to piece together how these parameters are pushed/popped/used: i386at/boot/asm.S i386at/asm_startup.h i386at/model_dep.c i386/setroot.c You'll have to modify either your boot program or the Mach startup to get the arguments differently. Once you have that part in sync you should be able to see Mach go through its initial device probe sequence. After the devices probe, Mach hands off to the bootstrap task, which was connected to it by makeboot. If makeboot wasn't modified correctly for your Linux a.out format, the whole thing will go south at this point. Then the bootstrap loader will try to open a paging file, and load and run the first server. For all that to work, the disk driver will need to recognize the Linux partitioning system. As is, it expects a BSD-ish label on the disk somewhere (can be in a DOS partition) and takes its info from that. Of course, bootstrap will also have to understand your Linux filesystems and a.out format, as will any Unix server you want to run. Whew. Good luck, you'll need it. I know, I've been there. :-) Jaime ............................................................................ : Stand on my shoulders, : jds@cs.umd.edu : James da Silva : not on my toes. : uunet!mimsy!jds : Systems Design & Analysis Group ------------------------------ From: mike@scrooge.uoregon.edu (Mike Mike Hoffman ) Crossposted-To: comp.os.mach,comp.os.os2.programmer.misc,comp.os.minix,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.development,comp.os.386bsd.bugs,comp.os.386bsd.apps,comp.os.386bsd.questions,comp.os.386bsd.misc Subject: Re: WILL ???BSD DIE? Date: 2 Nov 1993 21:07:27 GMT In article jmonroy@netcom.com (Jesus Monroy Jr) writes: >mail cgd@agate.berkeley.edu >Re: Subject: Status of 386BSD FTP Site on agate.berkeley.edu > > I've cross-posted this to the other PD OSes, because > it's time to move on. > > FANS, this is going to be .... > >>> Date: 1 Nov 1993 19:41:25 -0800 >>> >>> Barring serious objections, the 386BSD FTP Site on agate.berkeley.edu >>> will be disappearing on December 1, 1993. >>> > You must be kidding. Please define a "serious objection". > >>> There are several reasons for this: MUCH JUNK DELETED >>> > CHRIS resign. Take your merry men with you. While your at it > take those (subsubsub) contractors to BSDI with you. > You (subsubsub) contractors don't write to tell me how useless > your code is. Hackers in general -- don't take this personally. > I've just had enough... not enough to quit... but just enough to > tell people where to go for Christmas. Those of you working on > FreeBSD have my opinions. > > This leaves the people who like me.. well may all five of us > can get together someday. I guess we'll call it the > > "We get pead-on for speak our own opinion". > > That's all I have to say... missspellingsss and alll/ > >___________________________________________________________________________ >Jesus Monroy Jr jmonroy@netcom.com >Zebra Research >/386BSD/device-drivers /fd /qic /clock /documentation >___________________________________________________________________________ > PRO 1. I like 386BSD . It works for me. I have had little or no problems with it. (once I got it installed) CON 1. It does take a lot of hard disk space. 2. It attracts people who bitch and complain alot. I will be sorry to see 386BSD go. The departure does provide incentive to move on... to where: FreeBSD, LINUX ????? Maybe this is natures way of telling us to get off our rears. Mike@scrooge.uoregon.edu ------------------------------ From: neal@ctd.comsat.com (Neal Becker) Crossposted-To: comp.lang.perl Subject: perl4.036 on linux fails pipe test Date: 02 Nov 1993 13:41:26 GMT I just built linux-4.036 on linux. It fails the io/pipe test, but passes all others. Has anyone done better than this? Should I be concerned? BTW, one small patch is needed to doio.c to compile. I will provide it if I get this working (or if anyone wants it). ------------------------------ From: olaf@toppoint.de (Olaf Schlueter) Subject: Re: Yet another core dumps name suggestion Date: 3 Nov 1993 00:44:32 +0100 basile@soleil.serma.cea.fr (Basile STARYNKEVITCH) writes: >Also, my opinion is that the whole idea of core files (a good idea in >the PDP-8 unix days) is wrong today, since more and more programs are >huge and buggy (todays core file can easily much bigger than the >executable file whose execution produced them). Perhaps each process >could have an associated debugger server (or connection) which would be >sent a message by the kernel when a core used to be made (ie when a >naughty signal is sent). A default implementation of such a debugger >server might produce core files just like gcore command. Better choices >would be forking an interactive debugger (eg an xxgdb). I totally agree: recently I got a core file from a 300K program with a size of 14M (a image processing application) - dumped over NFS! (a cup of coffee dump :-)) I never care about core files as I did not yet face a situation when I cannot replicate an error with a debugger running and controlling the process. Even if such a situation would arise, the core file is just one sample of a erroneous run, and you are unable to deduce the reasons of the bug from the core file, you must see the program running into the error. As a matter of fact (as my debugger always tries to load a file core, if existing, when I want to debug a program, and sometimes it is from a different program or an older version, so I have to remove it to proceed), core files are just like MSDOS: things that get in your way. Some shells allow disabling core dumps. Just do it. -- Olaf Schlüter, Sandkuhle 4-6, 24103 Kiel, Germany, Toppoint Mailbox e.V. "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." David Megginson ------------------------------ From: osborn@ae.sps.mot.com (Steve Osborn) Subject: idea for TERM client Date: Wed, 3 Nov 1993 00:32:19 GMT The recent TERM upset got me thinking about term clients and I came up with one. Maybe this is old news but here goes: The new client, called trestart, would awaken a sleeping term and get it to reopen the serial ports that it was using before. The trouble is that I get phone calls while I'm terming into work and all the shells I have get destroyed. What would be really cool is if term could trap SIGHUP and instead of shutting down, close the serial ports and wait for a wake-up message. This way all the term clients could just hang until the serial connection gets re-established. Sort of like NFS mounted drives not being accessible. Anybody know if this has been done? -steve osborn@ae.sps.mot.com ------------------------------ From: nichols@ttd.teradyne.com Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: Mon, 01 Nov 93 20:01:59 GMT The real complaint, as I see it, is not that "core.imagename" is a bad idea, but that it makes it impractical to write simple scripts that will delete core.* files. (As stated by others, core.c, core.h, and core.5 are files that should not be deleted gratuitously.) I too am not in favor of trying to use special characters to delimit the file name. It will confuse too many users. How 'bout this? Instead of creating a core.imagename file, write it as core.-imagename. Yes, it is an extra character, but ".-" is not a common character sequence in files. In fact, there were no matches for *any* filename containing the character sequence ".-" on three different computers (running Linux, SunOS 4.1.3, and Solaris 2.2). Surely, then, a statement of 'rm core.-*' would be acceptable in scripts. Just a thought, Rick -- Richard D. Nichols Phone: (708) 940-9000 Teradyne Inc., Telecommunications Div. Fax: (708) 940-0344 1405 Lake Cook Road Email: nichols@ttd.teradyne.com Deerfield, IL 60015 ------------------------------ From: hal@pollux.cs.uga.edu (Hal N. Brooks) Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: 3 Nov 1993 03:43:22 GMT Reply-To: hal@pollux.cs.uga.edu (Hal N. Brooks) In article <1993Nov1.140548.1@ttd.teradyne.com> nichols@ttd.teradyne.com writes: > > The real complaint, as I see it, is not that "core.imagename" >is a bad idea, but that it makes it impractical to write simple >scripts that will delete core.* files. (As stated by others, >core.c, core.h, and core.5 are files that should not be >deleted gratuitously.) I too am not in favor of trying to I've really not been concerned with this issue, and maybe this method for deleting core files under the current naming scheme (core.imagename) has been mentioned, or maybe it has some ridiculously obvious disastrous result, but how about: rm `find . -name core\* -exec file {} \; | grep "core file" | sed -e "s/:.*$//"` here's a step-by-step example: {~}: find . -name core\* ./core.a.out ./core.c {~}: find . -name core\* -exec file {} \; ./core.a.out: core file (Linux) ./core.c: ascii text {~}: find . -name core\* -exec file {} \; | grep "core file" ./core.a.out: core file (Linux) {~}: find . -name core\* -exec file {} \; | grep "core file" |sed -e "s/:.*$//" ./core.a.out {~}:rm `find . -name core\* -exec file {} \;|grep "core file"|sed -e "s/:.*$//"` {~}: find . -name core\* ./core.c On some of the longer lines above I took the liberty of removing some blanks so it wouldn't line-wrap on an 80 character screen. Don't blame me if I deleted something important. And don't get the idea that I actually *use* this. But feel free to tell me what's dangerous about it. I guess it's pretty obvious that it will fail if the file name has a colon (:) in it. So if the binary was named "c:" and it dumped core, then the core dump would be named "core.c:", and the above would remove "core.c" instead of "core.c:". Whoops. But then again, I gave up using c: when I gave up using dos. But for those of you who don't want to take the chance, then how about: rm `find . -name core\* -exec file {} \; | grep "core file" | sed -e "s/: core file (Linux)$//"` Yeah. That's the ticket. OK, fire away. Tell me what I've overlooked with that one. And if you somehow manage to recursively delete every file on your system, please send me a polite message detailing your experience. :-) -hal ------------------------------ From: clark@ist.flinders.edu.au (Steven R Clark) Subject: Re: WANTED: COBOL compiler Date: Wed, 3 Nov 1993 03:01:37 GMT Reply-To: clark@ist.flinders.edu.au In article 8am@TAMUTS.TAMU.EDU, raf4482@TAMUTS.TAMU.EDU (Reid Allen Forrest) writes: >I am currently looking for a COBOL compiler in C, preferably one that already >works with Linux. However, I'll take anything, as I don't have any sort of >working code at the moment. > Thanks in advance, > Reid Forrest > raf4482@tamuts.tamu.edu > I have not seen one. I looked around quite thoroughly over the past few weeks. If a COBOL compiler/interpreter does show up, please make it known on the 'Net. If you like, put it (+ source) on sunsite/tsx-11 and fill out a lsm template for it. --- Steven R. Clark, BSc(Hons). clark@cs.flinders.edu.au <=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-|-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=> I am returning this otherwise good typing paper to you because someone has printed gibberish all over it and put your name at the top. -- English Professor, Ohio University <=-|-=> <=-|-=> <=-|-=> <=-|-=> <=-|-=> <=-|-=> <=-|-=> ------------------------------ From: vinod@cse.iitb.ernet.in (Vinod G Kulkarni) Subject: Re: What's wrong with a DOS to Linux disk access? Date: Wed, 3 Nov 1993 02:11:45 GMT Joel M. Hoffman (joel@rac3.wam.umd.edu) wrote: : You don't need anything so complicated as a filesystem driver. All : you need is the reverse of mtools. You need a program that can read : the minix FS, and read/write files on it. For example, from dos, : you'd be able to copy lcopy hda4:/tmp/myunixfile mydosfil.e. Probably : most of the code is already in the kernel. You'd just have to write : the front end. I disagree. Such a program will have limited use, and may not justify the cost of implementing one. The security issue is an issue only if there is pretty *easy* access to access/modify the linux files i.e. if I leave the machine for some time (say few hours) no one should be able to quickly come and access/modify important files within linux file system. Here at our place, the many floppy drives have physical locks. That was the only solution we found that served the purpose! So my suggestion is to go in for file-system like interface. A device driver/ TSR will be loaded on bootup, which will allow controlled access to linux file system. So you would initially 'login' giving the password. Then you use 'map' to mount required linux directories as dos drives -- much the same as in novel netware. I feel that the main advantage is in controlled access to files and programs on per user basis in DOS. And it will also open up plethora of application software for say configuration etc. etc. *********Now some happy news: ***************** A friend of mine is trying to develop a NFS client for DOS as part of his undergraduate project. He has already implemented many dos file system calls so that the C: drive can also be accessed as other F:, G: etc. drives, with their default working directories. The project will take on a full swing in December vacation. Though the above said functionality is a deviation, he will be happy to offer the code for dos side of filesystem interface. Someone can then use this code + linux kernel code for filesystem to give the above said functionality in pretty less amount of time. Vinod. ======================================================================== Vinod G Kulkarni Research scholar, Indian vinod@cse.iitb.ernet.in Institute of Technology, My favourite sign: [ ] Bombay, INDIA. ------------------------------ From: jminnich@marlin.ssnet.com (J. Minnich) Crossposted-To: comp.os.mach,comp.os.os2.programmer.misc,comp.os.minix,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.development,comp.os.386bsd.bugs,comp.os.386bsd.apps,comp.os.386bsd.questions,comp.os.386bsd.misc Subject: Re: WILL ???BSD DIE? Date: 3 Nov 1993 00:47:22 -0500 Why Jusus, rumor has it you are on a sobatical at a russian orthadox monastary in Codiac Island Alaska with a bunch of other men wearing casics. Did you take your portable with you just to tantalize the rest of us that have a purpose in life. The bishop would shun you if he knew what you were doing with your pc that was bought with diocesan funds. Do us all a favor - take your bible, make like a spruce tree and save your sunday sermon for the masses in Codiac. After a few trips to the pulpit your congregation will fasten you to a cross on the island with some standard press steel airplane bolts. Then you would be completely brain dead. Peace be with you. ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************