From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Mon, 4 Oct 93 12:13:12 EDT Subject: Linux-Development Digest #141 Linux-Development Digest #141, Volume #1 Mon, 4 Oct 93 12:13:12 EDT Contents: Linux Multi-threaded? (Divya Sundaram) Re: Size of WINE (Eric Youngdale) Re: Archive 2060S Tape Drive (Theodore A. Serreyn) Re: Size of WINE (Brett Person) How does one _change_ kernel variables? (with gdb) (Frank Lofaro) Re: Macintosh UNIX port (Ian) Re: How does one _change_ kernel variables? (with gdb) (Eric Youngdale) What is up with libc 4.4.2 development? (Charles Stephens) Can an FDC 8x0 be used at IRQs > 7 (Nathan D. Lane) OI ObjectBuilder - alternatives any? (Karsten Steffens) Re: Terminals off Serial Port (Mr A. Walker) Re: /proc/self/fd/0 and << in bash 1.12 (Ian Jackson) Re: linux scheduler alternatives??? - MY IDEA (Mark Lord) DOSEMU: keyboard queue >>still<< out of sync (Joel M. Hoffman) ---------------------------------------------------------------------------- From: sundaram@egr.msu.edu (Divya Sundaram) Subject: Linux Multi-threaded? Date: 3 Oct 1993 17:27:05 GMT Hi all, Just out of curiosity, will Linux have (or does it already have) multitthreading capacity?? Divya ------------------------------ From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: Size of WINE Date: Sun, 3 Oct 1993 18:25:18 GMT In article <1993Oct2.064142.4230@bhhome.ci.net> bill@bhhome.ci.net (Bill Heiser) writes: >mantel@zippy,fnal.gov (Jaime Mantel) writes: > >>I was wondering how much disk space WINE will take up when released? > >Isn't this just a tad pre-mature, considering that the release of >WINE is 6 months to a year away? :-) It may be early, but I can say with certainty that it will not be 100Mb or anything like it :-). Anyway, there are certain obvious prerequisites - having X running on your system, and you obviously need the application that you want to run, and you need the Wine executable, but beyond that you do not really need anything else. I think right now the Wine binary runs about a couple hundred Kb stripped, but it will grow some as more and more of the required functionality is added. I cannot even estimate how large the final binary will be, of course. -Eric -- "When Gregor Samsa woke up one morning from unsettling dreams, he found himself changed in his bed into a lawyer." ------------------------------ From: tserreyn@nyx.cs.du.edu (Theodore A. Serreyn) Crossposted-To: comp.os.linux.help Subject: Re: Archive 2060S Tape Drive Date: 3 Oct 93 19:02:23 GMT Problem fixed, ended up being a broken tape in the drive. (sheepish grin) Anyone want to buy a Cipher ST150S in unknown working order ($100 obo) Ted ------------------------------ From: person@plains.NoDak.edu (Brett Person) Subject: Re: Size of WINE Date: Sun, 3 Oct 1993 20:37:28 GMT In article <1993Oct2.064142.4230@bhhome.ci.net> bill@bhhome.ci.net (Bill Heiser) writes: >mantel@zippy,fnal.gov (Jaime Mantel) writes: > >>I was wondering how much disk space WINE will take up when released? > >Isn't this just a tad pre-mature, considering that the release of >WINE is 6 months to a year away? :-) > Not true. Saw an ad for it in BYTE. it must be perfectly functional now. :-) :-) Please note the sarcasm... -- Brett Person Guest Account North Dakota State University person@plains.nodak.edu || person@plains.bitnet ------------------------------ From: ftlofaro@unlv.edu (Frank Lofaro) Subject: How does one _change_ kernel variables? (with gdb) Date: Sun, 3 Oct 93 19:29:56 GMT I've found that one can use: gdb /usr/src/linux/tools/system /dev/core to examine kernel variables (very nice feature!), but trying to set them from within gdb gives "Cannot access memory at *0x" followed by the address of the variable. It seems gdb is trying to access it directly. It couldn't use /dev/core, since all writes to that give "invalid argument". Is there any way to hack something up so that gdb accesses /dev/kmem or somesuch in order to change the kernel variables? It would be really nice for testing/debugging/hacking. Also, I tried to attach to pid 0, said ptrace: No such process. Should I hack the ptrace code in the kernel to allow attaching that process? Could that work? ------------------------------ Crossposted-To: comp.sys.mac.app,comp.sys.mac.comm,comp.sys.mac.system,comp.sys.mac.misc,comp.os.linux.misc,comp.unix.bsd Subject: Re: Macintosh UNIX port From: i899435@redgum.ucnv.edu.au (Ian) Date: 3 Oct 1993 15:51:37 GMT wade@picard.cs.wisc.edu (Wade Masshardt) writes: : If anyone has any info on either the NetBSD Macintosh port or the Linux : Macintosh port please post or email me & I will post a summary. I haven't heard anything about the Linux port for the Mac. With respect to the BSD port, an Alpha version was released in early September, 1993. It currently runs on the MacII, and MacIIcx (and possibly IIx and SE/30). There is a mailing list you can subscribe to, to find out what's happening and to discuss any problems with it. Also, anyone who is interested in helping with the programming effort can subscribe. If you want to get on the mailing list, send a message with the word help in the BODY (not the subject) to Majordomo@sun-lamp.cs.berkeley.edu. To subscribe, send a message with a line: subscribe macbsd-general It is currently at the ALPHA version. hulk.sfsu.edu is the official binary release site. (/pub/MacBSD.ALPHA) sun-lamp.cs.berkeley.edu will be the source site. (/pub/NetBSD/mac) There is a file called MacBSD.FAQ in the /pub/MacBSD.ALPHA directory at hulk that should be able to answer a whole lot more. - Ian. ------------------------------ From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: How does one _change_ kernel variables? (with gdb) Date: Mon, 4 Oct 1993 01:50:45 GMT In article <1993Oct3.192956.10845@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes: > I've found that one can use: > >gdb /usr/src/linux/tools/system /dev/core > >to examine kernel variables (very nice feature!), but trying to set them >from within gdb gives "Cannot access memory at *0x" followed by the address >of the variable. It seems gdb is trying to access it directly. It couldn't >use /dev/core, since all writes to that give "invalid argument". When I first wrote the /dev/core stuff, I never even realized that it was possible to write to a core file, so the kernel is configured to reject writes. In theory it will not be that hard to fix. Incidentally, gdb-4.10 broke the /dev/core - gdb now wants the file size to be close to the size of the various sections that are dumped. To fix this, I had to move /dev/core into /proc/core - it now appears as a regular "file" that has the size set so that gdb again correctly works. It would not be that tough to expand this so that you can write to the file as well. -Eric -- "When Gregor Samsa woke up one morning from unsettling dreams, he found himself changed in his bed into a lawyer." ------------------------------ From: cfs@neuro.emory.edu (Charles Stephens) Subject: What is up with libc 4.4.2 development? Date: 4 Oct 1993 02:18:57 GMT I know, I know, I should read the mailing lists. Let's just say I have been preserving my sanity by cutting down on the possibility of information overload. What is the current status of the libc development? I am in no rush and I owe gratitude to the midnight hackers who take time to develop it, but I have several projects that I would like to wrap up and I want to know if they are going to be released soon. Please advise anyone. I will tune into the appropriate mailing list channel so I won't ask such dumb questions in the future... -- Charles Stephens, | There is a threat to our very Assistant System Administrator, | existance. He's cold, calculating, Department of Neurology, | round, and purple. His name is Barney. Emory University |---------------------------------------- Internet: cfs@next.neuro.emory.edu | Linux, choice of a GNU generation. ------------------------------ From: nathan@seldon.foundation.tricon.com (Nathan D. Lane) Subject: Can an FDC 8x0 be used at IRQs > 7 Date: Mon, 04 Oct 1993 03:17:54 GMT I would like to know if a Future Domain TMC8xx adapter can be used at interrupts greather than the 8bit limitation of 7. I seem to have a great deal of problems with both the TMC885 and the TMC860 at interrupts greater than 7. I originally had them at 5 (both controllers), but could not format/fdisk/mkfs my SCSI HD's. Since these are 16bit IRQ capable (but not 16bit data capable) cards, I wanted to move them out of the lower IRQs to make room for my sound card. Since the move, I always get ""SCSI1: unexpected interrupt". I modified "st??.c" to set the IRQ to 11. I also note that my SCSI CD/Tape drive work at IRQ11, but my HD's do not work at 11 OR AT 5!! Should I just ditch the darned TMC8xx and go to the TMC16xx? Both adapters work fine in an Esix SVr4 machine with 2.0GB of disk (three drives). Finally, there was a post on de.comp.os.linux mentioning his problem with a TMC885 that was exactly like mine got a timeout on all HD's, but the CD and Tape drives worked just fine. Thank you for any information [Crossposted via my translator (my wife) to de.comp.os.linux). Nathan D. Lane, MIS Analyst and VP of Triicon Systems, Inc. Santa Barbara, CA (805) 9636555; email: nathan@seldon.foundation.tricon.com Making the Title Insurance World an Easier Place! ------------------------------ From: karsten@kshome.ruhr.de (Karsten Steffens) Subject: OI ObjectBuilder - alternatives any? Date: Sun, 3 Oct 1993 17:47:21 GMT Hello fellow Linux-developpers, although it is absolutely nice from ParcPlace to "donate" their Object Builder OI to us linuxers, where they are still selling it for $3000 to users of "real" ;-) workstations, using it is quite difficult on a machine equipped with 8MB only. OI together with the User Interface Builder has some quite interesting features, for instance Motif and Open Look compatability withing the same prototyper. I like it very much, but I really cannot stand the sluggishness of my machine due to the lack of memory. So, my question is: Are there any GUI prototypers available on the net FOR FREE, which need 8MB to work at reasonable speed, and which allow to develop for Athena Widgets, Open Look (XView) and for Motif, not necessary bundled everything in a single application. Thanks a lot, best regards, and THANK YOU VERY MUCH at ParcPlace! When the time comes that I can afford a memory upgrade I probably come back to your product. Its great, and its a great idea of you to spread it in the public. Regards, Karsten -- ==================> Karsten Steffens <===================== karsten@kshome.ruhr.de | steffens@ikp.uni-muenster.de Marl - close to Recklinghausen | Institut fuer Kernphysik North of the Ruhrgebiet | Westf.Wilhelms-Universitaet Muenster ------------------------------ From: junaid@nella02.cc.monash.edu.au (Mr A. Walker) Subject: Re: Terminals off Serial Port Date: Mon, 4 Oct 1993 09:01:08 GMT imcclogh@cs.ucsd.edu (Ian McCloghrie) writes: >kunze@informatik.uni-hannover.de (Richard Kunze) writes: >>In article 18138@pat.uwe.ac.uk, mj_smith@onion.uwe.ac.uk ([Mark Smith]) writes: >>> Does anybody know how to, or know of a program that will enable me to plug >>> a dumb terminal (or my friends Linux running PC) into the serial or any >>> other port (I don't have and cannot afford a network card) of my machine, >>> and have it work as a terminal, (just VT100 or some such not X) >>Just plug it in and start getty on that port. > You can also run SLIP over a serial port, with no more hardware >than is necessary for a terminal. It's somewhat trickier to set up, but >not excessively so. Or, if both systems are using linux, and you've got >a spare parallel port on each machine, you could use PLIP with around >$10-$20 worth of hardware, probably. How does one wire up a suitable parallel port cable? ------------------------------ From: iwj10@cus.cam.ac.uk (Ian Jackson) Subject: Re: /proc/self/fd/0 and << in bash 1.12 Date: Sun, 3 Oct 1993 16:06:54 GMT In article <288spv$1gh@smurf.sub.org>, Matthias Urlichs wrote: >In comp.os.linux.misc, article <1993Sep12.162123.7386.chiark.ijackson@nyx.cs.du.edu>, > iwj10@cus.cam.ac.uk (Ian Jackson) writes: >> >> The files in /proc/.../fd inherit the permissions of the file being >> referred to, rather than the mode of the open file descriptor. >> >> User `fred' runs a setuid-`wizard' program, which opens a read-only >> file descriptor (5, say) onto a file bar/foo, like this: >> drwx------ wizard magic bar/ >> -rw-rw-rw- wizard magic bar/foo >> The setuid program then does setuid(getuid()) a couple of times and >> execs a shell, or a program of fred's choosing. This is usually OK >> as the access to the file is limited by the mode of the open file, >> which can't be changed. However fred can now go into /proc/self/fd >> and open `5' for writing, thus obliterating the contents of foo. >> >You don't even have to open a shell; just grab the file from another window. Err, good point. That's even worse, in fact. See below. >> The solution is to make the access of /proc/*/fd/* depend on the open >> mode of the file descriptor. I'm not quite sure how to implement >> this, though - it seems to violate the VFS layering somewhat. >> >No. The process could be setuid to wizard while entering the directory, then >revert back to stupiduser before opening the file. I was considering the situation where the setuid program was *intending* to pass a read-only filedescriptor onto a program subsequently run as `fred'. Currently that breaks, because fred can use /proc/*/fd to `upgrade' his access to the file. However you have spotted a hole that's much more likely to be a problem - even if the suid program doesn't ever do exec, it only has to open a file for it to become accessible to fred in /proc. >A general solution would have to use ACLs (access control lists). >You'd have to attach an intersection of X's file permissions and all ACLs of >directories you traverse to get to file X, to /proc/fd/.../X. No, I don't think so. In any case that would be clunky and impractical and could lead to `creeping access loss' (during eg cd private; cd ..) How about the following solutions: 1. For the hole that I originally described, the access of the filedescriptor file in /proc is the access of the filedescriptor in question. After all, this is exactly the access that could be gained by attaching the process under a debugger. 2. Make the directory in /proc have the same access conditions as are required to do a trace attach on the process. In fact, looking at the code in ptrace.c suggests that there is another hole lurking there. You can ptrace a process that was setuid but has relinquished it and have it reassert its setuidness via the saved-set-userid. Obviously you should not be able to trace a process whose saved-setuid and saved-setgid are not your own uid and gid. Perhaps the check should only be made against the saved-setuid and saved-setgid ? After all if your uid is the same as that of the file you could rewrite it to do what you wanted and wait for the luser to run it again. It might also be useful to be able to debug a program while it was running setuid, but obviously only if you're the author rather than the user. >Meanwhile, I've thought about this for an hour or so now and there indeed >doesn't seem to be a clean and secure solution. :-( The best I've come up >with is to disable access by other processes to any file descriptor which was >opened when uid != suid (saved effective UID). That's messy. I'd suggest disallowing tracing of and access by processes to the setuid program, until it has relinquished the saved setuid. When it has done so - for example by doing setuid(getuid()) twice - the author was clearly intending to start to run an unpriveliged bit of code, usually exec or something. This has the advantage of not needing a silly new bit in the file flags :-). >If that check is disabled when accessing your own file descriptors, i.e. >/proc/self, then any use by shells etc. would not be affected. Ahm. I was suggesting changing the mode on /proc/* so that you can only access a process if its suid is your [er]uid (whichever). However there is an obvious problem here that /proc/self becomes inaccessible to a setuid program ! Perhaps /proc/self should be mode 555. However you *still* need to limit access to /proc/*/fd/* to the access level of the filedescriptor in question. >I'll implement some patches. I hope I've replied to this in time to stop you wasting effort - I was away for a week or two. PS I have removed the crosspost to comp.os.linux.misc. -- Ian Jackson, at home or PGP2 public key available on server. Urgent email: 2 Lexington Close, Cambridge, CB4 3LS, England; phone: +44 223 64238 ------------------------------ From: mlord@bnr.ca (Mark Lord) Subject: Re: linux scheduler alternatives??? - MY IDEA Date: Fri, 1 Oct 93 15:28:29 GMT In article <28gron$f27@moonshot.west.oic.com> dillon@moonshot.west.oic.com writes: > > I have some ideas re: scheduling. Specifically, the scheduler I did > for a recent embedded OS. [much of description deleted] > > task->counter = task->counter - sum_pri > > when the counter goes negative you switch to the next task. Note that > YOU LEAVE THE COUNTER NEGATIVE! You do not zero it. > > When you switch in the next task in the run queue you perform the > following calculation: > > task->counter = task->counter + (task->pri * CONSTANT) > What happens on voluntary pre-emption? Where a task does not use all of its timeslice before voluntarily performing a wait of some kind? Inquiring minds want to know! I suppose this breaks down into two possibilities: (a) the process is waiting, so is moved off of the run queue, and it's timeslice is reset as normal when it eventually becomes ready again. (b) the process just wants to run the scheduler, without waiting for anything, for the sake of doing some kind of internal polling in the style of a FAST wait as you described.. so handling is just as per fast wait. By now I've probably answered my own question, in an incomprehensible manner. -- mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482 ------------------------------ From: joel@rac4.wam.umd.edu (Joel M. Hoffman) Subject: DOSEMU: keyboard queue >>still<< out of sync Date: Mon, 4 Oct 1993 15:20:05 GMT I have the latest public release of dosmeu, with the (three or so) patches applied, but I find that the keyboard queue STILL gets of of sync sometimes. That is, sometimes dosemu doesn't register one key until I type the next. (For example, I'll press ENTER, but ENTER won't be recorded until I press any other key, including, BTW, SHIFT.) More strikingly, if I then exit dosemu, when I next try to login on the same VC, the login fails. (I run dosemu by logging in as dos.) So I'm wondering if the bug isn't in dosemu, but somewhere else, and is manifesting itself when I try to login again. Any thoughts? -Joel (joel@wam.umd.edu) -- ============================================================================= |_|~~ Germany, Europe. 1943. "The diameter of the bomb was 30 centimeters, __|~| 16 Million DEAD. and the diameter of its destruction, about 7 meters, and in it four killed and 11 wounded. cnc Bosnia, Europe. 1993. And around these, in a larger circle of pain cnc HOW MANY MORE? and time, are scattered two hospitals and one cemetery. But the young woman who was buried in the place from where she came, at a distance of more than than 100 kilometers, enlarges the circle considerably. And the lonely man who is mourning her death in a distant country incorporates into the circle the whole world. And I won't speak of the cry of the orphans that reaches God's chair and from there makes the circle endless and godless." ============================================================================= Tell Clinton to stop the genocide: president@whitehouse.gov ------------------------------ ** 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 ******************************