From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Thu, 21 Oct 93 17:13:16 EDT Subject: Linux-Development Digest #178 Linux-Development Digest #178, Volume #1 Thu, 21 Oct 93 17:13:16 EDT Contents: Re: PATH_MAX and malloc.h (Linus Torvalds) NIS ? (Benny Holmgren) SCSI-ADA-2742T (Ralf.Schroers@gmd.de) ugly name for core dumps (core.imagename) -> patch for "img.core" (Harald Koenig) Re: UNIX trademark now X/Open (Don Holzworth) __setjmp not found (Simon Johnston) Need help with boot block question (Jonathan Shapiro) Andrew File System (Jim Howard) Re: GCC 2.4.5.... how do I compile the !@#$ thing? (Eckehard Stolz) Re: UNIX trademark now X/Open (Andy McFadden) Re: PATH_MAX and malloc.h (Eckehard Stolz) Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (Rick Frankel) Wanted: volunteer for C-Browser-project (Eckehard Stolz) Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (Rick Frankel) Kernel Comiling (Miriam Graff (LAW)) ---------------------------------------------------------------------------- From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Subject: Re: PATH_MAX and malloc.h Date: 21 Oct 1993 10:19:23 +0200 In article , Jay Lawrence wrote: > >Then I also go NET2debugged, and noticed that there was 1.21BETA, went >to make kernel but it called for malloc.h, which aswell, I don't have. Get the newest kernel if you want to play with this one: it can be found on nic.funet.fi: pub/OS/Linux/PEOPLE/Linus. As of now, the latest version is ALPHA-pl13h.tar.gz, and contains (among other things) the latest NET2debugged stuff and some other patches. It's reportedly slower on networking than before, but hopefully stable. The ALPHA-pl13h kernel should also fix one long-standing problem where the machine hangs when swapping heavily under some circumstances. It seems the buffer cache simply ran out of buffers and everything waited for more buffers to magically appear. As it happened, this miracle never does occur, so everything just grinds to a halt. Note that there aren't any patches for the newer kernels: I did some source tree re-organizations which will make patching rather uncomfortable. Thus only full sources until after pl14. Linus ------------------------------ From: tdi9110@abacus.hgs.se (Benny Holmgren) Subject: NIS ? Date: 21 Oct 1993 09:58:23 GMT Reply-To: tdi9110@abacus.hgs.se Hello From what I've heard, there's a development of NIS going on out there somewhere. If so, does anyone know who's working on it and how's it going. I'd like some status info on the project. Thanks.. -- -- -- -- Benny Holmgren Skogsgl{ntan 14 Astrakan Computer Club 812 31 Storvik bigfoot@astrakan.hgs.se Sweden tdi9110@abacus.hgs.se tel. +46-(0)290-10911 ------------------------------ From: Ralf.Schroers@gmd.de Subject: SCSI-ADA-2742T Date: Thu, 21 Oct 1993 09:28:59 GMT Hi! I have an ADAPTEC 2742T SCSI-Controller. I saw in HOW-TO-SCSI that this Controller is not supported by Linux. My question is: is there any possibility are hack known to use Linux mith this Controller. Many thanks. ralf.schroers@gmd.de ------------------------------ From: koenig@nova.tat.physik.uni-tuebingen.de (Harald Koenig) Subject: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: 21 Oct 93 13:05:18 GMT Hi, I find it's a good idea to get "named" core dumps for each image but the current naming convention in pl13 isn't that good since - you can't find and remove all core.* files (some people call source files core.c or core.h - it could crash your source if you have an image called 'c' with a source module called 'core.c' :-) whats amout using 'core' as file name extension (isn't used yet), so finding *.core sould be more secure and collisions with soures wouldn't occur (if your file system supports enough characters in file names for imagename.core). here my quick patch as an first example Harald =============================================================================== *** linux/fs/exec.c.orig Sat Oct 16 13:48:35 1993 --- linux/fs/exec.c Sat Oct 16 14:28:45 1993 *************** *** 132,139 **** return 0; fs = get_fs(); set_fs(KERNEL_DS); ! memcpy(corefile,"core.",5); ! memcpy(corefile+5,current->comm,sizeof(current->comm)); if (open_namei(corefile,O_CREAT | 2 | O_TRUNC,0600,&inode,NULL)) { inode = NULL; goto end_coredump; --- 132,143 ---- return 0; fs = get_fs(); set_fs(KERNEL_DS); ! memcpy(corefile,current->comm,sizeof(current->comm)); ! #ifdef CORE_ON_MINIX_FS ! memcpy(corefile+(strlen(corefile)<=9?strlen(corefile):9),".core\0",6); ! #else ! memcpy(corefile+strlen(corefile),".core\0",6); ! #endif if (open_namei(corefile,O_CREAT | 2 | O_TRUNC,0600,&inode,NULL)) { inode = NULL; goto end_coredump; =============================================================================== -- Harald Koenig, Inst.f.Theoret.Astrophysik (koenig@tat.physik.uni-tuebingen.de) All SCSI disks will from now on be required to send an email notice 24 hours prior to complete hardware failure! ------------------------------ From: donh@gcx1.ssd.csd.harris.com (Don Holzworth) Subject: Re: UNIX trademark now X/Open Date: 21 Oct 1993 13:19:33 GMT Reply-To: donh@gcx1.ssd.csd.harris.com (Don Holzworth) In article , quinlan@ebony.cs.bucknell.edu (Daniel Quinlan) writes: |> >>>>> hta@uninett.no (Harald T. Alvestrand) wrote: |> |> > No such luck. |> > The X/Open consortium will charge registration fees, based on |> > turnover. Guess they won't believe a turnover of zero with tens of |> > thousands of installations..... |> |> That does not mean that we can't claim to meet the spec (if we already |> do or will eventually), just that we probably won't be calling it |> "Unix". I don't think it is something that we should worry about too |> much, especially if it will impair Linux development (real |> development, i.e. the kernel). It does mean that you cannot claim conformance to the spec if there is a verification test suite that you have not passed. Generally, these kinds of verification suites cost tens of thousands of dollars to have run. You can claim compatibility with conforming implementations, however. That compatibility is what I'd be looking at. Regards, ============================================================================== donh@travis.csd.harris.com | Don Holzworth All opinions are mine alone. | (305) 977-5563 | "I often quote myself. It adds spice to my conversation." ============================================================================== ------------------------------ From: skj@oasis.icl.co.uk (Simon Johnston) Subject: __setjmp not found Date: Thu, 21 Oct 1993 12:26:17 GMT When attempting to build a number of programs I have come accross the error Undefined symbol __setjmp (and sometimes _setjmp) I have included libc.a and libm.a but I still get the problem, gcc 2.4.5 libc 4.4.2 Any ideas ?? MODULE Sig; FROM ICL IMPORT StdDisclaimer; BEGIN (* ------------------------------------------------------------------------. |Simon K. Johnston - Development Engineer |ICL Retail Systems | |------------------------------------------------------|3/4 Willoughby Road| |Unix Mail : S.K.Johnston.bra0801@oasis.icl.co.uk |Bracknell, Berks | |Telephone : +44 (0)344 476320 Fax: +44 (0)344 476084|United Kingdom | |Internal : 7621 6320 OP Mail: S.K.Johnston@BRA0801|RG12 8TJ | `------------------------------------------------------------------------ *) END Sig. ------------------------------ From: shap@cobra.cis.upenn.edu (Jonathan Shapiro) Crossposted-To: comp.os.msdos.programmer,comp.os.386bsd.development Subject: Need help with boot block question Date: 21 Oct 93 13:33:27 GMT I'm stumped, and I'm hoping someone out there can help me out. I'm trying to build a partition boot sector for my hard disk. My boot sectos gets loaded by the master boot record and runs just fine so long as I hard-code hte cyl/sec/head to get the rest of the bootstrap from within the boot sector. But there are boot sectors that work without hard coding this info, and it's a definite advantage to avoid doing so. How can a secondary boot record learn either of the following: 1. The head/cyl/sec that it was loaded from 2. The partition number that it was loaded from The DOS call to find the boot drive doesn't help. I'm not running DOS at this point. Thanks for any help you may have to offer - if you reply by mail I'll summarize back to these groups. Jonathan ------------------------------ From: jahoward@iastate.edu (Jim Howard) Subject: Andrew File System Date: Thu, 21 Oct 1993 16:19:03 GMT Does a port or complete rewrite of the Andrew file system (AFS) exist for Linux? Is such a project possible, if it does not already exist? Is it something that people would want if it does not already exist? If it does exist, where can I find information on it (either the product, or the group working on it) ? Thanks Jim Howard -- *_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_* jahoward@iastate.edu SGI adm. ISU EE/IEEE =-=-=-= LINUX -- Have you administered a real OS today? =-=-=-= =============== IPRT/ICEMT--Black Engineering 95E--Ames Lab ================== ------------------------------ From: stolz@Informatik.TU-Muenchen.DE (Eckehard Stolz) Subject: Re: GCC 2.4.5.... how do I compile the !@#$ thing? Date: Thu, 21 Oct 1993 18:04:24 GMT In article <2a3jj8INNr2d@matt.ksu.ksu.edu>, danodom@matt.ksu.ksu.edu (Dan Odom) writes: |> GCC 2.3.3 gets upset when I try to compile GCC 2.4.5... |> |> 'Undefined symbol __obstack_newchunk' |> |> What library do I need that I don't have? Or is this a problem in one |> of the object files or the Makefile? Arrrrrrgh! |> |> Maybe 2.3.3 is just upset because I'm trying to replace it; after all, |> nobody likes to be made obsolete, least of all C compilers :-). You find a file called obstack.c (*or something like that) ! You have to type following line in the beginning: #undef __GNU_C__ (or something like this, You will find a #ifndef __GNU_C (?) later, please check for that !) The reason: GCC assumes the obstack-functions to be in the GNU library. But in Linux libc, they aren't ! With this undef, it works for me ! cu Eckehard stolz@fiffi.sta.sub.org stolz@informatik.tu-muenchen.de ------------------------------ From: fadden@uts.amdahl.com (Andy McFadden) Subject: Re: UNIX trademark now X/Open Date: 21 Oct 93 17:42:46 GMT In article hpa@nwu.edu (H. Peter Anvin) writes: >In case you don't read comp.unix.misc, Novell has transferred the >trademark UNIX to X/Open, who allows its use for any OS that follows >the X/Open spec 1170. If I'm not mistaken, the spec requires that the code be based on USL's code (somebody swung a sweet deal), and therefore to be called "UNIX" you still have to pay royalties. Other than that, it's mostly just XPG4 or SVID3 compliancy (forget which). -- fadden@uts.amdahl.com (Andy McFadden) "Our UNIX is bigger than your UNIX" [ These are my opinions, not Amdahl policies. ] ------------------------------ From: stolz@Informatik.TU-Muenchen.DE (Eckehard Stolz) Subject: Re: PATH_MAX and malloc.h Date: Thu, 21 Oct 1993 18:07:48 GMT In article , jjlawren@undergrad.math.uwaterloo.ca (Jay Lawrence) writes: |> |> Occasionally I have a program that will call for PATH_MAX. Hmmm. For |> some reason my header files are missing it. Where should I put it, what |> should it be? I have inc4.4.4 and kernel pl13. You are using Slackware, don't you ? Just change in the file: /usr/lib/gcc-lib/i486-linux/2.4.5/include/syslimits.h the line: #include_next to #include cu Eckehard stolz@informatik.tu-muenchen.de stolz@fiffi.sta.sub.org ------------------------------ From: rfrankel@us.oracle.com (Rick Frankel) Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: Thu, 21 Oct 1993 18:11:59 GMT -- rfrankel@us.oracle.com richard.frankel@amail.amdahl.com ------------------------------ From: stolz@Informatik.TU-Muenchen.DE (Eckehard Stolz) Subject: Wanted: volunteer for C-Browser-project Date: Thu, 21 Oct 1993 18:10:36 GMT Sorry for the crosspost, I realized later on, that this newsgroup might be more adequat for this posting than comp.os.linux.misc ! ########### PLEASE SEND ANSWERS TO: stolz@fiffi.sta.sub.org ################ ########### DO NOT REPLY !!!! ################ Hi ! I posted a question in this newsgroup about a C-Browser-Tool and got many answers! Thanks to all of you for you effort ! Unfortunatly, noone was really satisfactory (also the couple of mails regarding XCoral) ! So I began to write a browser-Tool for Linux. My intention is to provide a tool, which can tell me the following things: for functions: - where is it defined - which parameters does it have - which functions does it call (normal/library) - by which functions is it called itself - which global data does it use - which scope does it have - print a call-tree from this function (including/excluding functions, and special library-calls) for variables: - which Type - which scope - where is variable defined - where is it used (which function/module) - where is the type defined [...to be continued ...] This tool should be able to produce listings but should also be interactive, so you can enter a function and you get all the information shown in a window. This might be useful for analysis of unknown C-code ! How should it be done: You need a parser for C, which should be as close to the GCC as possible. Well, I took the one which is provided by GNU and patched the GCC (2.4.5) itself ! While parsing a C-File, GCC produces a Browser-File, containing the needed information in an easy-to-parse way. I've choosen a tagged ASCII-format, since it can be processed through various Un*x-tools ! What's working allready: GCC does produce this browser-file (still buggy, of course), and I have a flex-Programm called "calls", which tells me the functions, which are called by a specific function. I need people, who are willing to contribute to this project. Maybe, in a final state, it will be a kind of CASE-tool, at least for reverse-engineering unknown C-Code. I am a little short of time right now, so they might have to make most of the work by themselfs ! What is needed now are people, who are experienced in writing user-interface-programs with a lot of interacitivity. If it would be in X11, I would appreciate it too ! I am not willing to make a public release, unless there are some useful tools present ! Comments are wellcome, but if you want to contribute, you need at least 30 Meg free disk-space to compile the GCC 2.4.5 sources ! O.k., that's enough for now, please email me if you're interested. Eckehard Stolz stolz@fiffi.sta.sub.org or stolz@informatik.tu-muenchen.de ------------------------------ From: rfrankel@us.oracle.com (Rick Frankel) Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: 21 Oct 93 18:27:41 GMT (Sorry about the null prev. message, I seem to be hitting a lot of wrong keys lately :{) In article koenig@nova.tat.physik.uni-tuebingen.de (Harald Koenig) writes: koenig> I find it's a good idea to get "named" core dumps for each koenig> image but the current naming convention in pl13 isn't that koenig> good since - you can't find and remove all core.* files (some koenig> people call source files core.c or core.h I agree, I have the same problem in pl12. core.[ch] is EXTREMELY common (I think it's even in the gcc source), so it is very dangerous to search and destroy core files wiht the current implementation koenig> whats amout using 'core' as file name extension (isn't used koenig> yet), so finding *.core sould be more secure and collisions koenig> with soures wouldn't occur (if your file system supports koenig> enough characters in file names for imagename.core). Seems like a reasonable approach. rick -- rfrankel@us.oracle.com richard.frankel@amail.amdahl.com ------------------------------ From: mgraff@mailer.cc.fsu.edu (Miriam Graff (LAW)) Subject: Kernel Comiling Date: Thu, 21 Oct 1993 19:01:09 GMT Howdy all, Been doing a little kernel hacking/configuring, and I noticed this happened with my SLS <.99.12> kernel when I went to recompile it with some modififications.... Anyone else have this happen. Also, Why doesnt .9913 come with Sound support? . With the remote term, I can see that the kernel does indeed boot and operate. Errors hit in console.c. Just wondering if anyone else has had this problem... If so will it do the same under .99p13 ... Here is a neato excerpe from the compile......... ld -r -o kernel.o sched.o sys_call.o traps.o irq.o dma.o fork.o panic.o printk.o vsprintf.o sys.o module.o ksyms.o exit.o signal.o mktime.o ptrace.o ioport.o itimer.o info.o ldt.o des.o sync chr_drv gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -x c++ -m486 -c tty_io.c gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -x c++ -m486 -c console.c console.c:349: warning: initialization of signed pointer from unsigned pointer console.c: In function `void reset_terminal (int, int)': console.c:1012: warning: assignment of unsigned pointer from signed pointer console.c:1013: warning: assignment of unsigned pointer from signed pointer console.c:1014: warning: assignment of unsigned pointer from signed pointer console.c: In function `void con_write (struct tty_struct*)': console.c:1350: warning: assignment of unsigned pointer from signed pointer console.c:1352: warning: assignment of unsigned pointer from signed pointer console.c:1354: warning: assignment of unsigned pointer from signed pointer console.c:1361: warning: assignment of unsigned pointer from signed pointer console.c:1363: warning: assignment of unsigned pointer from signed pointer console.c:1365: warning: assignment of unsigned pointer from signed pointer console.c: In function `int vc_activate_cp (int, int)': console.c:1846: warning: comparison of distinct pointer types lacks a cast console.c:1847: warning: comparison of distinct pointer types lacks a cast console.c:1849: warning: assignment of unsigned pointer from signed pointer Tada! Look familar to anyone Anyway, I know most are warnings ................ Anyone had a problem with video after re-compiling/configuring the kernel? ------------------------------ ** 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 ******************************