Linux-Development-Sys Digest #325, Volume #8      Tue, 5 Dec 00 16:13:10 EST

Contents:
  Re: How to make a BIOS call in Linux ([EMAIL PROTECTED])
  Re: Global constructors in ELF so libs NOT CALLED! ("Paul Pluzhnikov")
  Re: Global constructors in ELF so libs NOT CALLED! ("John C. Griggs")
  Re: A challenging problem... ("Paul Pluzhnikov")
  Remapping memory in the kernel space ("David Zada")
  Problem with LVM and LILO (David Vidal Rodriguez)
  linuxthread manager and SIGINT ([EMAIL PROTECTED])
  Re: A challenging problem... (Duane Rettig)
  Re: Can I use alloca() in a kernel module? (Brian Horton)
  Re: linuxthread manager and SIGINT (Kaz Kylheku)
  Re: Problem with LVM and LILO (Bruce Stephens)
  Re: how to rebuild tcp code (Eric Taylor)
  Re: how to rebuild tcp code (Andi Kleen)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED]
Subject: Re: How to make a BIOS call in Linux
Date: Tue, 05 Dec 2000 14:02:46 GMT

I'm using a type of bios called smbios
( http://www.phoenix.com/products/specs-smbios.pdf ) The spec is
written by various PC and BIOS companies, eg, Intel and Phoenix tech.
The smbios knows various aspects about the PC, including temperature,
voltage, bios rev, bios build date, manufacturing, etc.

The static info, e.g., bios rev, bios date, etc, I can get them by
reading from a known location in memory. But for dynamic info,
temperature, voltage, etc, it looks like I need to make the bios call.
If there are other ways to get this info that would be great.

Thanks

In article <[EMAIL PROTECTED]>,
  Joe Pfeiffer <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>
> > Does any body know how to make a BIOS call in linux or point me to
an
> > example in the linux src code? I searched through the linix source
code
> > for "bios' or "BIOS" but did not come up w/ anything useful.
>
> This is the sort of answer I personally find extremely annoying, but:
>
> You almost certainly don't want to do it.  Only a vanishingly small
> number of system-style programs, like the boot loader or APM, have any
> need to ever look at the BIOS.
>
> If you have to ask how (and I'd have to hunt a while, myself --
> speaking as somebody who's written a modularized device driver), it's
> a virtual certainty that you don't need to.
> --
> Joseph J. Pfeiffer, Jr., Ph.D.       Phone -- (505) 646-1605
> Department of Computer Science       FAX   -- (505) 646-1002
> New Mexico State University          http://www.cs.nmsu.edu/~pfeiffer
> VL 2000 Homepage:  http://www.cs.orst.edu/~burnett/vl2000/
>


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: "Paul Pluzhnikov" <[EMAIL PROTECTED]>
Subject: Re: Global constructors in ELF so libs NOT CALLED!
Date: Tue, 05 Dec 2000 15:26:53 GMT

"Erik Westlin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> The build command is ld -shared -o$(OUTFILE) $(OBJS) $(LIBS).

That is your problem. Use g++ to link your .so, and life will be good :-)

It is *never* a good idea to link anything with ld, unless you
*know what you are doing*



------------------------------

Date: Tue, 05 Dec 2000 10:13:31 -0500
From: "John C. Griggs" <[EMAIL PROTECTED]>
Subject: Re: Global constructors in ELF so libs NOT CALLED!

Erik Westlin wrote:
> 
> John C. Griggs wrote:
> >
> >
> > Well, what was your intention?  Surely you weren't expecting someone who
> > needed your little tutorial to be of any help?  BTW, what OO language
> > were you programming in "nearly 20 years" ago?
> >
> Simula http://www.cetus-links.org/oo_simula.html

I've done some Simula77 myself (in college on a VAX system) - you have
my sympathies.  From what I remember, it was a large, slow language that
had some pretty obscure syntax.  We used is with some simulation
libraries (it was part of a course on simulations, not OO programming) -
I'm pretty sure the college got the compiler, etc. free with the VAX and
that was the only reason they subjected their students to it.

> >
> 
> I too have had my share of BIG (void)s (i'm not refering to you John)
> who instead of answering questions like to comment on the way the
> question was put.
> 

I rarely have a problem with the way a question is asked (unless the
person is downright rude), but I am frequently amazed by how many
(apparently intelligent) people expect readers on usenet to be able to
read their minds for the important details and then get upset when this
doesn't happen.  Not to pick on you, but go back and read your own
messages on this thread - if they were coming from a stranger, would
_you_ be able to provide them with any useful guidance based on the
information provided?  I strongly urge you (or anyone) to include code,
compiler and linker options and as much information as possible when you
post a question in the future.  I think most people would rather wade
through a bunch of (possibly) irrelevant information to try to help
someone than have to interrogate a poster for the crucial details.  Of
course, you should always try to reduce the code (etc.) to the simplest
case that exhibits the problem.

> Well i thought it would be an easy answer for whoever knew it.
> I don't think i'm doing anything out of the ordinary so
> there ought to be others who have walked into the same trap.
> Anyway global objects/variables has allways been considered bad
> and i might as well not us them if i could.
> 

It might well be an easy answer, but it is impossible to say without
adequate information about what you are doing.  It's also not possible
to say if you are doing anything "out of the ordinary" if you don't show
anyone what you are doing...  Many folks coming to Linux/Unix from a
Windows background get caught by the differences between DLLs and shared
libraries and its easy to assume that this is the basic problem if you
don't see code (etc.) that proves otherwise.  I've been working on Unix
or (more recently) Linux systems for quite some time now and I still get
screwed up by some obscure detail about once a year or so 8^)!

> Maybe i do something non-ordinary, i'm porting a program
> from NT to linux. This make use of DCOM which has been ported
> to linux and is available for non-commercial use.
> See http://www.softwareag.com/entirex/download/free_download.htm
> DCOM makes heavy use of so-libs or dll's as they are called in
> windows.

If the global object you were having trouble with was some kind of DCOM
Interface, I'd guess the problem may have been with EntireX trying to
emulate DCOM loading on top of the ELF shared library interfaces.  The
inclusion of the "-Bsymbolic" linker command switch in the Makefile
fragment you include below makes me think that some of the EntireX
shared libraries expect to use their own internal globals instead of
those in the main program - without this switch, definitions in the main
program's space supercede those in the library.

> Anyway along the EntireX distribution comes several examples
> and they have another build command. I didn't use it for my
> own libs at first but now i tried it and now everything works!
> 

If this makes your original code (which you still haven't posted, I
notice 8^) work, then my guess (and without the code itself, a guess is
the best I can do) is that it is either something like what I mentioned
above regarding the "-Bsymbolic" switch or it is some key EntireX
library that you had omitted ("mutantstubs" in particular looks like it
might refer to some way to mutate DCOM activations into ELF shared lib
operations, but that's just guessing based on a name.  The "rpcrt4" and
"ole32" libraries are others that might be key to this, again, just
looking at the names and guessing as to their meaning).

> LIBRARY_LINKER_NAME = g++
> 
> LIBRARY_LD_FLAGS = \
>           -g \
>           -shared \
>           -Wl,-Bsymbolic,-t
> 
> LIBRARY_LINKLIBS = \
>           -L$(DCOLIB) \
>           -lmutantstubs \
>           -L$(DCOLIB) \
>           -lole32 \
>           -lrpcrt4 \
>           -lntrtl \
>           -lmutant \
>           -lcoolmisc \
>           $(TRACELIB) \
>           -lpthread \
>           -lc \
>           -ldl \
>           `gcc --print-libgcc-file`
> 
> $(OUTFILE): $(SOBJS)
>   $(LIBRARY_LINKER_NAME) -o$(OUTFILE) $(LIBRARY_LD_FLAGS) \
>        $(SOBJS) $(LIBRARY_LINKLIBS) $(LIBS)
> 
Well, glad to hear that you seem to have solved your problem.  If the
EntireX folks give you a definitive explanation what the base problem
was, please post it here.  I hate it when I get my teeth into a problem
and then never find out what the ultimate solution (and reason for that
solution) is.

Regards,
        John Griggs

------------------------------

From: "Paul Pluzhnikov" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.lisp
Subject: Re: A challenging problem...
Date: Tue, 05 Dec 2000 15:21:36 GMT

"Kaelin Colclasure" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Duane Rettig <[EMAIL PROTECTED]> writes:
> > It is also possible to dynamically load and unload shared-libraries
> > during normal program execution, but I am not sure what ptrace
> > implementations do with these dynamics.
>
> That's a good point. I'm pretty sure prex scans the ELF executable
> for .so dependencies and recursively loads and scans all of them for
> probes as well -- but I don't know *what* it does when the code
> dlopen's a .so that contains probes. Probably nothing. :-/
>

I have not tried this, but prex could easily get notified about .so
load/unload
events on Solaris via the runtime linker-debugger interfaces:
http://docs.sun.com/ab2/coll.45.13/LLM/@Ab2PageView/10995?Ab2Lang=C&Ab2Enc=i
so-8859-1

I'd be surprized if it actually did nothing.



------------------------------

From: "David Zada" <[EMAIL PROTECTED]>
Subject: Remapping memory in the kernel space
Date: Tue, 5 Dec 2000 18:58:55 +0200

Hi !

How can i map my memory in the linux, to allocate  a region of memory in
specific address that i decide , that any others process can't overwrite
this region of memory  ? ( i know in the other O.S you just give order to
the linker to save some region of memory for you in specific
address , i wonder if there any way in linux to do it ).
I must to notify that this allocation done in my module , and i want that
this allocation will be in the kernel space memory


Sincerely,
David



------------------------------

From: David Vidal Rodriguez <[EMAIL PROTECTED]>
Subject: Problem with LVM and LILO
Date: Tue, 05 Dec 2000 18:36:09 +0100

Hi everyone!
I have recently migrated my partition-based Linux system to a lvm-based
one (Logical Volume Management). Everithing works (surprisingly) fine,
but my LILO won't recognize my LV's as bootable devices. It says
something like:

"Reading boot sector from /dev/dsk/boot...
 Merging it with /boot/boot.b
 Don't know how to handle device 3a01",

where the number points exactly to one of my LV's (in major-minor
notation). The error appears (as I've seen when running LILO with the -v
-v -v -v -v option) while caching new disk devices.
My question is: Does a newer version of LILO support LVM, or have
I fallen into a trap and my Linux has become unbootable forever?

I would be glad of seeing an answer soon, 'cause it urges.

Thanks in advance,
--
  ------------------------------------------------------------------------
 David Vidal R. ([EMAIL PROTECTED])




------------------------------

From: [EMAIL PROTECTED]
Subject: linuxthread manager and SIGINT
Date: Tue, 05 Dec 2000 17:40:39 GMT
Reply-To: [EMAIL PROTECTED]

I am running a linuxthreaded application.  When I try
to send SIGINT to the manager thread using kill it never gets *sent*.
However if I try the same with say SIGSTOP it gets sent.

Does anyone know why this is??

Thank you,
Pete.


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Duane Rettig <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.lisp
Subject: Re: A challenging problem...
Date: 05 Dec 2000 09:26:55 -0800

"Paul Pluzhnikov" <[EMAIL PROTECTED]> writes:

> "Kaelin Colclasure" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Duane Rettig <[EMAIL PROTECTED]> writes:
> > > It is also possible to dynamically load and unload shared-libraries
> > > during normal program execution, but I am not sure what ptrace
> > > implementations do with these dynamics.
> >
> > That's a good point. I'm pretty sure prex scans the ELF executable
> > for .so dependencies and recursively loads and scans all of them for
> > probes as well -- but I don't know *what* it does when the code
> > dlopen's a .so that contains probes. Probably nothing. :-/
> >
> 
> I have not tried this, but prex could easily get notified about .so
> load/unload
> events on Solaris via the runtime linker-debugger interfaces:
> http://docs.sun.com/ab2/coll.45.13/LLM/@Ab2PageView/10995?Ab2Lang=C&Ab2Enc=i
> so-8859-1
> 
> I'd be surprized if it actually did nothing.

I believe you are both correct.  Evidence for this is shown below.
Having said this, though, I cannot do this in all debug systems; I
am not sure whether the problems are in dlopen, gdb/dbx, or ptrace.
So I usually only do this on systems which I have learned to trust
as having gotten it right.

The big idea is that when a breakpoint is set that doesn't yet exist,
it is deferred.  The loading of the first library which contains
that entry point will establish an address for the breakpoint, and
insert the actual breakpont at that address.  This must occur with
some hook at dlopen time, or else the breakpoint would never have been
set in the example below. 

I have never had occasion to try dlclosing a library with a breakpoint
in it, so I don't know whether dlclose works as it intuitively should
(i.e. hooking the deletion/re-deferral of breakpoints upon unloading
of a library).


% gdb lisp
Detected 64-bit executable.
Invoking /opt/langtools/bin/gdb64.
HP gdb 2.0
Copyright 1986 - 1999 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 2.0 (based on GDB 4.17-hpwdb-980821)
Wildebeest is free software, covered by the GNU General Public License, and
you are welcome to change it and/or distribute copies of it under certain
conditions.  Type "show copying" to see the conditions.  There is
absolutely no warranty for Wildebeest.  Type "show warranty" for details.
Wildebeest was built for PA-RISC 2.0 (wide), HP-UX 11.00.
..
(gdb) break lisp_main
Breakpoint 1 (deferred) at "lisp_main" ("lisp_main" was not found).
Breakpoint deferred until a shared library containing "lisp_main" is loaded.
(gdb) info break
Num Type           Disp Enb Address    What
1   breakpoint     keep n   (deferred) in lisp_main
(gdb) run -I dcl
Starting program: /acl/duane/acl61/src/lisp -I dcl

Breakpoint 1, lisp_main (argc=3, argv=0x80000001000248c0, 
    envp=0x800003ffefff05a8) at c/startup.c:373
373         int startup_debug = (char *)getenv("ACL_STARTUP_DEBUG") != NULL;
Current language:  auto; currently c++
(gdb) info break
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x800003ffefcce478 in lisp_main at c/startup.c:373
        breakpoint already hit 1 time
(gdb) 


-- 
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   [EMAIL PROTECTED] (internet)

------------------------------

From: Brian Horton <[EMAIL PROTECTED]>
Subject: Re: Can I use alloca() in a kernel module?
Date: Tue, 05 Dec 2000 12:24:12 -0600

Ah.. yup, thats the problem -- trying for too much space.

thx!  .bri.

Andi Kleen wrote:
> 
> Brian Horton <[EMAIL PROTECTED]> writes:
> 
> > I'm trying to use alloca() in a kernel module -- is that allowed? I'm
> > blowing the box up (clears the screen and reboots...) using alloca's,
> > tho doing kmalloc/kfree work. (I don't THINK that I've got a leak, but
> > yes, I'm looking into that as well. :-)
> 
> alloca() should work. But remember that the kernel stack
> is very limited: ~6K on IA32 and you need to keep some space for
> interrupts so you should not use more than 3-4K. So usually it is a better
> idea to use kmalloc() or get_free_pages() for bigger allocations.
> 
> You're probably overflowing your stack.
> 
> -Andi

------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: linuxthread manager and SIGINT
Reply-To: [EMAIL PROTECTED]
Date: Tue, 05 Dec 2000 18:50:53 GMT

On Tue, 05 Dec 2000 17:40:39 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>I am running a linuxthreaded application.  When I try
>to send SIGINT to the manager thread using kill it never gets *sent*.
>However if I try the same with say SIGSTOP it gets sent.
>
>Does anyone know why this is??

Don't send signals to the thread manager, it's pointless. If you send it a
fatal signal, it will die causing your application to deadlock as thread
manager requests go unanswered.

------------------------------

From: Bruce Stephens <[EMAIL PROTECTED]>
Subject: Re: Problem with LVM and LILO
Date: 05 Dec 2000 19:02:24 +0000

David Vidal Rodriguez <[EMAIL PROTECTED]> writes:

> I have recently migrated my partition-based Linux system to a lvm-based
> one (Logical Volume Management). Everithing works (surprisingly) fine,
> but my LILO won't recognize my LV's as bootable devices. It says
> something like:
> 
> "Reading boot sector from /dev/dsk/boot...
>  Merging it with /boot/boot.b
>  Don't know how to handle device 3a01",
> 
> where the number points exactly to one of my LV's (in major-minor
> notation). The error appears (as I've seen when running LILO with
> the -v -v -v -v -v option) while caching new disk devices.  My
> question is: Does a newer version of LILO support LVM, or have I
> fallen into a trap and my Linux has become unbootable forever?

I don't know.  Try the LVM web site, and the mailing lists there.
Personally, I kept my root partition and /boot as ordinary partitions.
If you have any ordinary partitions (for example, the root partition),
you should be able to stick kernel images on one of those and use
LILO.  Even an MSDOS partition ought to work, I think, so long as
you're careful not to defragment the partition.

------------------------------

From: Eric Taylor <[EMAIL PROTECTED]>
Subject: Re: how to rebuild tcp code
Date: Tue, 05 Dec 2000 19:14:27 GMT

peter@nospam wrote:
> 
> In article <[EMAIL PROTECTED]>, Rex says...
> 
> >to set
> >echo 42 > /proc/sys/net/ipv4/tcp_retries2
> >
> 
> Rex,
> does one need to re-start the network on linux after modifying
> those parameters for them to take effect?
> 
> thanks,
> peter

I tried this without restart, it worked. I watched
it get larger than 15, and when it hit 42 it did
the disconnect same as before when it was 15.

ET

------------------------------

From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: how to rebuild tcp code
Date: 05 Dec 2000 20:45:55 +0100

Eric Taylor <[EMAIL PROTECTED]> writes:

> 
> I tried this without restart, it worked. I watched
> it get larger than 15, and when it hit 42 it did
> the disconnect same as before when it was 15.

There is nothing like a "restart" in Linux networking. Only a few parameters 
(like e.g. the socket buffer sizes) just need a reopen of a particular
socket so you would need to restart the program or inetd. 

-Andi


------------------------------


** 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
******************************

Reply via email to