Linux-Development-Sys Digest #447
Linux-Development-Sys Digest #447, Volume #8 Sat, 27 Jan 01 22:13:09 EST
Contents:
Re: getche() (Erik de Castro Lopo)
Re: CHS value of a block (Kasper Dupont)
Re: booting CD, ramfs -> / in 2.4, some issues (Kasper Dupont)
Re: The value of HZ (Kasper Dupont)
Re: Access to beep (echo \a) on embedded system with no console (Kasper Dupont)
Re: 64-bit i-numbers? (Kasper Dupont)
Re: Linux Kernel book about linux 2.0 still useful?? (Kaelin Colclasure)
Re: Controlling things on that other platform (Chris J/#6)
Re: booting CD, ramfs -> / in 2.4, some issues ([EMAIL PROTECTED])
Communication between kernel module and user space program ("knightG")
Re: Controlling things on that other platform ([EMAIL PROTECTED])
Re: How to build a USB rescue floppy disk ([EMAIL PROTECTED])
How to build...? ("The Linux Fan!!!")
Re: The value of HZ ("Norm Dresner")
Re: Communication between kernel module and user space program ("Norm Dresner")
Re: Sys call for Available Memory? - Attempts to help, but still no answer after
months. :-( (MeekGeek)
From: Erik de Castro Lopo <[EMAIL PROTECTED]>
Subject: Re: getche()
Date: Sat, 27 Jan 2001 12:25:21 GMT
root wrote:
>
> I just wanted a funtion that could get input without need to press enter. I don't
> need to change the echo.
> How can i change the terminal setup from c/c++. Writting to some files?
No, by using functions defined in .
man tcsetattr
> BTW what are terminal modes. I am really a newbie. Please use basic words.
Linux has an abstract called the terminal. Every program that gets input
from stdin and puts it's output to stdout does so via this terminal
abstraction. The settings for the terminal can be modified by use
of the tcsetattr() function.
For an example of a program which does this (but not exactly what you
want), have a look at:
http://www.zip.com.au/~erikd/BOOK/list1306_readline.c
Hope this helps,
Erik
--
+--+
Erik de Castro Lopo [EMAIL PROTECTED] (Yes its valid)
+--+
"A subversive is anyone who can out-argue their government"
--
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: CHS value of a block
Date: Sat, 27 Jan 2001 13:23:42 +0100
Josef Moellers wrote:
>
> Marty wrote:
> >
> > How to get the CHS (cylinder, head, sector) value given a block number
> > in a hard disk ?
> >
> > Thanks,
> > Marty.
>
> Physically speaking, this may not be possible, because you may have a
> solid state disk and these tend to not have cylinders and heads.
>
> If you have the number of sectors/track (spt) and the number of heads
> (hds), the assumption is that the sector numbers are such that tracks
> fill first, the cylinders, so if you have a linear block address (LBA):
>
> LBA mod spt + 1= sector (Note sectors are usually numbered 1..spt)
> (LBA div spt) mod hds = head
> LBA div (spt * hds) = cylinder
>
> The values for spt and hds can be obtained using ioctl(fd,
> HDIO_GETGEO,&buf).
>
> --
> Josef Möllers (Pinguinpfleger bei FSC)
> If failure had no penalty success would not be a prize (T. Pratchett)
In earlier operating systems CHS was used to improve
performance and in some cases because the concept of
sectors was not implemented by hardware but by software.
New medias might have different size cylinders or in
the case of CDs not even that but a single spiral.
Linux does only have CHS values because it is sometimes
needed for compatibility with BIOS and/or other
operating systems.
Unless you need to be compatible with some ancient
software designs don't use it.
--
Kasper Dupont
--
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: booting CD, ramfs -> / in 2.4, some issues
Date: Sat, 27 Jan 2001 13:35:53 +0100
Robert Kaiser wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] writes:
>
> > 2. The "df" command shows nothing but "cat /proc/mounts" works.
> > Doing "df" on a specific mounted filesystem does work. Here's
> > what I get (I've pulled the actual unmounting of /mnt for now):
> >
>
> This is probably because df dies on a division by zero error. I've
> noticed this with the busybox version of df and I suspect that
> the standard df has the same problem: the statfs syscall, when applied
> to ramfs returns zeroes for the total blocks and free blocks, which df
> is not prepared to handle.
>
That does not sound likely since df actually works when
given the ramfs as argument. The problem is that for
historic
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
