On Sat, 26 Feb 2000 theone@aitchison.chch.planet.org.nz wrote:
>> > 1) Have as many VC's as I like - not restricted by video RAM
>> > size.
>> 64 is not enough for you? I'm largest VT consumer of all I know and I'm
>> satisfied with 24 VTs (currently 25, as 25th is VMware fullscreen).
>
>Well, I'm using (checks /etc/inittab) 54 VTs, which is considerably higher
>than 25, and I'm running out of VTs. I keep finding I have to close one to
>use something else. I'm thinking about making more, just not sure which
>key bindings to give them.
>
>I could easily use more than 64 -- what I do to manage them is I make
>groups of 9 VTs using the number pad keys plus a modifier.
>
>Alt-1 to 9 are for web browsing. No modifier, just 1 to 9 jump to shell
>prompts in ~/src (customised getty that logins for me). Ctrl-1 to 9, are
>shell prompts beginning in ~/.
>
>I've considered using the "screen" program but I have found that swapping
>between programs isn't as nice.
>
>I do think 64 is too little, but I think 256 would be sufficient -- but I'm
>sure it could be possible that 256 isn't enough for someone.
Ouch! That many? Well, I'd never personally use them all, but I
think that having the kernel support that many is a good idea if
someone out there wants that many. Isn't it just a #define you
can change?
>> > 2) Have the OPTION of having separate scrollback buffers on each
>> > VC, each of which can be a different runtime configurable
>> > size.
>> Well, it was talked about couple of times and always shot down,
>> as with 32KB scrollback (current VGAcon does 4KB onscreen + 28KB scrollback)
>> it is 32KB per console unswappable memory, and as you may noticed, even
>> although such useful thing as devfs consumes 66KB, users complain that
>> it is too big. And 32KB * 64 VT = 2MB.
>
>Is there some reason why the memory could not be swapped out? Or could
>memory onboard the video card be used to store each scroll back somehow?
>(I'm often in text mode w/o X and my video card has 8 megs of RAM)
Or if not swapped out, then how about a scrollback buffer
ager? Lets say after the last operation that put data in
scrollback on a VC a timer activates which counts down. If
something else scrolls it resets the timer. If nothing scrolls,
then after a programmable time - the buffer is flushed and the
memory returned to the pool.
That would work fine for me. I'd set my timeouts at around 15-20
minutes.
>Really two megs of memory makes very little difference if you look at how
>much the applications running on each VT take up.
I think it is more a question of: Does the person wanting that
big a scrollback buffer agree that is is ok that it takes up X
megs of unswappable memory? If they think it is ok, why not let
them choose that. If a better solution could be found, it would
be great, but I'd rather lose a few megs than get stuck with the
single scrollback buffer there is now. 2.0.x had separate
buffers on each console. They were small, and the more VC's you
had the smaller they were, but they were useful.
>Even ash is likely to take up more than 32kb (and it may be
>possible for shells to be swapped out, but I have found that
>they're not ..).
13683 tty8 SW 0:00 [bash]
Bash is swapped out on my machine. ;o) I have another box that
has several shells swapped out.
TTYL
-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocateSuspicious Anagram #4: Word: PRESIDENT CLINTON OF THE USA Anagram: TO COPULATE HE FINDS INTERNS
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:14 EST