Linux-Development-Sys Digest #445
Linux-Development-Sys Digest #445, Volume #6 Tue, 2 Mar 99 10:16:16 EST
Contents:
Re: capturing keyboard input? ("mark")
Re: SMP Support ("Paul F. Dietz")
Re: Some notes on glibc-2.1 and egcs-1.1.1 (Safuat Hamdy)
how can i change the video mode in c++ ("davide morelli")
can you tell me how to write a .dll in c++ ? ("davide morelli")
Re: waiting for milliseconds? ("mark gittins")
Re: LINUX MERCED (Dr A O V Le Blanc)
Re: PROOF: Jesus *is* Lord of the Sabbath! ("Mathiaxe")
Re: PROOF: Jesus *is* Lord of the Sabbath! ("Per Olsson")
Re: PROOF: Jesus *is* Lord of the Sabbath! (Stuart Bell)
Re: PROOF: Jesus *is* an iMac (Stuart Bell)
Re: PROOF: Blondes love iMacs (Julian Robert Yon)
WHY AM I BEING BLAMED? (Julian Robert Yon)
Re: Some notes on glibc-2.1 and egcs-1.1.1 (Andreas Jaeger)
Re: Real Programmers text editors ("Per Olsson")
Re: SMP Support (Julian Robert Yon)
Re: Driver Programming (Gerard van der Sel)
Re: SMP: slicing by -process- or -thread- ? (Peter Samuelson)
Re: glibc 2.1 ;) (Ronald Cole)
Sound under 2.2.x -- mulaw missing (Michael Hirsch)
From: "mark" [EMAIL PROTECTED]
Subject: Re: capturing keyboard input?
Date: 2 Mar 1999 10:25:07 GMT
i *think* that there is something in a book called Advanced Unix
Programming Marc Rochkind / Paperback
/ Published 1985. He details some C code to do this, you use system calls
to modify the setup of the terminal, Sorry I can't remember any more
details but it has been a few years since I saw it.
Mark Gittins
[EMAIL PROTECTED]
John DeBoard [EMAIL PROTECTED] wrote in article
[EMAIL PROTECTED]...
Any programmers out there know how to capture keyboard input using C.
DOS had the getch() thing, I notice that there is a curses getch but I
was just wondering if there was some sort of way to get to things on a
kernel level, like catching the kbd interrupt, then translating it..
John DeBoard
[EMAIL PROTECTED]
--
From: "Paul F. Dietz" [EMAIL PROTECTED]
Subject: Re: SMP Support
Date: Tue, 02 Mar 1999 04:46:22 -0600
I suppose it depends on how your disk performs. If your disk I/O is
really slow, then maybe it really helps if one process can be
compiling while another is writing to disk, whereas if your disk I/O
were really fast then this wouldn't make as much of a difference.
Just guessing though
Also, doesn't the kernel compile use the -pipe option
to gcc? That would already give some parallelism
even without the -j option to make.
Paul
--
From: Safuat Hamdy [EMAIL PROTECTED]
Subject: Re: Some notes on glibc-2.1 and egcs-1.1.1
Date: 02 Mar 1999 11:07:16 +0100
Andreas Jaeger [EMAIL PROTECTED] writes:
2. programms compiled with gcc-2.8.1 and glibc-2.0.6 which previously worked
well fail when recompiled with egcs-1.1.1 and glibc-2.1
here make (3.77) is a good example (but others exist, moc from Qt is another
one)
[...]
Did someone else made the same observations? Is there a way out of this
uncomfortable situation?
Read the glibc2.1 FAQ:
4.6.I've build make 3.77 against glibc 2.1 and now make gets
segmentation faults.
sorry that I come back on this, but I checked moc more closely. Conclusion:
moc (Qt-1.43) compiles well and does not have the "defects" make-3.77 suffers from.
Anyway moc
crashes, for instance:
in qt-1.43/src:
$ gdb ../bin/moc
...
(gdb) run dialogs/qfiledialog.h -o dialogs/moc_qfiledialog.cpp
...
Program received signal SIGSEGV, Segmentation fault.
0x400ca291 in _IO_unbuffer_write () at genops.c:734
734 _IO_SETBUF (fp, NULL, 0);
(gdb) bt
#0 0x400ca291 in _IO_unbuffer_write () at genops.c:734
#1 0x400ca2c9 in _IO_cleanup () at genops.c:749
#2 0x40095029 in exit (status=0) at exit.c:62
#3 0x4008caa1 in __libc_start_main () at ../sysdeps/generic/libc-start.c:78
Similar results for moc from Qt-1.40 when recompiled with glibc-2.1 and egcs-1.1.1
(which worked
well with glibc-2.0.6 and gcc-2.8.1)
And now?
--
S. Hamdy| All primes are odd except 2,
[EMAIL PROTECTED]| which is the oddest of all.
|
unsolicited commercial e-mail | D.E. Knuth
is strictly not welcome |
--
From: "davide morelli" [EMAIL PROTECTED]
Subject: how can i change the video mode in c++
Date: 27 Feb 1999 00:47:16 +0100
under windows'95
davide,
[EMAIL PROTECTED]
--
From: "davide morelli" [EMAIL PROTECTED]
Subject: can you tell me how to write a .dll in c++ ?
Date: 27 Feb 1999 00:48:21 +0100
davide,
[EMAIL PROTECTED]
--
From: "mark gittins" [EMAIL PROTECTED]
Subject: Re: waiting for milliseconds?
Date: 2 Mar 1999 11:17:33 GMT
usleep should be available, see man 3 usleep.
[EMAIL PROTECTED]
Linux-Development-Sys Digest #447
Linux-Development-Sys Digest #447, Volume #6 Tue, 2 Mar 99 21:14:31 EST
Contents:
The proc filesystem on Linux 2.2.1 (Sandeep Kumar)
Patch for 2.2.* and some Digital Celebris machines (Christopher Neufeld)
Re: SMP Support (Michael Hirsch)
Re: 256 threads limit on linux (Nelson Minar)
Re: PROOF: Jesus *is* an iMac (Stuart Bell)
procpc-1.2.9 'w' command??? (Karl Keyte)
Re: WHY AM I BEING BLAMED? ("Jim H.")
rtlinux and RedHat 5.2 (2.0.36) ([EMAIL PROTECTED])
Problem with libstdc++ ("Alahel")
something like getch needed (John DeBoard)
V2.2.0 V2.2.2 kernel do not compile on a m68k Amiga A1200 (Mr Guest)
From: Sandeep Kumar [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.misc
Subject: The proc filesystem on Linux 2.2.1
Date: 02 Mar 1999 12:20:48 -0800
Hi, I've grappled with understanding how to add a new piece of information
for a process through /proc/pid/ or /proc/self. What I've tried is the
following but it doesn't seem to work. Any suggestions?
===
o Added PROC_PID_FOO to the pid_direcory_inos in linux/proc_fs.h as the last
entry of the enum.
o Created get_pid_foo(int pid, char *buff) in fs/proc/array.c to copy the
info about the process that I want displayed.
o updated get_process_array() in fs/proc/array.c to dispatch PROC_PID_FOO.
o Created a
From: Sandeep Kumar [EMAIL PROTECTED]
Date: 02 Mar 1999 12:07:42 -0800
Message-ID: [EMAIL PROTECTED]
Lines: 23
X-Newsreader: Gnus v5.5/XEmacs 20.4 - "Emerald"
--text follows this line--
static struct proc_dir_entry proc_pid_foo = {
PROC_PID_VIN, 3, "foo",
S_IFREG | S_IRUGO, 1, 0, 0,
0, proc_array_inode_operations,
NULL, proc_pid_fill_inode,
};
in fs/proc/base.c.
o Registered proc_pid_foo with
proc_register(proc_pid, proc_pid_vin);
in fs/proc/base.c.
===
The kernel doesn't panic but I never see /proc/self/foo. What am I not
doing?
If possible, please respond directly to me, perhaps in addition to
responding to the newsgroup.
Thanks
--sandeep
--
Subject: Patch for 2.2.* and some Digital Celebris machines
Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Christopher Neufeld)
Date: 2 Mar 1999 16:03:30 -0500
Posted and emailed to Linus.
A few of us have noticed problems with the 2.2.* series kernels and
some Digital Celebris Pentium boxes. The machines hang before console
initialization on 2.2.1 and 2.2.2. In my office we have four such
machines, three of which fail on the boot, and the fourth has no trouble
at all. The folks at Digital are stumped, the motherboards are the same
on all of them.
Anyway, the problem is that on the problematic boards, the 82C54
programmable interval timer does not clear its output bit after the
countdown is commanded. The result is that a delay loop which is supposed
to take 50 milliseconds instead takes effectively zero time. The number
of CPU clock cycles spent in this 50 ms loop is then divided into a 64
bit number, with the expectation that a valid 32 bit value will be
returned, but because of the short-circuited loop, the resulting quotient
overflows on the division, and everything stops with a division error.
The following patch fixes the problem by detecting when the loop has been
short-circuited, and returning an out-of-bounds value to the calling
subroutine. This means that the TSC cannot be calibrated (at least not by
this technique), so the kernel falls back on non-TSC behaviour. The patch
has been tested, and allows problematical boards to boot into non-TSC
mode while still giving correct TSC behaviour for other Digital Celebris
machines whose CTC is working properly.
*** linux/arch/i386/kernel/time.c.orig Thu Jan 21 09:09:30 1999
--- linux/arch/i386/kernel/time.c Tue Mar 2 16:06:54 1999
***
*** 587,605
--- 587,620
"movl %%eax, %%ebx\n\t"
"movl %%edx, %%ecx\n\t"
/* Busy wait. Only 50 ms wasted at boot time. */
"0: inb $0x61, %%al\n\t" /* Read Speaker Output Port */
+ "incl %3\n\t" /* Add one to loop counter. */
"testb $0x20, %%al\n\t" /* Check CTC channel 2 output (bit 5) */
"jz 0b\n\t"
/* And read the TSC. 5 jiffies (50.00077ms) have elapsed. */
"rdtsc\n\t"
/* Great. So far so good. Store last TSC reading in
* last_tsc_low (only 32 lsb bits needed) */
"movl %%eax, last_tsc_low\n\t"
+
+ /* If the loop counter is zero, then there's a problem with
+ * the CTC (maybe a Digital Celebris Pentium machine?).
+ * The calibration fails. */
+ "movl %3, %%eax\n\t"
+
