Subject: Linux-Development Digest #571 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Tue, 22 Mar 94 07:13:05 EST Linux-Development Digest #571, Volume #1 Tue, 22 Mar 94 07:13:05 EST Contents: Pipe failure, open files (Jon Freivald) Re: VM performance tuning via program restructuring (Peter Desnoyers) Re: Specialix Driver Round 2 (From specialix) (Craig Milo Rogers) xterm for Xaw3d patch [XFree86 2.1] (Satoshi ASAMI) Re: Adpatec 2842 SCSI Driver .. (Tseng Yaw-yih) IPX (NetWare) routing. (Chris D. Johnston) Can two programs read or write from /dev/dsp at the same time (Brandon C Long) LINUX port to a transputer system (Baranski, A.S.) Re: 486DLC support anyone? (engelbert.jgm.torremans) Re: Can two programs read or write from /dev/dsp at the same time (Hannu Savolainen) ---------------------------------------------------------------------------- From: jaf@jaflrn.Morse.Net (Jon Freivald) Subject: Pipe failure, open files Date: Tue, 22 Mar 1994 05:10:41 GMT I got a message from my Cron Daemon today -- it said I had a pipe failure due to too many open files. This brings me to asking 2 questions: 1. How many files can be open at one time? (And related, is this per process, or for the entire system?) 2. Is there anything I can do to increase this number? (Memory is not tight... 20M real, 64M virtual) Jon -- Jon Freivald ( jaf@jaflrn.Morse.Net ) PGP V2 - 22A829/40 DA 9E 8E C0 A1 59 B2 46 3B 73 81 2B 7B 83 1F Nothing is impossible for the man who doesn't have to do it. ------------------------------ From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) Subject: Re: VM performance tuning via program restructuring Date: Mon, 21 Mar 1994 18:10:00 GMT A simple method that might give more accurate information for program restructuring would be to measure the call graph transitions - i.e. how many times A calls B - by source code instrumentation. It's not as simple as turning on profiling, but it's still pretty easy to implement (write a perl script to insert counting code, then recompile) and shouldn't impact performance too badly. The advantage is that this gives you exactly the information you need to re-order your code, instead of having to infer calling frequencies from static frequency in the source code. Now, given the call frequency graph, do any of you have any good algorithms for re-ordering functions? Peter Desnoyers -- ------------------------------ From: rogers@drax.isi.edu (Craig Milo Rogers) Subject: Re: Specialix Driver Round 2 (From specialix) Date: 21 Mar 1994 10:10:28 -0800 In the following reply, I may appear a little condescending, even sarcastic. I apologize in advance. I don't really wish to offend, I simply wish to make my point obvious. Also, this is a long post, and I apologize for that, too. In article dmw@prism1.prism1.com (David Wright) writes: > I don't see that the "host side" portion of the code would be >vendor-specific in & of itself. 1) The intelligent board connects to the host system by the system I/O bus, right? 2) The system I/O bus is accessed from the host CPU via I/O instructions and/or memory-mapped I/O regions. 1) The system DMA controller might be used for some activities. 2) In some cases, an I/O board might control onoing transactions as an independent bus master. 3) These details are irrelevant. 3) Setting various bits in the I/O registers from the host (via I/O instructions or memory access instructions) causes various and wonderful things to happen in the intelligent I/O boards. 4) Since the intelligent board contain a running software program of its own, the format of the registers, and their meanings, may be time-varying in very complex, arbitrary, obscure, arcane, and wonderful ways. Here we reach the nut of the problem. Each :intelligent serial board" vendor may use a completely and arbitrarily *different* allocation (spatial and temporal) of bits on the host side of the interface, to do that vendor's various and wonderful things. There is no common convention or standard (of which I'm aware) for the hardware design, meaning of bits, temporal dependencies, etc. in these boards. Nada. Zip. Conclusion: the host-side interface is vendor-specific, in-and-of itself. For competitive reasons, at least one "intelligent serial board" vendor wishes to keep various aspects of their host-side interface a trade secret. Now, what about the host side driver software? Part of it has to load those host-side divice registers, and twiddle those host-side bits, and follow those temporal protocols, in order to accomplish the various and wonderful things of which the intelligent board is capable. Conclusion: part of the host-side driver software (code) is vendor-specific, in-and-of itself. Revealing that part of the host-side driver, as by publishing its source code, would reveal details of the host-side interface which (at least one) vendor wishes to keep a trade secret. >Granted, as there is no "generic" intelligent >host adapter "glue" code right now (that I am aware of), someone would have to >write this (which would be covered by the GPL), possibly using the standard >serial device interface code as an example (which is how you want the >intelligent card to look for IOCTL purposes anyway). There is no "generic" intelligent host adaptor "glue" code, because there is no "generic intelligent host adaptor" (of which I am aware). No standard has been established, not even a partial standard, as is found in video adaptors, sound adaptors, SCSI disk adaptors/drives, etc. Lacking adherence to a common standard, nothing is generic. Lacking adherence to a common standard, functioning (complete in itself) "generic" driver code for intelligent serial boards is not possible. We might discuss *why* there is no standard. Essentially, there is no dominent vendor (or other organization) wishing to and in an economic position to establish a standard, and the market is apparently too small for the reverse-engineering practices, that have established some de-facto industry standards, to be practical. >But that does not have >anything to do with the code that is running ON THE HOST ADAPTER. IE: If the >host adapter is using a RISC procoessor, all the Linux code is doing is acting >as a loader for the RISC code, and the RISC code would NOT be under the GPL at >all. The details for loading the on-board processor code is, quite probably, one of the major functions that the vendor(s) wish to remain a trade secret. However, you've overlooked most of the actual function of the Linux driver. It doesn't just *load* the on-board processor. It *talks* with it afterward! *How* the "Linux code" talks with tbe board is device-specific, and may be, as I have said, something a vendor wishes to remain a trade secret, too. > What would be good to have (and what we will get "de facto" when the >Specialix driver is released) is an API for talking to intelligent cards >under Linux. This would be the part that got linked into the kernel, that knew >about Linux internals, and how to write to the intelligent card on the other >side. What the intelligent card DOES with the data would still be vendor >specific, and would be running vendor-supplied binary code (either loaded >by the drive at boot time (the loader would likely have to be GPLed), or on >firmware on the card) that would NOT have to be GPLed, since it knows nothing >about Linux/Unix/DOS at all... > > CMR> If you are a latecomer to this thread, I might be able to > CMR> email you a copy of the messages that I've saved from it. > > Nope, I have the whole thing here, and saw all the various "rounds"... Ok, then please reread my post (Message-ID: <2klq36$c8p@drax.isi.edu>) on how to split an operating system device driver into two parts: an OS-specific part, which, in the case of Linux, would be GPLed and distributed with source, and a hardware-device-specific (running on the host processor, I emphasize) part, which would not be subject to the GPL, and which could be distributed in object-only format. The OS-specific part of the driver could be considered the API you described above, except that the API *wouldn't* know "how to write to the intelligent card on the other side", as doing so is specific to each vendor's device, in-and-of itself. Writing to the intelligent card would be the responsibility of the non-GPLed, object-only portion of the device driver. On the OS-dependent side, you could establish a API, such as a set of IOCTLs, to be used by user-level programs to reset the intelligent serial board's on-board processor, load a new program into the board, and other functions that are not present in a standard "dumb" serial board, but which may be reasonably expected to be common to intelligent serial boards. However, the implementation of resetting, loading, etc., the on-board processor would be part of the hardware-device-specific, non-GPLed code in the two-part driver I refer to above. Alternatively, and with all due respect to Specialix, Inc., you could simply choose to buy your intelligent board from a vendor that does *not* regard keeping trade secrets to be necessary for their competitive advantage. Craig Milo Rogers ------------------------------ From: asami@cs.berkeley.edu (Satoshi ASAMI) Crossposted-To: comp.windows.x.i386unix,comp.os.386bsd.apps Subject: xterm for Xaw3d patch [XFree86 2.1] Date: 22 Mar 94 00:17:22 (I'm not sure if this is the correct Linux group to post this, sorry if it's not.) I grabbed the xterm patch from ftp.x.org:/contrib/Xaw3d so that I can use arrow scrollbars of xterm on my just-compiled XFree86 2.1 (FreeBSD-(almost-)current, Orchid F1280+ VLB). Unfortunately, quite a bit of the source has changed and many hunks failed. The following is the result of my hand-applying of the patches. Disclaimer: I didn't bother with the version headers. I haven't tested the Tek part. The VT window looks ok. If anybody made a similar patch for kterm, please let me know. Kalib (kaleb@x.org, the author of Xaw3d) will probably like to hear that too. Satoshi P.S. Xaw3d is great! If you have Sun-style shared libraries (aka *BSD-current), all you need to do is to compile Xaw3d and make a symbolic link libXaw.so.2.0 --> libXaw3d.so.2.0 and boom! everything is 3D! --- diff -rub xterm.org/Tekproc.c xterm/Tekproc.c --- xterm.org/Tekproc.c Sun Mar 20 02:25:24 1994 +++ xterm/Tekproc.c Sun Mar 20 13:46:55 1994 @@ -151,6 +151,8 @@ extern int Tpttable[]; extern int Tspttable[]; +extern XtAppContext app_con; + static int *curstate = Talptable; static int *Tparsestate = Talptable; @@ -606,7 +608,7 @@ TekGINoff(); TCursorDown(); if (!TekRefresh && - (QLength(screen->display) > 0 || + (XtAppPending(app_con) || GetBytesAvailable (ConnectionNumber(screen->display)) > 0)) xevents(); break; @@ -726,7 +728,7 @@ Ttoggled = FALSE; } #ifndef AMOEBA - if(QLength(screen->display)) + if(XtAppPending(app_con) & XtIMXEvent) Tselect_mask = X_mask; else { XFlush(screen->display); diff -rub xterm.org/charproc.c xterm/charproc.c --- xterm.org/charproc.c Sun Mar 20 02:25:25 1994 +++ xterm/charproc.c Sun Mar 20 14:06:04 1994 @@ -68,6 +68,7 @@ extern jmp_buf VTend; +extern XtAppContext app_con; extern Widget toplevel; extern void exit(); extern char *malloc(); @@ -620,7 +621,7 @@ Index(screen, 1); if (term->flags & LINEFEED) CarriageReturn(screen); - if (QLength(screen->display) > 0 || + if (XtAppPending(app_con) || GetBytesAvailable (ConnectionNumber(screen->display)) > 0) xevents(); parsestate = groundtable; @@ -996,7 +997,7 @@ case CASE_IND: /* IND */ Index(screen, 1); - if (QLength(screen->display) > 0 || + if (XtAppPending(app_con) || GetBytesAvailable (ConnectionNumber(screen->display)) > 0) xevents(); parsestate = groundtable; @@ -1007,7 +1008,7 @@ Index(screen, 1); CarriageReturn(screen); - if (QLength(screen->display) > 0 || + if (XtAppPending(app_con) || GetBytesAvailable (ConnectionNumber(screen->display)) > 0) xevents(); parsestate = groundtable; @@ -1431,15 +1432,26 @@ XFlush(screen->display); /* always flush writes before waiting */ #ifndef AMOEBA - /* Update the masks and, unless X events are already in the queue, - wait for I/O to be possible. */ + /* + * Update the masks and, unless X events are already in the + * queue, wait for I/O to be possible. + */ select_mask = Select_mask; write_mask = ptymask(); select_timeout.tv_sec = 0; + /* + * if there's either an XEvent or an XtTimeout pending, just take + * a quick peek, i.e. timeout from the select() immediately. If + * there's nothing pending, let select() block a little while, but + * for a shorter interval than the arrow-style scrollbar timeout. + */ + if (XtAppPending(app_con)) select_timeout.tv_usec = 0; - i = select(max_plus1, (fd_set *)&select_mask, (fd_set *)&write_mask, - (fd_set *)NULL, QLength(screen->display) ? &select_timeout - : (struct timeval *) NULL); + else + select_timeout.tv_usec = 50000; + i = select(max_plus1, + (fd_set *)&select_mask, (fd_set *)&write_mask, + (fd_set *)NULL, &select_timeout); if (i < 0) { if (errno != EINTR) SysError(ERROR_SELECT); @@ -1453,7 +1465,7 @@ /* if there are X events already in our queue, it counts as being readable */ - if (QLength(screen->display) || (select_mask & X_mask)) { + if (XtAppPending(app_con) || (select_mask & X_mask)) { xevents(); } #else @@ -2552,7 +2564,6 @@ /* make sure that the resize gravity acceptable */ if ( new->misc.resizeGravity != NorthWestGravity && new->misc.resizeGravity != SouthWestGravity) { - extern XtAppContext app_con; Cardinal nparams = 1; XtAppWarningMsg(app_con, "rangeError", "resizeGravity", "XTermError", @@ -2992,7 +3003,7 @@ * (screen->max_row + 1) + 2 * screen->border, &junk, &junk); XSync(screen->display, FALSE); /* synchronize */ - if(QLength(screen->display) > 0) + if(XtAppPending(app_con)) xevents(); } CursorSet(screen, 0, 0, term->flags); diff -rub xterm.org/main.c xterm/main.c --- xterm.org/main.c Sun Mar 20 02:25:25 1994 +++ xterm/main.c Sun Mar 20 14:26:03 1994 @@ -223,6 +223,10 @@ #define ttyslot() 1 #endif /* apollo */ +#ifdef sun +#include +#endif + #ifdef UTMP #include #endif @@ -3486,15 +3490,19 @@ { #ifndef AMOEBA #ifdef FIONREAD - static long arg; + long arg; ioctl (fd, FIONREAD, (char *) &arg); return (int) arg; #else +#ifdef FIORDCK + return (ioctl (fd, FIORDCHK, NULL)); +#else struct pollfd pollfds[1]; pollfds[0].fd = fd; pollfds[0].events = POLLIN; return poll (pollfds, 1, 0); +#endif #endif #else /* diff -rub xterm.org/misc.c xterm/misc.c --- xterm.org/misc.c Sun Mar 20 02:25:26 1994 +++ xterm/misc.c Sun Mar 20 13:44:05 1994 @@ -64,21 +64,33 @@ static void DoSpecialEnterNotify(); static void DoSpecialLeaveNotify(); +extern XtAppContext app_con; + xevents() { XEvent event; + XtInputMask input_mask; register TScreen *screen = &term->screen; - extern XtAppContext app_con; if(screen->scroll_amt) FlushScroll(screen); - if (!XPending (screen->display)) - /* protect against events/errors being swallowed by us or Xlib */ + /* + * process timeouts, relying on the fact that XtAppProcessEvent + * will process the timeout and return without blockng on the + * XEvent queue. Other sources i.e. the pty are handled elsewhere + * with select(). + */ + while ((input_mask = XtAppPending(app_con)) & XtIMTimer) + XtAppProcessEvent(app_con, XtIMTimer); + /* + * If there's no XEvents, don't wait around... + */ + if ((input_mask & XtIMXEvent) != XtIMXEvent) return; do { if (waitingForTrackInfo) return; - XNextEvent (screen->display, &event); + XtAppNextEvent (app_con, &event); /* * Hack to get around problems with the toolkit throwing away * eventing during the exclusive grab of the menu popup. By @@ -104,7 +116,7 @@ (event.xany.type != ButtonPress) && (event.xany.type != ButtonRelease))) XtDispatchEvent(&event); - } while (QLength(screen->display) > 0); + } while ((input_mask = XtAppPending(app_con)) & XtIMXEvent); } @@ -322,7 +334,7 @@ the bell again? */ if(screen->bellSuppressTime) { if(screen->bellInProgress) { - if (QLength(screen->display) > 0 || + if (XtAppPending(app_con) || GetBytesAvailable (ConnectionNumber(screen->display)) > 0) xevents(); if(screen->bellInProgress) { /* even after new events? */ ------------------------------ From: u800307@Winkie.Oz.nthu.edu.tw (Tseng Yaw-yih) Subject: Re: Adpatec 2842 SCSI Driver .. Date: 22 Mar 1994 08:25:41 GMT Wolfgang Jung (wong@cs.tu-berlin.de) wrote: > Hi > == > I would like to know when there will be a SCSI Driver for the > 2842 (if at all ) > I read a message of an upcoming Driver for the 2842 about 3 1/2 Month > ago.. So I would llike to know how far the development for that > Adapter went .. > Thanks > Wolfgang > PS: I would like email. If you got the driver,please mail to me ,too. Thank you very much. u800307@Winkie.Oz.nthu.edu.tw ------------------------------ From: chris@surfcty.surfcty.com (Chris D. Johnston) Subject: IPX (NetWare) routing. Date: Tue, 22 Mar 1994 08:42:10 GMT I noticed in a recent compile session of Alan Cox's patched Net-032 kit, there seemed to be some mention of IPX/SPX packet handling. This would imply Novell NetWare packet routing. Someone responded to me earlier regarding this, but I managed to misplace that mail file. In any case, the goal is to use Linux as a router/bridge to connect two offices. Both offices use TCP/IP and IPX (NetWare). The new Net-032(cox) man pages make no mention of this. Has anyone any ideas or plans ? ? ? Chris -- =============================================================== Chris D. Johnston Surf City Software, Orange, CA 714/289-8543 chris@surfcty.com fax: 714/289-1002 ------------------------------ From: blong@dcl-nxt44 (Brandon C Long) Subject: Can two programs read or write from /dev/dsp at the same time Date: 22 Mar 1994 08:46:04 GMT I'm writing a program that reads from /dev/dsp and attempts to display the results graphically using svgalib. Currently, I can get it to work using something like a playing a CD, or if I play a mod to /dev/dsp1 (I have a PAS 16) and set the PAS to record from pcm2, it will work. But I would like it to be able to read /dev/dsp while a program like str was using it. Is this possible, can it be done with some simple modification of str, or do I have to have a tracker as part of my program in order to do this. Thanks for any help Brandon ================================================================================ > Brandon Long ][ Yeah, I blong here too. [ > Computer Engineering ][ "A man who could make so vile a pun would not [ > University of Illinois ][ scruple to pick a pocket." -- John Dennis [ > Urbana-Champaign ][ blong@uiuc.edu blong@sumter.cso.uiuc.edu (NeXT) [ ===========blong=================== The aforementioned views may not be those of this fine University. Let's just say that I would be really surprised if they were. ------------------------------ From: Antoni.Baranski@si.hhs.nl (Baranski, A.S.) Subject: LINUX port to a transputer system Reply-To: Antoni.Baranski@si.hhs.nl Date: Tue, 22 Mar 1994 08:18:17 GMT Hi World, I am a student at the Haagse HogeSchool Sector Informatica in the Hague, Holland. During my summer holliday I am planning on making a port of LINUX onto a T800 transputer subsystem which plugs into my PC. The general idea is that the PC will function as a server for the transputer system. Taking care of all the I/O routines (Harddisk, Video) and at the same time will be used as the frontend user interface for the transputer system. Running with X11 on the PC under LINUX it will be possible to open a window with linux and have a linux sub-system running on the transputer system. And using the transputer system for number crunching. I must say that I am new to LINUX and have never ported any software that realy worked after the porting. I under stand that big portions of the LINUX kernel are written in assembly, and that is a point I fear I migth get into a lot of trouble because my knowlegde of assembly isn't that great. And programming the transputer is assembly well, no thank you. So I would have to translate all the assembly into C/C++. SO, if my idea is crazy please let me know. I f you any suggestions on books that migth help in the proces of porting the linux kernel please let me know. Well actualy if you have any comment on this 'CRAZY' idea please let me know. Thanx ================================================| Baranski, A. S. | Haagse HogeSchool | E-Mail: | Sector Informatica | Antoni.Baranski@si.hhs.nl | Student Software Engineering | ================================================| DOS => Just another boot sector virus. Windows => Bigest virus code ever written. OS/2 => Works great!! ------------------------------ From: etorrem@cbnewsj.cb.att.com (engelbert.jgm.torremans) Subject: Re: 486DLC support anyone? Date: Tue, 22 Mar 1994 08:58:23 GMT From article <1994Mar19.020240.14960@mcshub.dcss.mcmaster.ca>, by abrams@maccs.mcmaster.ca (Jonathan H. Abrams): > In article , > Superuser wrote: >>cjthomas@metronet.com (Chris Thomas) writes: >>> I just popped a TI486DLC cpu into my system only to discover that there is a >>> DOS program that enables the internal cache on the chip. It works great >>> for DOS, but linux is still kind of slow. >>> Has anyone tried to add DLC support to the kernel? For that matter, does >>> anyone know how to enable the internal cache of the CPU? >> >>Grab CxPatch.tar.gz from sunsite.unc.edu in /pub/Linux/kernel/misc-patches >>(or thereabouts). >> > > Is this neccessary if I have set the internal cache enabled in the AMi > bios setting? > > Jonathan H. Abrams McMaster University > abrams@acm.org Hamilton, Ontario, Canada No, the patches are only required for motherboards and BIOS'es that are not 486DLC aware. In your case the internal cache is already enabled by the BIOS. Good luck, -- ========================================================================== | Engelbert Torremans | AT&T Network Systems Nederland | | Huizen | Email: e.torremans@att.com | | The Netherlands | My opinions are my own | ------------------------------ From: hsavolai@cs.Helsinki.FI (Hannu Savolainen) Subject: Re: Can two programs read or write from /dev/dsp at the same time Date: 22 Mar 1994 09:31:26 GMT In <2mmb8c$r1l@vixen.cso.uiuc.edu> blong@dcl-nxt44 (Brandon C Long) writes: >I'm writing a program that reads from /dev/dsp and attempts to display >the results graphically using svgalib. Currently, I can get it to >work using something like a playing a CD, or if I play a mod to /dev/dsp1 >(I have a PAS 16) and set the PAS to record from pcm2, it will work. >But I would like it to be able to read /dev/dsp while a program like >str was using it. Is this possible, can it be done with some simple >modification of str, or do I have to have a tracker as part of my program >in order to do this. Most of the current soundcards are not able to do simultaneous input and output of digitized voice. The only exeption is the PAS16 which has two audio devices in the same package. The GUS is also able to record and play back at the same time but the current driver doesn't support it (could be possible within this year). The SB family doesn't have this capability. It could be technically possible to build some kind of monitor device to the sound driver (a process reading from this device receives a copy of everything written to /dev/dsp). However it's likely that this kind of solution has disastrous performance effects so I'm not willing to implement it. Hannu -- ============================================================================ Hannu Savolainen (hsavolai@cs.helsinki.fi) Hexdump a day keeps the doctor away. ------------------------------ ** 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 ******************************