wjc@ho5cad.ATT.COM (Bill Carpenter) (04/19/89)
A while back there was a question and brief discussion about getting more windows on a UNIXpc. I don't recall ever seeing if anyone ever figured out how to do it or figured out definitively that it couldn't be done (without rebuilding the kernel, I guess). So, does anybody know the answer to this? (Well, as a matter of fact, I *haven't* tried just making more /dev/w?? device entries. On this machine, that sounds too simple.) -- -- Bill Carpenter att!ho5cad!wjc or attmail!bill
lenny@icus.islp.ny.us (Lenny Tropiano) (04/20/89)
In article <WJC.89Apr18182734@ho5cad.ho5cad.ATT.COM> wjc@ho5cad.ATT.COM (Bill Carpenter) writes: |>A while back there was a question and brief discussion about getting |>more windows on a UNIXpc. I don't recall ever seeing if anyone ever |>figured out how to do it or figured out definitively that it couldn't |>be done (without rebuilding the kernel, I guess). |> |>So, does anybody know the answer to this? (Well, as a matter of fact, |>I *haven't* tried just making more /dev/w?? device entries. On this |>machine, that sounds too simple.) Ain't that simple ... I tried doing the mknod(1M) command for the next window devices (minor number changed) to see if the NWINDOWS define in /etc/master for 12 was the limit. It sure was, after the 12 windows were allocated I got EBUSY ... "Device Busy" ... Maybe the next release of the kernel will have NWINDOWS increased, although I rarely go over 12 windows ... if you don't use the USER AGENT (UA) then you shouldn't have too much trouble keeping within the 12 window constraint. -Lenny -- Lenny Tropiano ICUS Software Systems [w] +1 (516) 582-5525 lenny@icus.islp.ny.us Telex; 154232428 ICUS [h] +1 (516) 968-8576 {talcott,decuac,boulder,hombre,pacbell,sbcs}!icus!lenny attmail!icus!lenny ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752
bdb@becker.UUCP (Bruce Becker) (04/21/89)
In article <WJC.89Apr18182734@ho5cad.ho5cad.ATT.COM> wjc@ho5cad.ATT.COM (Bill Carpenter) writes: |A while back there was a question and brief discussion about getting |more windows on a UNIXpc. I don't recall ever seeing if anyone ever |figured out how to do it or figured out definitively that it couldn't |be done (without rebuilding the kernel, I guess). | |So, does anybody know the answer to this? (Well, as a matter of fact, |I *haven't* tried just making more /dev/w?? device entries. On this |machine, that sounds too simple.) I have tried to make more window devices, and to change the value "nwindows" in "/etc/master", but it seems to have no effect. | Bill Carpenter att!ho5cad!wjc or attmail!bill Cheers, -- __ Bruce Becker Toronto, Ont. w \cc/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/v/-e BitNet: BECKER@HUMBER.BITNET _< >_ "A divine sparc turned me from nextrophilia" - NoNuke of the North
gil@limbic.UUCP (Gil Kloepfer Jr.) (04/21/89)
In article <WJC.89Apr18182734@ho5cad.ho5cad.ATT.COM> wjc@ho5cad.ATT.COM (Bill Carpenter) writes: >A while back there was a question and brief discussion about getting >more windows on a UNIXpc. I don't recall ever seeing if anyone ever In article <677@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: >Maybe the next release of the kernel will have NWINDOWS increased, Although there is a kernel "variable" called NWINDOWS, the real limitations are in the window driver, not in the kernel. I believe (correct me if I'm wrong) that the number of windows is limited by the amount of memory/structures that are compiled-into the window driver (which, BTW, is a loadable driver and can be changed...some food for thought for you window-program hackers out there ;-) So, correctly speaking, what should really happen is: 1) have AT&T increase the amount of windows compiled-into the window driver [a memory waste for those who don't use a lot of windows], or 2) rewrite the window driver so that the maximum number of windows can be dynamically changed by modifying NWINDOWS. I doubt #2 will ever be done, and I think that #1 will probably not be done for the reason I gave above. Sound correct? ----- | Gil Kloepfer, Jr. | ICUS Software Systems/Bowne Management Systems (depending on where I am) | {decuac,boulder,talcott,sbcs}!icus!limbic!gil or gil@icus.islp.ny.us
todd@ivucsb.UUCP (Todd Day) (04/24/89)
In article <482@limbic.UUCP> gil@limbic.UUCP (Gil Kloepfer Jr.) writes:
~So, correctly speaking, what should really happen is: 1) have AT&T increase
~the amount of windows compiled-into the window driver [a memory waste for
~those who don't use a lot of windows],
But won't the new window driver just eat more kernel memory? It seems to me
that there is a LOT of unused kernel memory, and adding a few more window
structures doesn't seem like it will put a real drain on available kernel
memory...
BTW, when you open a window, where does the memory that holds all the
points within that window get allocated? Certainly, there must be two
updates every time something is written to the screen (1 for the
actual screen memory and another one so the computer can do windowing).
Also, where is the screen memory mapped to?
--
-Todd Day-
UUCP: {pyramid, ucbvax}!ucsbcsl!nessus!ivucsb!todd
Internet: todd%ivucsb.UUCP@anise.acc.comjcm@mtunb.ATT.COM (was-John McMillan) (04/26/89)
In article <757@ivucsb.UUCP> todd@ivucsb.UUCP (Todd Day) writes: ... >But won't the new window driver just eat more kernel memory? It seems to me >that there is a LOT of unused kernel memory, and adding a few more window >structures doesn't seem like it will put a real drain on available kernel >memory... There are users out there with TCP/IP, xt, cmb, nicp, and other loadables -- all at the same time. Sadly, this means they are running with as little as 6 free kernel pages. They have locked up merely by turning on screen- blanking -- which requires another 8 kernel pages. While we could argue about strategies that free those 8 pages, it is difficult to defend the statement that "there is a lot of unused kernel memory". (It is also hard to justify the TCP/IP size, but folks use it...) john mcmillan -- att!mtunb!jcm
gil@limbic.UUCP (Gil Kloepfer Jr.) (04/29/89)
In article <757@ivucsb.UUCP> todd@ivucsb.UUCP (Todd Day) writes: >In article <482@limbic.UUCP> gil@limbic.UUCP (Gil Kloepfer Jr.) writes: >~So, correctly speaking, what should really happen is: 1) have AT&T increase >~the amount of windows compiled-into the window driver [a memory waste for >~those who don't use a lot of windows], > >But won't the new window driver just eat more kernel memory? It seems to me >that there is a LOT of unused kernel memory, and adding a few more window >structures doesn't seem like it will put a real drain on available kernel >memory... >-Todd Day- >Internet: todd%ivucsb.UUCP@anise.acc.com Yeah, it *will* eat more kernel memory...which I would like to have available for device drivers for other things .. like maybe the proposed SCSI board being worked on, voice power board, my own device drivers, etc. Although it's THERE, it's not there to waste. If the window driver is to use memory like it does, the parameter should be tunable, or it should allocate/free virtual memory at window create/delete time (if it doesn't already). I suspect it *does* use kernel memory, for a multitude of reasons too complex (and a little beyond my knowledge of the kernel) to explain here on the net. Most of us out here have no need for the extra windows. Unless you use the user agent (which, I may add, could use window resources much more efficiently), you will rarely, if ever, exceed the window limitations of the machine. I'm sure someone has a non-ua-based pet project which is an exception to this rule, but it seems to me that my statement is more the rule than the exception. Again, if someone didn't respond already with the correct answer, my understanding is that the bitmap for each window is saved somewhere other than in screen memory for the sole purpose of being able to restore windows which were temporarily occluded by another window at some time. Since these bitmaps are large (or can become large), I do feel that they should not be there unless "allowed" (like with a tunable parameter). ----- | Gil Kloepfer, Jr. | ICUS Software Systems/Bowne Management Systems (depending on where I am) | {decuac,boulder,talcott,sbcs}!icus!limbic!gil or gil@icus.islp.ny.us
wjc@ho5cad.ATT.COM (Bill Carpenter) (04/30/89)
In article <484@limbic.UUCP> gil@limbic.UUCP (Gil Kloepfer Jr.) writes: > Yeah, it *will* eat more kernel memory...which I would like to have available > for device drivers for other things .. like maybe the proposed SCSI board > being worked on, voice power board, my own device drivers, etc. Although > it's THERE, it's not there to waste. > > If the window driver is to use memory like it does, the parameter should > be tunable, or it should allocate/free virtual memory at window create/delete No doubt about it. Bitmaps for windows could get up to about 30k each. That's not much in a regular old program, but it's enormous in kernel country. Sure makes you wish there were a user space window manager available, doesn't it? It would probably not be possible to completely emulate the existing window system without dipping into a little kernel sorcery, but you could probably come pretty close. If you didn't care much about compatibility with the native stuff, you could probably just port some existing free window system. Like, f'r'instance, "X" (probably too hard to be practical) or "mgr" (I have the author's list of things needed to change for SysV, but I don't have the time to try it soon). -- -- Bill Carpenter att!ho5cad!wjc or attmail!bill