From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Fri, 8 Oct 93 13:13:12 EDT Subject: Linux-Development Digest #149 Linux-Development Digest #149, Volume #1 Fri, 8 Oct 93 13:13:12 EDT Contents: Re: Page fault (Peter Andersson) Re: CFC/CFI: XSysadmin (Brandon S. Allbery) Re: >Re: Linux Slowly Dying Off? (System Operator) Re: Linux Slowly Dying Off? + Lets make a game for Linux (John R. Campbell) Re: GCC and structure field alignment (George Grimes) Re: CFC/CFI: XSysadmin (Alan Cox) Re: debuggers & core inspectors (Karel Kubat) Linux and PCI-Board (Heiko Krupp) Re: CFC/CFI: XSysadmin (Malcolm Beattie) Re: Linux Slowly Dying Off? + Lets make a game for Linux (Thomas Boutell) How do you install/config uucp? (Eric Kimminau) [q:] cap for linux, problems with ethertalkaddr (Topic-Administrator for tcl (Bernd Kratz)) ---------------------------------------------------------------------------- From: pand@kullmar.se (Peter Andersson) Subject: Re: Page fault Date: Fri, 8 Oct 1993 09:25:06 GMT gt8134b@prism.gatech.EDU (Howlin' Bob) writes: >In <1993Oct6.233556.4030@kullmar.se> pand@kullmar.se (Peter Andersson) writes: >> I'm currently writing a program that needs the page fault >> handler (SIGSYSV) to obtain some speed. But the program needs >Okay, that's strike one. SIGSEGV is the "Segmentation Violation" >signal, meaning you poked your nose where it doesn't belong. Not necessarily, I use the mmap() function to map a page of memory to another place and then I sets the R/W protection it. What I need is to let my program handle the causing SIGSYSV as this: 1 - change the protection of the page to allow read & write 2 - single step the instruction who caused the SIGSYSV 3 - change the protection back Got any idea how to handle this? >This isn't necessarily a page fault; it could be a literal >segment violation (limit or permissions, like writing to CS). >If you dereference NULL in a QMAGIC binary, or write to memory >outside your brk, *then* it'll be caused by a page fault, but >it won't be a page fault handler. Page faults are serviced by >the kernel, with no intervention from the user process. (Seems like I have to patch the kernel :( ) >> some extra data like where it was trying to write or read and >> if it is possible, set the single step trap. >If you were in the kernel, you would read CR2. Since you're not, >it's not a valid question. But how does gdb handle it? It is able to single step one instruction! - Peter Andersson, pand@kullmar.se - Sweden (so don't ask me where to find ^^^^^^ cheap computer equipment! =) ------------------------------ Crossposted-To: comp.os.linux,comp.os.linux.admin From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: CFC/CFI: XSysadmin Date: Fri, 8 Oct 1993 02:06:58 GMT In article <291fir$efd@peanuts.informatik.uni-tuebingen.de> will@peanuts.informatik.uni-tuebingen.de writes: >While xview is nice, I think OI is much more real >ObjectOriented - and it is more easy to provide two userinterfaces >using the same functionalitycode with true objects... XView's UIC library is an object-oriented C++ interface to XView, if you prefer that to the C interface. Always remember that XView has one major advantage over OI: it's freely available, so it can be used on more systems than just Linux for Intel. (Of course, whether the *BSD folks want anything to do with this is another issue entirely...) Moreover, since the source is available, you have something to work from other than a reference manual when developing a character-mode version that uses the same API and equivalent semantics. My own vote would probably be for Tcl/Tk, with a curses-based Tk replacement for character mode terminals. I think John Ousterhout commented on the possibility of such a Tk alternative being in a future Tk release --- but we would probably have to roll our own rather than waiting. Still, Tk is freely available source, so it's a lot easier than cloning OI's functionality would be. ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ Subject: Re: >Re: Linux Slowly Dying Off? From: system@byteme.UUCP (System Operator) Date: Thu, 07 Oct 93 07:36:37 EDT gareth@gblinux.demon.co.uk (Gareth Bult) writes: > On 4 Oct 1993 21:53:16 GMT; > ----Kelly Murray (kem@prl.ufl.edu) said: > > >It would only benefit naive end-users, who are seen by many Linux people as > >a lower form of life. > > naive end-users are a form of life? > > ;) 'naive end-user' is redundant! system@byteme.UUCP (System Operator) Byte Mechanix Enterprises +1 404 962 2510 ------------------------------ From: soup@penrij.UUCP (John R. Campbell) Subject: Re: Linux Slowly Dying Off? + Lets make a game for Linux Date: 6 Oct 93 21:35:10 GMT boutell@netcom.com (Humble Pie) writes: >soup@penrij.UUCP (John R. Campbell) writes: >>What I find amusing is that MS-Windoze has only proven itself as a game >>program and screen-saver environment. Why worry about *real* applications? >>Most people only run MineSweeper and/or Solitaire... >REALITY CHECK: >Excel >Word for Windows >Ami Pro >Pagemaker... >Etc etc etc etc etc etc etc. Yeah, right. How many people actually USE these versus the copies used to run solitaire or other Windoze-based games??? True, we've got one guy at the office who uses TinyTerm to drive several "terminals". Of course, I run Linux w/ X-Windows & xterm/rlogin/telnets with 80x40 windows (on a 17" monitor). Sure beats the Windoze turkey; I can actually do something useful locally (running 3 local xterms and two rlogins (or more) to 2 different systems. -- John R. Campbell soup%penrij@kd3bj.ampr.org or: uunet!kd3bj!penrij!soup ------------------------------ From: grimes@netcom.com (George Grimes) Subject: Re: GCC and structure field alignment Date: Fri, 8 Oct 1993 13:46:37 GMT In article <292cuk$gmo@vixen.cso.uiuc.edu> bazyar@mrcnext.cso.uiuc.edu (Jawaid Bazyar) writes: >wirzeniu@cs.Helsinki.FI (Lars Wirzenius) writes: > >>bazyar@mrcnext.cso.uiuc.edu (Jawaid Bazyar) writes: > >>> This wouldn't be a big deal if THE GCC MANPAGE LISTED THE 80X86 OPTIONS >>> FOR GCC!! > >>That might be nice; however, the man page for gcc is updated sporadically >>so you should check out the info docs instead. > > Info docs? > >>(When you learn of the 80x86 options, please fix the man page and >>distribute it; else you're a hypocrit for complaining that other >>people don't fix problems in documentation.) > > Um. It's not my compiler :) I maintain excellent docs on all my software >(well, I have to, being a commercial developer). Linux's main lack is >professional documentation. > Sure it's your compiler--all the GNU work is done by volunteers. Fixing the man page and sharing it is in keeping with the spirit of GNU but complaining about it is not. If you are not willing to do your part to help make GCC better, then go spend the dollars required for a commercial compiler. Then you'll have the right to complain. George ------------------------------ From: iiitac@swan.pyr (Alan Cox) Subject: Re: CFC/CFI: XSysadmin Date: Fri, 8 Oct 1993 12:45:21 GMT In article <9328104.25388@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes: >It's for things just like this that I wrote a patch for Linux >to implement secure setuid shell scripts. The `tclsh' shell doesn't Yes I saw the patch, if there was a secure shell of some sort for Linux it would be quite nice. As I read your patch it had the BSD link race problem if you were persistent enough. Still it can be done. >appear to have any security problems (although I've only read the man >page, not the source), so secure tcl programs don't sound too hard >to me. [I don't have enough experience with tk to comment about the >security of tk programs.] The problem with tcl/tk is that you can in general pop up a window and chat to any running tcl/tk application at command level. Its a brilliant debugging feature _BUT_..... Alan iiitac@pyr.swan.ac.uk ------------------------------ From: karel@icce.rug.nl (Karel Kubat) Subject: Re: debuggers & core inspectors Date: Fri, 8 Oct 1993 14:01:59 GMT Hi: About the Duel interface to gdb. It sounds pretty good, but I have 2 questions: (1) Does it debug C++ programs as well? Since gdb handles C++ programs the same way as C, I guess that should be no problem. (2) Are the and keys supported in the same way as in gdb? Especially since in C++ name magling occurs, these keys make gdb pretty handy. E.g., you may want to set a breakpoint in a function init() which is part of a class Demo: break Demo::init - that won't do, the names are mangled break init - gdb might complete the name to, e.g., init__6cDemo or whatever mangled name break init - gdb will print all function names which start with init, including that init__6cDemo or whatever. I've found that when debugging C++, name completion is *very* handy indeed. Karel. -- The ICCE usenet account providing access to usenet news for the ICCE Experience _WERKEN_AAN_DE_GRENZEN_VAN_HET_KUNNEN_ ------------------------------ From: krupp@unix-ag.uni-kl.de (Heiko Krupp) Subject: Linux and PCI-Board Date: Fri, 8 Oct 1993 14:12:24 GMT Hi folks... about 1 week ago I posted an article about Linux and PCI-Boards...no answer! BUT! today I had a chance to test Linux on a PCI-Board myselfe. And the best: It seems to work. I couldn't do much testing for they didn't allow me to remove DOS from their HD. The board I tested was an ECS board with integrated NCR5381 SCSI-II chip, integrated IDE, 2.88MB floppy and serial, parallel. The graphicscard was a normal ET4000 for ISA-Bus. We used a 0.99pl13 Kernel with the scsi-patch but the NCR 5380 support didn't work. No SCSI-Device was detected. The IDE-Harddrive worked fine, we could mount the dos-fs and have a look on it. The ISA-Bus subsystem of the PCI-Bus seems to work fine, we had no problem with the ET4000 card. There's just the need of a SCSI driver for this NCR5381 chip and maybe the PCI-Graphicscard (we couldn't test). We'll have a look on a ATI-Mach32 card for PCI when it's available. So give PCI a chance...my next board will be a PCI-Board :) Heiko Krupp. ------------------------------ From: mbeattie@black.ox.ac.uk (Malcolm Beattie) Subject: Re: CFC/CFI: XSysadmin Date: Fri, 8 Oct 1993 14:24:55 GMT In article <9328104.25388@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes: >iiitac@swan.pyr (Alan Cox) writes: > >>zmbenhal@netcom.com (Zeyd M. Ben-Halim) writes: >> >>>How about tcl/Tk? >> >>What about the security issues. Setuid functions within a tcl/tk program >>are a bit tricky. > >It's for things just like this that I wrote a patch for Linux >to implement secure setuid shell scripts. The `tclsh' shell doesn't >appear to have any security problems (although I've only read the man >page, not the source), so secure tcl programs don't sound too hard >to me. [I don't have enough experience with tk to comment about the >security of tk programs.] The potential problem with tk is that any tk application on a display can send any other tk application on that display an arbitrary command which will then be executed in the target application's interpreter and the result returned. That command can be an exec to execute any external command, unless the target application's interpreter has been secured carefully. This is a marvellous feature for ordinary tk applications but a potential security hole for suid/sgid tk applications, unless the relevant interpreter and the X display itself are carefully secured. --Malcolm -- Malcolm Beattie | I'm not a kernel hacker Oxford University Computing Services | I'm a kernel hacker's mate 13 Banbury Road, Oxford, OX2 6NN (U.K.) | And I'm only hacking kernels Tel: +44 865 273232 Fax: +44 865 273275 | 'Cos the kernel hacker's late ------------------------------ From: boutell@netcom.com (Thomas Boutell) Subject: Re: Linux Slowly Dying Off? + Lets make a game for Linux Date: Fri, 8 Oct 1993 14:59:15 GMT soup@penrij.UUCP (John R. Campbell) writes: >boutell@netcom.com (Humble Pie) writes: >>REALITY CHECK: > >>Excel >>Word for Windows >>Ami Pro >>Pagemaker... > >Yeah, right. > >How many people actually USE these versus the copies used to run solitaire >or other Windoze-based games??? { Description of people using their PCs to contact remote systems deleted } Sigh. I knew there was a reason I tried to give up followups. Yes, there are many places where PCs are used to contact the net and for not much else, and in those places if Windows is going to be used for anything it's probably going to be Solitaire, After Dark, etc. Sure, I've seen these places. But believe it or not, there are people who have to get work done on their PCs. People who crunch words and numbers under Windows for a living, and to whom operating systems are not nifty toys. People who (SHUDDER! GASP!) aren't on the net. OK, I know what you'll say to this one: "THEN HOW COME NONE OF THEM HAVE POSTED AND SAID SO?" (: -T -- i'll be under the floorboards with my face in the sun ------------------------------ From: ekimmina@pms709.pms.ford.com (Eric Kimminau) Subject: How do you install/config uucp? Date: 8 Oct 1993 15:35:06 GMT I have never installed uucp on ANY machine. Where would I find the steps to show me how this is done for Linux? Does anyone have a sample of their config files I could get my hands on? Also, where can I get a copy of the SLiP kernel patch? Thanks! -- Eric Kimminau Workstation Systems Department 313-322-3431 Product & Manufacturing Systems ekimmina@pms709.pms.ford.com Ford Motor Co. Planning and Implementation "Not an official Ford Spokesperson" ------------------------------ From: tam-tcl@hrz-ws26.hrz.uni-kassel.de (Topic-Administrator for tcl (Bernd Kratz)) Subject: [q:] cap for linux, problems with ethertalkaddr Date: Fri, 8 Oct 1993 16:34:42 GMT CAP for linux vers.0.1 (Fri Oct 8 08:27:54 1993) Please send bug-reports to me, or on the linux-net mailling-list. (sorry, got no news :-( ) Email: ben@ws-01.iset.kassel.de Hello , this is CAP for linux 0.99pl12. It's on: nic.funet.fi linux/incomming This port is based on CAP60pl154. I changed the Configure-script and some files in lib/xxx/, so that the most of CAP compile under linux. This port should support IPTalk, based on Appletalk protocols encapsulated in UDP/IP packets (sorry, no chance to test it, because got no apple-bridge). Please test it, and send me a bug-report. Native EtherTalk,UAB or Kernel AppleTalk is NOT yet implemented ! Linux propably doesn't support the necessay kernel-functions (yet). See below , there's the error-list , if i tried to compile aaprd using Native EtherTalk, and the error-list for the UAB-stuff. Maybe, there's someone who could help me. There's still a lot of work, e.g. in this version CAP does not use the sysv-ipc of linux (CAP seems to emulate a bsd-ipc. (sendmsg & rcvmsg vs.msgsnd & msgrcv) Installation: Just run 'Configure', it should detect linux as OS. (uname should return the string 'Linux' (take care of the 'L')). (look at the Configure-script) The answers about UAB, Native EtherTalk are ignored. (You can try to compile it manualy, just go into support/ethertalk and run 'make aarpd' or in support/uab run 'make uab') After compilation, follow the install-notes in (doc/). ERRORLIST : ERRORLIST for ethertalk: (aarpd) In file included from /usr/include/rpc/types.h:55, from aarpd.c:29: /usr/include/stdlib.h:353: redefinition of `struct qelem' aarpd.c: In function `main': aarpd.c:193: `IPPROTO_UDP' undeclared (first use this function) aarpd.c:193: (Each undeclared identifier is reported only once aarpd.c:193: for each function it appears in.) aarpd.c:204: `IPPROTO_TCP' undeclared (first use this function) aarpd.c: At top level: aarpd.c:462: warning: `svc_listener' was declared `extern' and later `static' make: *** [aarpd.o] Error 1 make: Target `aarpd' not remade because of errors. The errors of 'undeclared IPPROTO_TCP & IPPROTO_UDP' are fixed in the next release of CAP for linux. ERRORLIST for UAB: (the most warnings are removed ) In file included from aarp.c:49: aarp_defs.h:36: warning: garbage at end of `#ifndef' argument aarp.c: In function `aarp_listener': aarp.c:594: storage size of `arp' isn't known aarp.c: At top level: aarp.c:698: field `aaph_arp' has incomplete type aarp.c: In function `probe_and_request_driver': aarp.c:861: sizeof applied to an incomplete type aarp.c: In function `aarp_reply': aarp.c:930: dereferencing pointer to incomplete type : : : aarp.c:947: dereferencing pointer to incomplete type make: *** [aarp.o] Error 1 kip_mpx.c: In function `kips_ahoy': kip_mpx.c:297: warning: passing arg 2 of `bind' from incompatible pointer type kip_mpx.c: In function `kip_grab': kip_mpx.c:345: warning: passing arg 2 of `bind' from incompatible pointer type asyncatalk.c: In function `asyncatalk_init': asyncatalk.c:195: too many arguments to function `socket' asyncatalk.c: In function `start_listener': asyncatalk.c:254: warning: passing arg 2 of `bind' from incompatible pointer type asyncatalk.c: In function `async_listener': asyncatalk.c:311: warning: passing arg 5 of `recvfrom' from incompatible pointer type asyncatalk.c:356: warning: passing arg 5 of `sendto' from incompatible pointer type asyncatalk.c: In function `asyncatalk_send_ddp': asyncatalk.c:443: warning: passing arg 5 of `sendto' from incompatible pointer type make: *** [asyncatalk.o] Error 1 make: Target `all' not remade because of errors. I thing this is one of the main problems: There are some struct's, that aren't implemented in linux. Excerpt from support/uab/aarpd_Defs.h: /* An ethertalk node address (should probably merge with aarptab) */ typedef struct aarp_entry { struct ethertalkaddr aae_pa; /* protocol address */ ^^^^^^^^^^^^^ (not in linux ) int aae_flags; /* flags */ #define AARP_OKAY 0x1 /* resolved */ #define AARP_RESOLVING 0x2 /* trying to resolve this */ #define AARP_PERM 0x4 /* permanent (not used) */ #define AARP_FNAME_OKAY(f) ((f&AARP_OKAY) ? "okay " : "") #define AARP_FNAME_RESOLVING(f) ((f&AARP_RESOLVING) ? "resolving " : "") #define AARP_FNAME_PERM(f) ((f&AARP_PERM) ? "perm " : "") u_char aae_eaddr[EHRD]; /* hardware address */ int aae_ttl; /* time to live */ int aae_used; /* # of times used */ struct aarp_entry *aae_next; /* next in list of all */ caddr_t aae_aarptab; /* back pointer */ } AARP_ENTRY; the other is, what else is nesessary to get UAB or Native EtherTalk to run ? Please send me a mail. Email: ben@ws-01.iset.kassel.de ------------------------------ ** 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 ******************************