Linux-Development-Sys Digest #42, Volume #7 Wed, 11 Aug 99 09:15:26 EDT
Contents:
Re: Device driver programming and C++ (ellis)
Re: Linux assembly, etc (Josef =?iso-8859-1?Q?M=F6llers?=)
Re: Looking for a good utility... (Mason)
Need Help Boot Record (Reungyos Vorajenwanich)
Re: Compile problem with kernel 2.2.11 (Erik de Castro Lopo)
Re: Need help with PAM/g++ (Horst von Brand)
Re: Which file systems are write stable on Linux? (Randall Parker)
Re: Why ignore a theoretical possibility? (Peter T. Breuer)
Re: My first linux program: non-bios boot loader (Etienne Lorrain)
Re: Looking for a good utility... (Bernd Strieder)
Re: Linux hangs at reboot after recompiling kernel 2.2.10 ("JanW. Roelofs")
Re: My first linux program: non-bios boot loader (H. Peter Anvin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (ellis)
Subject: Re: Device driver programming and C++
Date: 11 Aug 1999 00:42:16 GMT
In article <7ohpnb$t33$[EMAIL PROTECTED]>,
Andrey Fisunenko <[EMAIL PROTECTED]> wrote:
>I returned to "man g++ > temp.txt" after reading your advice and tried to
>find entry "rtti" with no success.
>Where can I read more detail g++ information like that?
Try http://egcs.cygnus.com/onlinedocs/gcc_toc.html
--
http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: Josef =?iso-8859-1?Q?M=F6llers?= <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Linux assembly, etc
Date: Wed, 11 Aug 1999 08:12:00 +0200
Alexander Viro wrote:
> =
> In article <[EMAIL PROTECTED]>,
> Johan Kullstam <[EMAIL PROTECTED]> wrote:
> >of course it's not *really* a shared library. however, on the surface=
> >it shares a couple of attributes:
> >
> >1) system calls are done by a C subroutine call mechanism. in x86 you=
> > push args onto the stack and use a `call' instruction.
> =
> Check the facts, please. It's done by putting the values into registers=
> followed by int 0x80. No trace of call. We are *not* using the call
> gate - it's a trap gate and nothing is copied from the caller's stack.
> Check arch/i386/kernel/{trap.c,entry.S} for details. Or just do the fol=
lowing:
> al@bird:/tmp$ ar x /usr/lib/libc.a write.o
> al@bird:/tmp$ objdump --disassemble write.o |less
Could it possibly be that you two (Alexander and Johan) happily talk
past another?
If I wrote a C program, I would initiate a system call (e.g.
open/close/read/write) by calling a subroutine/function (possibly) in
the standard-C-library (g)libc. This is usually but not necessarily a
shared library. My process would still be in user land, parameters would
(usually) be passed by pushing them onto the stack and retrieving them
from there. The passing of arguments and the calling of functions is a
compiler issue.
(This is Johan's point of view)
The library function would then, in turn, do the actual system call,
e.g. by loading the parameters into registers and executing an INT
instruction. This would switch into system mode and enter the kernel.
This is a kernel implementation issue.
(This is Alexander's statement)
Having a library between the user code and the kernel call has the
advantage that the source code is independent of the kernel-entry
mechanism: No matter how the transition from user to kernel mode was
implemented, INT 0x80, CALL gate, SYSCALL instruction, or even
attempting to execute an illegal instruction, the source code would
still refer to it as a function. Some "system calls" may even be
implemented partially or wholly in user land, e.g. a kernel
implementation may choose to map the proc structure read-only into the
user address space, getpid(), getuid() and friends would then require no
entry into kernel mode.
Having a shared library has the additional advantage that a program
gains a certain degree of binary portability, because the transition
code is added at runtime and a different library may be linked at
program start time to reflect the change in calling method.
Hoping to end a senseless debate,
Josef
-- =
PS Die hier dargestellte Meinung ist die persoenliche Meinung des
Autors!
PS This article reflects the autor=B4s personal views only!
------------------------------
From: Mason <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Looking for a good utility...
Date: Wed, 11 Aug 1999 01:31:41 -0500
Kaz Kylheku wrote:
>
> On Tue, 10 Aug 1999 19:48:55 -0400, Charles Sullivan <[EMAIL PROTECTED]>
> wrote:
> >
> >Keith Wright wrote in message ...
> >>Tristan Wibberley <[EMAIL PROTECTED]> writes:
> >>
> >>> Mason wrote:
> >>> >
> >>> > Can anybody point me in the direction of a good "OS spelunking" type
> >>>
> >>> eh?
> >>
> >>Spelunking: (n) the hobby or practice of exploring caves.
> >>
> >>So he is saying, in obfuscated English, that he wants to look into
> >>the deap dark depths of the code.
> >
> >When you've got all the source code, how much deeper can you
> >expect to get.
>
> You don't get it. The source code *is* the deep dark cave. :)
Maybe, just maybe, I would like to see how see how that source code is
translated into native machine language. Also to see how differences in
high level code structure affect how the compiler/linker creates the
final binary. All this talk hasn't helped me find a "debug"-like
utility though; I'll check out gdb, but I'm afraid it won't be very
intuitive for this type of stuff.
--
If guns are outlawed, how will we shoot the liberals?
[EMAIL PROTECTED]
------------------------------
From: Reungyos Vorajenwanich <[EMAIL PROTECTED]>
Subject: Need Help Boot Record
Date: Wed, 11 Aug 1999 10:40:14 +0700
Dear Everyone.
Now i'm trying to find information about Boot Record to do my Paper
work but i don't know where i can find it.so anyone know please let me
know.Mail to me at [EMAIL PROTECTED]
Thank You Very Much.
Reungyos.
------------------------------
From: Erik de Castro Lopo <[EMAIL PROTECTED]>
Subject: Re: Compile problem with kernel 2.2.11
Date: Wed, 11 Aug 1999 19:28:51 +1000
Robert Krawitz wrote:
<snip>
> One of the early menu items is to choose your maximum memory size.
> It's not set to anything by default; you have to pick something (1 GB
> is the most common).
Thanks, thats fixed it.
It was my fault for just copying the .config files from the directory
of 2.2.10 before compiling. The maximum memroy size option must be a new
one.
Erik
--
+-------------------------------------------------+
Erik de Castro Lopo [EMAIL PROTECTED]
+-------------------------------------------------+
Will the last person leaving Redmond please turn off all the lights.
------------------------------
From: Horst von Brand <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: Re: Need help with PAM/g++
Date: 10 Aug 1999 18:01:45 -0400
lx <[EMAIL PROTECTED]> writes:
> These are my command lines:
>
> gcc auth.c -o auth -ldl -lpam -lpam_misc
> g++ auth.c -o auth -ldl -lpam -lpam_misc
>
> The first works. The second yields undefined references on PAM
> functions described in both libpam.so and libpam_misc.so. What on
> earth is going on here??
Did you wrap your callback functions in
extern "C" {
// prototypes go here
}
?
--
Dr. Horst H. von Brand mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
------------------------------
From: [EMAIL PROTECTED] (Randall Parker)
Subject: Re: Which file systems are write stable on Linux?
Date: Tue, 10 Aug 1999 18:21:35 GMT
In article <7opjbp$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> Unless something is totally wonky, databases that I have seen rarely, if
> ever change the names of their data files. Depending on the load, the
> transaction logs are created every 30 minutes or more. If you have much
> more in the direction of transaction logs being created, maybe you should
> increase the max size of the log.
I think there are RDBMSs that write out their transaction logs
synchronously. So if either the transaction log on one partition or the
database itself on another partition would survive a system crash then
there would be some way to get back pretty close to the final state of
the database of where it was at when the system crashed.
If a volume can't be read at all (because the metadata is garbled)
whether its database files are up to date or not is a moot point. If you
can't get to them how much is in them doesn't matter.
> If it is other files that are being created on a rapid basis, then that is
> a different issue.
One thing I thought of was to put the database files on their own
partition. That way there is less updating of the directory entries and
less chance that a metadata corruption at the time of system crash would
render the whole partition or much of the partition's files unaccessible.
But as a database file grows in size doesn't the directory entry for it
get updated to reflect its size? So it is getting written to all the
time, right? Granted, it probably only gets updated and stays at the same
location on the disk and the links between the directory entries probably
(I am guessing) do not change.
>I don't think many, if any, JFS filesystems guarantee
> consistency of data, only consistency of metadata.
Aside: elsewhere I have read that AIX can't use JFS on its boot
partition. So its journalling is helpful for the metadata on data
partitions. A friend who runs a mix of different OSs tells me he still
runs first to his AIX machine to shut it down gracefully when power has
failed and he is running hardware on his UPS boxes. He finds AIX's file
system on the OS partition to be fragile.
> I think that one of the
> BSDs has what you are looking for in terms of sync metadata updates.
That is very useful to know.
> There
> was a big discussion a few months back about this, with *BSD people saying
> that sync metadata was the way to go, while Linux people said that if you
> are writing out data blocks it doesn't affect metadata, and if you crash
> while writing metadata, it doesn't really matter if you are writing those
> out first.
But if the metadata is being written out synchronously then at any given
time when power fails there is a lower chance that there will be metadata
waiting to be written and there will, on average, be less metadata
waiting to be written.
I realize that there is no wonderful panacea. I am just looking for
techniques that reduce the frequency of data losses and the size of
losses when they do occur.
------------------------------
From: [EMAIL PROTECTED] (Peter T. Breuer)
Subject: Re: Why ignore a theoretical possibility?
Date: 11 Aug 1999 07:02:54 GMT
Reply-To: [EMAIL PROTECTED]
Alexander Viro ([EMAIL PROTECTED]) wrote:
: In article <[EMAIL PROTECTED]>,
: Benedetto Proietti <[EMAIL PROTECTED]> wrote:
: >thinking about the theoretical possibility to realize a compiler like
: >this:
: >- a source code is compiled for the first time and some information is
: >saved about it.
: >- following modifications of said source could be handled so that a very
: >little portion of the source is recompiled, and the generated code is
: >properly inserted into the (previously) compiled file. By little portion
: >I mean single functions, statement or less!
: First of all, minimal modifications of source may seriously change the
: parse tree. Morevore, with even less efforts you can change the common
: subexpressions and lifetimes and *that* will tear down a lot of things done
: by any decent optimizer. So you'll have to redo it anyway. Yes, you can do it
: on per-function basis. If the function is not inlined, that is.
: The main question being: what for? Incremental compile? That had been
: supported by any C compiler since the original ones (IIRC there were several
: toy compilers on bitty-boxen that required to keep everything in the single
: file, but who cares?). Just don't make your modules excessively large and
: that's it. And use make. It's C, not PASCAL.
Amen.
Incremental compile-on-demand was supported at the function level by
an environment for a functional database language (DL) that I wrote in
the mid eighties. You changed a line of source and the next time that
function was needed, its object code would be recompiled from the
source. The dependency information was kept, so that dependent
functions were marked as invalid and then recompiled the next time
_they_ were needed.
WIth an eager compile scheme, instead of a lazy one, this is what
Benedetto proposes.
If I were to do it again, I would background the compiler as a low
priority task, and have it eager.
Peter
------------------------------
From: Etienne Lorrain <[EMAIL PROTECTED]>
Subject: Re: My first linux program: non-bios boot loader
Date: Wed, 11 Aug 1999 12:05:38 +0100
Hi,
Neil Koozer wrote:
> [...]
> This thread began with the description of a boot loader that solves a
> real-world problem.
>
> The problem is:
> Many first-time installers of linux are blocked or frustrated by the
> "LI" or the "L 01 01 01..." problem.
> The latter is due to the bios being unable to address drives hdc-hdh or
> the bios being unable to address above cylindar 1023. The "LI" is
> usually due to geometry confusion between the bios and linux.
That is the problem.
My other constraint (and probably for a lot of people) is that
I am not always booting the same thing, i.e. I already have
different kernel (and even different root partitions) on the
same PC - and most people have also different operating system,
for instance *BSD. I will not boot Linux to change the kernel
to be booted and then reboot.
Your bootloader is nicely written, but I do not see how to
extend it to handle different kernel or different OS. It is
better than mine because it works, mine is a lot more complex
in the way that I want to propose (graphically, VESA) the user
a "selection" of kernel possible to boot and preload the
necessary modules (SCSI, filesystems), but mine is still not
working.
By the way, using the (E)BIOS DISK interface would normally
enable also the PCMCIA devices like plug-able disk, or the
"simulated hard/floppy disk on CDROM" and so boot a kernel
on those, it is not only for SCSI. EBIOS disk V3 should also
enable booting from a network, when it will be available.
Also, if the installer (the equivalent of your muni.c) is
written in real mode, it can exactly detect which kind of
BIOS is available (at least 4 kinds), what is the understanding
of the disk geometry by the BIOS, and be sure to provide
what is necessary at the next boot. Moreover, because I do
not plan to modify the second stage bootloader while Linux
is running, this file can be marked as "imuable", i.e.
read only even for root (but in runlevel 1), so luser-root
will always have a booting PC.
Note also that you will find (older but still in use) IDE
hard disk which cannot do LBA addressing, just CHS (see
ATA doc, bit 6 of register 6, from memory); Linux is perfectly
working with these HD, but they will not boot with your
bootloader.
Have a nice day,
Etienne.
------------------------------
From: Bernd Strieder <[EMAIL PROTECTED]>
Subject: Re: Looking for a good utility...
Date: Wed, 11 Aug 1999 13:08:30 +0200
Hi
Mason wrote:
>
>
> Maybe, just maybe, I would like to see how see how that source code is
> translated into native machine language. Also to see how differences in
> high level code structure affect how the compiler/linker creates the
> final binary. All this talk hasn't helped me find a "debug"-like
> utility though; I'll check out gdb, but I'm afraid it won't be very
> intuitive for this type of stuff.
> --
> If guns are outlawed, how will we shoot the liberals?
> [EMAIL PROTECTED]
from the manual page of gcc:
-S Stop after the stage of compilation proper; do not
assemble. The output is an assembler code file for
each non-assembler input file specified.
By default, GCC makes the assembler file name for a
source file by replacing the suffix `.c', `.i',
etc., with `.s'. Use -o to select another name.
GCC ignores any input files that don't require com�
pilation.
So perhaps you just add -S to CFLAGS in the /usr/src/linux/Makefile and
you get what you want. I haven't tried. Perhaps there are other things
necessary, perhaps to add a command in the rule for generating object
files to create the assembly file as well.
But there will be a lot of assembly code to inspect :-)
HTH
Bernd.
------------------------------
From: "JanW. Roelofs" <[EMAIL PROTECTED]>
Subject: Re: Linux hangs at reboot after recompiling kernel 2.2.10
Date: Tue, 10 Aug 1999 21:32:42 +0200
Guilhem Tardy wrote:
>
> Now I can boot (I previously forgot to update the bootsect.lnx in the
> WinNT partition, which worked fine until some boot file moved within the
> ext2 partition), BUT it hangs with the root fs:
> NTFS version 990411
> request_module[block-major-8]: Root fs is not mounted
> VFS: Cannot open root device 08:07
> Kernel panic: VFS: Unable to mount root fs on 08:07
>
> It is kernel 2.2.11 on a SCSI drive, I moved the SCSI drivers (AHA-7xxx)
> to modules and created an initrd image, as described in the RH 6.0
If you like to boot from SCSI, you should NOT compile your AHA-7xxx driver as a module,
but fixed in the kernel.
--
Gr.
JW
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: My first linux program: non-bios boot loader
Date: 11 Aug 1999 12:56:12 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <[EMAIL PROTECTED]>
By author: Etienne Lorrain <[EMAIL PROTECTED]>
In newsgroup: comp.os.linux.development.system
>
> Also, if the installer (the equivalent of your muni.c) is
> written in real mode, it can exactly detect which kind of
> BIOS is available (at least 4 kinds), what is the understanding
> of the disk geometry by the BIOS, and be sure to provide
> what is necessary at the next boot. Moreover, because I do
> not plan to modify the second stage bootloader while Linux
> is running, this file can be marked as "imuable", i.e.
> read only even for root (but in runlevel 1), so luser-root
> will always have a booting PC.
>
There are two problems with this: first of all, you need to get to
real mode to install (and within Linux, you can't get to a "clean"
BIOS), and second of all, if you move the disk to a different system
it may no longer boot. In lbcon I'm doing this determination at boot
time rather than install time for these reasons. The problem, of
course, is that one has to *really* shoehorn stuff into the boot
block...
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
------------------------------
** 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
******************************
