Linux-Development-Sys Digest #263, Volume #8 Wed, 8 Nov 00 06:13:06 EST
Contents:
Re: non-portable port (Alexander Viro)
Re: Help: Kernel hang/coredump analysis (Ji-soo)
Re: non-portable port (George MacDonald)
Re: Raw block device interface ([EMAIL PROTECTED])
Re: harddisk and partitions (MESMEUR Philippe)
compile problem: kernel 2.2.17 on RH 7.0 (Sudhindra Suresh Bengeri)
Linux engineers wanted ("HR")
Re: harddisk and partitions (Josef Moellers)
Re: non-portable port (Josef Moellers)
Re: non-portable port (Josef Moellers)
Re: Is that process a thread? (Maciej Golebiewski)
Re: Is that process a thread? (Maciej Golebiewski)
Re: Is that process a thread? (Maciej Golebiewski)
Video Sync and X and Linux (Chris Mihaly)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: non-portable port
Date: 8 Nov 2000 00:18:08 -0500
In article <IL4O5.134328$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>> <shrug> ncurses, indeed. The only real reasons why DOS stuff needed direct
>> access to video memory were
>> * very inefficient implementation of the terminal driver
>> * general laziness stopping folks from implementing intelligent
>> redraw algorithms.
>
>I thought the _real_ big deal was the fact that BIOS didn't offer a
>"string" function; in order to output 60 characters, you had to bounce
>60 interrupts at the system. None too efficient...
Last time I touched anything of that family was _long_ time ago, but
ISTR that there was such function. OTOH it might be EGA and higher or
something... Bugger if I remember. Dunno. One might expect that write(2)
would do the right thing, BIOS or not. After all, that's what the kernel
is about - applications have no bloody business running around and calling
the internal kernel functions, no matter where these functions are stored.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: Ji-soo <[EMAIL PROTECTED]>
Subject: Re: Help: Kernel hang/coredump analysis
Date: Wed, 08 Nov 2000 16:24:01 +0900
kdb or kernprof can be helpful.
Ji-soo
http://oss.sgi.com/projects/
Liaw Yong Shyang wrote:
> Hi,
>
> I have midified and recompiled the Linux kernel for my project. I can
> reboot from my new kernel image successfully, and it works happily.
> However, the system will hang from time to time. How can I debug, as I
> could not repeat the bug at my will?? Is it any tool that I can use to
> analyse coredump? Any book or article I can read more about coredump
> analysis?
>
> I really appreciate if you can help. Thank in advance.
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: non-portable port
Date: Wed, 08 Nov 2000 07:26:18 GMT
T wrote:
>
> I'd like to revive an old dos project that used inline assembly calls
> to BIOS and direct screen writes. Trying to get up to speed with Linux
> programming, I've been looking at some sources and reading what I can
> find. It looks like both (BIOS calls and direct screen writes) are
> verboten and in the domain of the Linux kernel. Learning about modules
> and kernel will take too long although I plan to keep at it. I looked
> at SVGALib, but my app doesn't need graphics-- it writes to text
> screen. Are there any viable approaches (other than give it up:~) and
> stuff like curses?
Try
man console_codes
You can output these things to most TTY windows/devices. These "codes"
come from an ancient device called a Terminal something that used
to be connected to serial ports on Computers that had *real* operating
systems. In fact they are derived from a specific terminal family(VT100
to be precise) produced by a now defunct company that was called Digital Computers.
Actually I think they were bought out by one of those BIOS based companies!?
So popular were these products that many terminal manufacturers adopted the format
and it eventually became a standard --> ANSI X3.64
You can actually just blurt these things out from a program and lo
and behold you get all those cool console type features!!!!! You
can even do it in shell programs!!! So if you are looking for the easiest
way to write a program that does 2d character based addressing, that's
probably it.
Curses was created to buffer people from those codes because there were
hundreds of different terminals using different codes ... When X windows
came along people needed the familiar terminal interface so Xterm was
created. These "terminal windows" programs grew and multiplied to the
point that there are dozens to choose from. Most of them support the
ANSI X3.64 standard. Even the text based consoles on Linux
support the standard. i.e. the ones that you see when the system boots
before starting up the window manager
You can do great amount with just the cursor position codes, i.e.
<ESC>[row;colH
i.e. The ESC character, the open square bracket, the row position in decimal
characters, i.e.
0-9, a semicolon, the column position also in decimal characters and finally the 'H'
character.
A simple
printf("\033[%d;%dH", row, col);
or in a shell script:
echo -n "^[[12;32H"
When typing the shell command, press control-v before pressing the escape character as
the
shell does special things when it sees an escape.
You can set foreground/background colors with esc[3#m , esc[4#m Where # = 0-7
You can either translate your assembler to C and use printf's or use the
inline assembler capabilities of the GNU compilers.
You can also learn curses which should only take a day or so. It has a number of
advantages, such as doing smart screen updates... Your code probably already does that
or perhaps you don't need to. Most people would probably tell you do use curses
as it would make your code more portable. For example, you could run it from
a telnet session on your palm VII .......
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.unix.programmer,comp.os.linux.networking
Subject: Re: Raw block device interface
Date: Wed, 08 Nov 2000 07:52:58 -0000
In comp.os.linux.development.system Philip Armstrong <[EMAIL PROTECTED]> wrote:
| You can of course access the block device directly, but it is not
| possible in the current stable kernels to bypass the buffer cache
| AFAIK.
You can open() with O_SYNC. For writes it forces them to be written
immediately. There's less buffering of written data. For reads, if
the block you want is already in the buffer cache, you get it. So
this is not bypassing cache, but it's close. Otherwise I guess you
need the /dev/raw feature, which doesn't seem to allow more than one
device access at a time.
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: MESMEUR Philippe <[EMAIL PROTECTED]>
Subject: Re: harddisk and partitions
Date: Wed, 08 Nov 2000 09:07:18 +0100
Philip Armstrong wrote:
>
> In article <[EMAIL PROTECTED]>, Tux <[EMAIL PROTECTED]> wrote:
> >MESMEUR Philippe wrote:
> >> Hello, I'm looking for a way to get the list of the hard-drives an the
> >> list for all the partitions in each hard-disk. I think the is a system
> >> call to to this.
> >What about "fdisk -l" ?
>
> Or cat /proc/partitions ?
yes but I would like a function to do this (if there isn't, I
will code it)
> Phil
>
> --
> http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
--
========================================================
Oce-Industries SA
1, rue Jean Lemoine
94015 Creteil cedex France
phone: 33-1-48988000 fax: 33-1-48985450
========================================================
------------------------------
From: Sudhindra Suresh Bengeri <[EMAIL PROTECTED]>
Subject: compile problem: kernel 2.2.17 on RH 7.0
Date: Mon, 6 Nov 2000 18:55:57 -0500
Hi,
I downloaded the 2.2.17 src from www.kernel.org, and tried to compile the
kernel following the directions the linux/README file. I have
all the required versions of the packages listed in the
linux/Documentation/Changes.
When I do a 'make zImage' I get the following the error message:
make[2]: Entering directory `/usr/src/linux/arch/i386/lib'
cc -D__KERNEL__ -I/usr/src/linux/include -D__ASSEMBLY__ -traditional -c
checksum.S -o checksum.o
checksum.S:231: badly punctuated parameter list in #define
checksum.S:237: badly punctuated parameter list in #define
make[2]: *** [checksum.o] Error 1
make[2]: Leaving directory `/usr/src/linux/arch/i386/lib'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
make: *** [_dir_arch/i386/lib] Error 2
These are the lines in the linux/arch/i386/lib/checksum.S that give the
error:
#define SRC(y...) \
9999: y; \
.section __ex_table, "a"; \
.long 9999b, 6001f ; \
231 >> .previous
#define DST(y...) \
9999: y; \
.section __ex_table, "a"; \
.long 9999b, 6002f ; \
237 >> .previous
Can anyone pls. tell me where could be the problem? I would really
appreciate that.
TIA.
Regards,
Sudhin.
****************** Sudhindra Suresh Bengeri ********************
Graduate Research Assistant | Home: |
to Dr. George N. Rouskas | 2110, Gorman St., |
Dept. of Computer Science, | Raleigh, NC - 27606 |
NCSU, Raleigh, NC 27606 | Ph. (919) 852-1961 |
My web projection: http://www4.ncsu.edu/~ssbenger
------------------------------
From: "HR" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.portable
Subject: Linux engineers wanted
Date: Wed, 08 Nov 2000 08:45:50 GMT
First of all, our apology if these type of postings are not allowed here..
Stream2Go, Inc. (www.stream2go.com), a startup company based in Orange
County, California offers total mobile wireless intranet solutions for the
corporate enterprise customers. We develop advanced mobile wireless
applications based on embedded Linux OS as a mobile platform. We were
founded by former AT&T Wireless & IBM engineers.
We're currently looking for locally based (LA, OC, & San Diego) Linux / Unix
engineers in all levels & skill sets -
Positions - Directors, Managers, & Engineers (entry, mid, senior)
Salary & Benefits - industry competitive benefits & salary, including
relocation
Skills - Linux / Unix / C / C++, Wireless (HW and/or SW), TCP/IP, WAN/LAN
Design, software development, applications development, Embedded systems
We offer generous stock options and fun working environment. If you're
interested please send your resume via email to [EMAIL PROTECTED]
Stream2Go, Inc.
1 Centerpointe Dr.
Suite 320
La Palma, CA 90623
714-736-1760 main
714-736-1769 fax
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: harddisk and partitions
Date: Wed, 08 Nov 2000 10:10:38 +0100
MESMEUR Philippe wrote:
> =
> Philip Armstrong wrote:
> >
> > In article <[EMAIL PROTECTED]>, Tux <[EMAIL PROTECTED]> wrote:
> > >MESMEUR Philippe wrote:
> > >> Hello, I'm looking for a way to get the list of the hard-drives an=
the
> > >> list for all the partitions in each hard-disk. I think the is a sy=
stem
> > >> call to to this.
> > >What about "fdisk -l" ?
> >
> > Or cat /proc/partitions ?
> =
> yes but I would like a function to do this (if there isn't, I
> will code it)
??? You want to write a function to retrieve information which is
already there ???
Hey, this is Linux, not any other OS!
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: non-portable port
Date: Wed, 08 Nov 2000 10:18:27 +0100
Alexander Viro wrote:
> =
> In article <IL4O5.134328$[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
> >> <shrug> ncurses, indeed. The only real reasons why DOS stuff needed =
direct
> >> access to video memory were
> >> * very inefficient implementation of the terminal driver
> >> * general laziness stopping folks from implementing intelligent=
> >> redraw algorithms.
> >
> >I thought the _real_ big deal was the fact that BIOS didn't offer a
> >"string" function; in order to output 60 characters, you had to bounce=
> >60 interrupts at the system. None too efficient...
> =
> Last time I touched anything of that family was _long_ time ago, but
> ISTR that there was such function. OTOH it might be EGA and higher or
Yepp, Ralf Brwon's interrupt list shows:
INT 10 - VIDEO - WRITE STRING (AT and later,EGA)
AH =3D 13h
AL =3D write mode
bit 0: update cursor after writing
bit 1: string contains alternating characters and attributes
bits 2-7: reserved (0)
BH =3D page number
BL =3D attribute if string contains only characters
CX =3D number of characters in string
DH,DL =3D row,column at which to start writing
ES:BP -> string to write
> something... Bugger if I remember. Dunno. One might expect that write(2=
)
> would do the right thing, BIOS or not. After all, that's what the kerne=
l
> is about - applications have no bloody business running around and call=
ing
> the internal kernel functions, no matter where these functions are stor=
ed.
If you care to remember, DOS was a mere program loader. Once a program
was running, it happily went around DOS and did whatever it wanted
poking bytes into video memory and such. That's what some people call
"innovation".
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: non-portable port
Date: Wed, 08 Nov 2000 10:23:58 +0100
George MacDonald wrote:
> =
> T wrote:
> >
> > I'd like to revive an old dos project that used inline assembly calls=
> > to BIOS and direct screen writes. Trying to get up to speed with Linu=
x
> > programming, I've been looking at some sources and reading what I can=
> > find. It looks like both (BIOS calls and direct screen writes) are
> > verboten and in the domain of the Linux kernel. Learning about module=
s
> > and kernel will take too long although I plan to keep at it. I looked=
> > at SVGALib, but my app doesn't need graphics-- it writes to text
> > screen. Are there any viable approaches (other than give it up:~) and=
> > stuff like curses?
> =
> Try
> =
> man console_codes
Just don't!
As Al Viro has mentioned, ncurses is the way to go. To quote from the
console_codes manpage:
It is generally not good practice to hard-wire terminal
controls into programs. Linux supports a terminfo(5)
database of terminal capabilities. Rather than emitting
console escape sequences by hand, you will almost always
want to use a terminfo-aware screen library or utility
such as ncurses(3), tput(1), or reset(1).
Although these codes may work with the console and most xterms, they are
not guaranteed to work everywhere and you need to keep track of what's
where on the screen. ncurses will do this for you and will provide the
correct codes for a number of terminals, serial, networked, direct, you
name it.
If you need to touch a program for porting purposes, consider that the
interface to the input/output devices is part of the environment.
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
From: Maciej Golebiewski <[EMAIL PROTECTED]>
Subject: Re: Is that process a thread?
Date: Wed, 08 Nov 2000 11:04:33 +0100
George MacDonald wrote:
> One thing that seems to strongly indicate a thread is the presence of
> one of these
>
> 40019000-40023000 r-xp 00000000 03:06 424368 /lib/libpthread-0.8.so
>
> entries in it's /proc/#/maps|
Not really! Consider this: you have a process A that in its main thread
pthread_create (...) ---> creates thread that is a process B
fork () ---> forks process C
Then /proc/#/maps for all A,B and C process (and the additional process which
is the thread manager for A) will contain libpthread. So following your logic
C would get classified as a thread for A (libpthread in maps nad PPID == A)
even though it was fork'ed and not pthread_create'ed!
Maciej
------------------------------
From: Maciej Golebiewski <[EMAIL PROTECTED]>
Subject: Re: Is that process a thread?
Date: Wed, 08 Nov 2000 11:07:20 +0100
[EMAIL PROTECTED] wrote:
> |> Why not use PID/PPID relationships?
> |
> | Because this does not distinguish between processes created by fork and
> | pthread_create, and while if they look the same for the system, the user might
> | still be interested in distinguishing them (I had a few situations myself
> | where
> | it would help me).
>
> I presume in Linux that pthread_create() results in sys_fork() in the
> kernel at some point. In order to distinguish if pthread_create() was
> actually used to end up calling sys_fork() for a given process, you may
> well have to look inside the process space for any markers left behind
> by pthread_create() specific to the new thread. Keep in mind that a
> thread may really call fork(), too, so the marker may get cloned.
That was my first suggestion: to hack pthread_create so that it puts markers
into the new threads environment and then you can look for them using
/proc/#/environ
It's a quick hack but should work.
Maciej
------------------------------
From: Maciej Golebiewski <[EMAIL PROTECTED]>
Subject: Re: Is that process a thread?
Date: Wed, 08 Nov 2000 11:19:44 +0100
George MacDonald wrote:
> What if the exec is on the same executable image, does it reuse the existing
> virtual memory(text/data but not stack)? Can the new exec then create a new
It'll reuse text (the code segment) but data only as long as page is
only read by all processes sharing it (i.e. there will be copy if one of
processes
tries to write into it).
> thread "tree"? Can it create a thread on the old controlling thread?
>
> > If there were other users of old VM they keep what
> > they had. VM is destoryed only when it becomes completely orphaned.
>
> Can one lock pages in memory so they stay there even when all processes
> die. Let's say I want to keep a shared lib in memory cause I know it's
> going to be used again.
If you're speaking of retaining shared libraries code in memory, than it's
better to leave it to the kernel to decide when it makes sense.
I think that kernel will unlock all pages when all processes referencing
them die. IMHO it is the only reasonable thing for the kernel to do.
If you want to retain some data shared by all users of the library, you
can do it by using SYSV shared memory, and letting the shared segment stay
stale after all processes terminate. Then later new processes can shmat that
segment again.
If you don't like the idea of having stale segments hanging around (I don't)
than you can add a small daemon that will be creator of that segment. Makes
easier to decide which segments to delete when you run out of shmem and want
to get rid of the stale ones :)
Maciej
------------------------------
From: Chris Mihaly <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Video Sync and X and Linux
Date: Tue, 07 Nov 2000 13:03:34 -0800
Reply-To: [EMAIL PROTECTED]
I posted this on a linux X board, but this is more a developer
question, so maybe this is a more appropriate forum.
I was wondering if there was a general X API method that would
allow
programs to sync with the monitor. The SGI IRIX X server has an
extension,
called SGI_video_sync (glXGetVideoSyncSGI(), glXWaitVideoSyncSGI(),
glXSwapIntervalSGI). These are obviously SGI extenstion to gl on top of
X. I was wondering if there was a generalized method for getting the
video retrace
interrupt in X or linux?
Thank
Chris
--
Christopher Mihaly Email: [EMAIL PROTECTED]
Walt Disney Feature Animation Phone: (818) 460-9409
500 S. Buena Vista St. Fax: (818) 460-8290
Burbank, CA 91521-4970
------------------------------
** 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: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
