Linux-Development-Sys Digest #186, Volume #8 Mon, 2 Oct 00 15:13:16 EDT
Contents:
Block Device Help Please ("[EMAIL PROTECTED]")
Re: How to load shared libs at runtime? (Markus Kossmann)
Re: new windowing system (Drazen Kacar)
Re: How to load shared libs at runtime? ("Peter Koch")
Re: new windowing system (Rasputin)
extend ethernet header to 18 bytes? (NortonNg)
Can Intel Ethernet Express 100pro do direct copy between NIC? (NortonNg)
Re: extend ethernet header to 18 bytes? (Lew Pitcher)
Re: How to load shared libs at runtime? (James Cownie)
Re: vm86 system call ("andrew.betts")
Re: extend ethernet header to 18 bytes? (Kaz Kylheku)
Re: Linux Stack Sizes? (0/1) ("Paul D. Smith")
Re: How to load shared libs at runtime? (Philip Armstrong)
Re: extend ethernet header to 18 bytes? (Frank Sweetser)
Re: new project for linux in idea..... (Nix)
----------------------------------------------------------------------------
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: Block Device Help Please
Date: Mon, 02 Oct 2000 17:17:24 +0200
Hi ,
Can a device driver guru please help me with this.
I'm Writing a block device driver in linux,
A real simplified verison of the code is
//BLKSIZE = 1024
void request_block(void) // less kernel 2.2.32
{
INIT_REQUEST; // and all that protection
if (CURRENT->cmd = read)
memcpy(CURRENT->buffer,my_input_buffer,BLKSIZE);
if (CURRENT->cmd = write)
memcpy(my_input_buffer,CURRENT->buffer,BLKSIZE);
end_request(1);
}
CURRENT->current_no_sectors is 2.
I'm only putting 1024 bytes in the buffer.
When I read the device it gives me only every second 1024 bytes.
If I pump in more than 1024 eg 2048 ,
there are problems with stability.
Can Any on please Help me.
Thanks,
Richard.
------------------------------
From: Markus Kossmann <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to load shared libs at runtime?
Date: Mon, 02 Oct 2000 08:04:42 +0200
Peter Koch wrote:
>
> I'm quite a rookie concerning linux programming, so this question may sound
> stupid.
>
> I am considering to port an application from win32 to linus. I need the
> ability to load a shared library at runtime and find the address of a
> function within it. Can somebody point me out what functions I need for
> this?
man dlopen
--
Markus Kossmann
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Drazen Kacar)
Crossposted-To: comp.os.linux.x,comp.windows.x
Subject: Re: new windowing system
Date: 2 Oct 2000 16:05:18 GMT
Christopher Browne wrote:
> The default configuration rejects IP-based connections (see your
> /etc/orbitrc file) in favor of Unix Stream files.
>
> Which means that you're _sort of_ right.
>
> I'd very much like to see services be designed to actually be network
> "enabled;" the more that happens, the more useful it should become.
> But I don't think it's there yet.
I think they were enebled by default and then security freaks had
something against it. IPv4 should be stable. There is some IPv6 support,
but I'm not sure if that's finished.
--
.-. .-. I don't work for my employer.
(_ \ / _)
| [EMAIL PROTECTED]
| [EMAIL PROTECTED]
------------------------------
From: "Peter Koch" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to load shared libs at runtime?
Date: Mon, 2 Oct 2000 18:48:03 +0200
"Markus Kossmann" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:[EMAIL PROTECTED]...
> Peter Koch wrote:
> >
> > I'm quite a rookie concerning linux programming, so this question may
sound
> > stupid.
> >
> > I am considering to port an application from win32 to linus. I need the
> > ability to load a shared library at runtime and find the address of a
> > function within it. Can somebody point me out what functions I need for
> > this?
> man dlopen
>
> --
> Markus Kossmann
> [EMAIL PROTECTED]
Thanks, but there are no "man" pages available for these functions (I'm
using SuSE 7.0). I found the necessary declarators in /usr/include/dlfcn.h
meanwhile however and think I can work with this. Seems the tricky part of
linux development is getting used to poor documentation.
Peter Koch
------------------------------
From: [EMAIL PROTECTED] (Rasputin)
Crossposted-To: comp.os.linux.x,comp.windows.x
Subject: Re: new windowing system
Reply-To: [EMAIL PROTECTED]
Date: Mon, 02 Oct 2000 16:55:43 GMT
[EMAIL PROTECTED] <Christopher Browne> wrote:
>In our last episode (Mon, 02 Oct 2000 13:25:07 GMT),
>the artist formerly known as Rasputin said:
>>[EMAIL PROTECTED] <Juliusz Chroboczek> wrote:
>>>Nix <$}xinix{[email protected]>:
>>As far as I can make out, all CORBA objects in GNOME are run
>>on the localhost anyway, so what is the benefit of using a
>>platform-independant system like CORBA for stuff like cut-n-paste?
>>It just looks like a lot of unnecessary overhead from here.
>>
>>GNOME doesn't seem to be any more a 'Network Object Model Environment'
>>than X is.
>>
>>Any URLs proving me wrong gratefully recieved...
>
>The default configuration rejects IP-based connections (see your
>/etc/orbitrc file) in favor of Unix Stream files.
>
>Which means that you're _sort of_ right.
>
>I'd very much like to see services be designed to actually be network
>"enabled;" the more that happens, the more useful it should become.
>But I don't think it's there yet.
Reading over my earlier post, I don't want to give the impression
that I'm resurrecting the:
'please recompile X to rip out the network bloat'
thread, I just wondered what developments were underway to take
advantage of the networking possibilites of CORBA.
Having a framework in place will hopefully make a few
cool things possible in the future... 'clipboard servers' and so on.
--
Rasputin.
Jack of All Trades - Master of Nuns.
------------------------------
From: NortonNg <[EMAIL PROTECTED]>
Subject: extend ethernet header to 18 bytes?
Date: Mon, 2 Oct 2000 17:21:40 +0000 (UTC)
According to RFC 894 Ethernet Encapsulation header is 14 bytes,
but i need to extend it to 18 bytes for setting some flag for local
communication. Is it possbile? How can i do it? modify the device driver
codes??
jkng
------------------------------
From: NortonNg <[EMAIL PROTECTED]>
Subject: Can Intel Ethernet Express 100pro do direct copy between NIC?
Date: Mon, 2 Oct 2000 17:25:34 +0000 (UTC)
I know that DEC 21xxx chip NIC using tulip.o device driver can do the
direct DMA copy packet between NICs, i wonder to know how about the
Intel Express 100pro? Does anyone know about it?
jkng
------------------------------
From: [EMAIL PROTECTED] (Lew Pitcher)
Subject: Re: extend ethernet header to 18 bytes?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 02 Oct 2000 17:32:17 GMT
On Mon, 2 Oct 2000 17:21:40 +0000 (UTC), NortonNg
<[EMAIL PROTECTED]> wrote:
>
> According to RFC 894 Ethernet Encapsulation header is 14 bytes,
>but i need to extend it to 18 bytes for setting some flag for local
>communication.
>Is it possbile?
Yes, it's possible. However, it's inadvisable to do so, and if you do
make such changes, your changed ethernet won't interoperate with real
ethernet devices (or at least will break the protocols carried in
ethernet packets)
>How can i do it? modify the device driver codes??
Exactly.
>jkng
Lew Pitcher
Information Technology Consultant
Toronto Dominion Bank Financial Group
([EMAIL PROTECTED])
(Opinions expressed are my own, not my employer's.)
------------------------------
From: James Cownie <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to load shared libs at runtime?
Date: Mon, 02 Oct 2000 17:32:44 GMT
Peter Koch wrote:
>
> Thanks, but there are no "man" pages available for these functions (I'm
> using SuSE 7.0). I found the necessary declarators in /usr/include/dlfcn.h
> meanwhile however and think I can work with this. Seems the tricky part of
> linux development is getting used to poor documentation.
Well maybe you just need to install the man pages ?
On my RH system they're all there, e.g.
DLOPEN(3) Linux Programmer's Manual DLOPEN(3)
NAME
dlclose, dlerror, dlopen, dlsym - Programming interface to
dynamic linking loader.
SYNOPSIS
#include <dlfcn.h>
void *dlopen (const char *filename, int flag);
const char *dlerror(void);
void *dlsym(void *handle, char *symbol);
int dlclose (void *handle);
Special symbols: _init, _fini.
DESCRIPTION
dlopen loads a dynamic library from the file named by the
null terminated string filename and returns an opaque
"handle" for the dynamic library. If filename is not an
absolute path (i.e., it does not begin with a "/"), then
the file is searched for in the following locations:
A colon-separated list of directories in the user's
LD_LIBRARY path environment variable.
The list of libraries specified in
/etc/ld.so.cache.
/usr/lib, followed by /lib.
If filename is a NULL pointer, then the returned handle is
for the main program.
External references in the library are resolved using the
libraries in that library's dependency list and any other
libraries previously opened with the RTLD_GLOBAL flag. If
the executable was linked with the flag "-rdynamic", then
the global symbols in the executable will also be used to
resolve references in a dynamically loaded library.
flag must be either RTLD_LAZY, meaning resolve undefined
symbols as code from the dynamic library is executed, or
RTLD_NOW, meaning resolve all undefined symbols before
dlopen returns, and fail if this cannot be done. Option-
ally, RTLD_GLOBAL may be or'ed with flag, in which case
the external symbols defined in the library will be made
available to subsequently loaded libraries.
If the library exports a routine named _init, then that
code is executed before dlopen returns. If the same
library is loaded twice with dlopen(), the same file han-
dle is returned. The dl library maintains link counts for
dynamic file handles, so a dynamic library is not deallo-
cated until dlclose has been called on it as many times as
dlopen has succeeded on it.
Linux 16 May 1995 1
If dlopen fails for any reason, it returns NULL. A human
readable string describing the most recent error that
occurred from any of the dl routines (dlopen, dlsym or
dlclose) can be extracted with dlerror(). dlerror returns
NULL if no errors have occurred since initialization or
since it was last called. (Calling dlerror() twice con-
secutively, will always result in the second call return-
ing NULL.)
dlsym takes a "handle" of a dynamic library returned by
dlopen and the null terminated symbol name, returning the
address where that symbol is loaded. If the symbol is not
found, dlsym returns NULL; however, the correct way to
test for an error from dlsym is to save the result of
dlerror into a variable, and then check if saved value is
not NULL. This is because the value of the symbol could
actually be NULL. It is also necessary to save the
results of dlerror into a variable because if dlerror is
called again, it will return NULL.
dlclose decrements the reference count on the dynamic
library handle handle. If the reference count drops to
zero and no other loaded libraries use symbols in it, then
the dynamic library is unloaded. If the dynamic library
exports a routine named _fini, then that routine is called
just before the library is unloaded.
EXAMPLES
Load the math library, and print the cosine of 2.0:
#include <dlfcn.h>
int main(int argc, char **argv) {
void *handle = dlopen ("/lib/libm.so", RTLD_LAZY);
double (*cosine)(double) = dlsym(handle, "cos");
printf ("%f\n", (*cosine)(2.0));
dlclose(handle);
}
If this program were in a file named "foo.c", you
would build the program with the following command:
gcc -rdynamic -o foo foo.c -ldl
Do the same thing, but check for errors at every step:
#include <stdio.h>
#include <dlfcn.h>
int main(int argc, char **argv) {
void *handle;
double (*cosine)(double);
char *error;
handle = dlopen ("/lib/libm.so", RTLD_LAZY);
if (!handle) {
Linux 16 May 1995 2
fputs (dlerror(), stderr);
exit(1);
}
cosine = dlsym(handle, "cos");
if ((error = dlerror()) != NULL) {
fputs(error, stderr);
exit(1);
}
printf ("%f\n", (*cosine)(2.0));
dlclose(handle);
}
ACKNOWLEDGEMENTS
The dlopen interface standard comes from Solaris. The
Linux dlopen implementation was primarily written by Eric
Youngdale with help from Mitch D'Souza, David Engel,
Hongjiu Lu, Andreas Schwab and others. The manual page
was written by Adam Richter.
SEE ALSO
ld(1), ld.so(8), ldconfig(8), ldd(1), ld.so.info.
Linux 16 May 1995 3
-- Jim
James Cownie <[EMAIL PROTECTED]>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
------------------------------
From: "andrew.betts" <[EMAIL PROTECTED]>
Subject: Re: vm86 system call
Date: Mon, 2 Oct 2000 19:02:17 +0100
Thanks for that.
Try as I might I could not get the new vm86() call to work. But the
vm86old() (via assembly) works fine. What's the diff?
"Tim Roberts" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "andrew.betts" <[EMAIL PROTECTED]> wrote:
> >
> >Can someone explain to me how to execute a code snippet with the vm86
system
> >call.
>
> It's complicated.... There is a package called "lrmi" (Linux real-mode
> interface) that gives some good examples of calling in to the VESA BIOS.
> You might search the web for it; it isn't stored where I originally found
> it. If you have the XFree86 3.3.6 source code, the Savage server includes
> it.
>
> >void somecode() {
> > __asm__(
> > "mov %%ax,%%bx" // or something
> > )
> >}
> >
> >void go()
> >{
> > struct vm86plus_struct vm86s;
> > vm86s.regs.eip=(void*)somecode; ?????
> > vm86(VM86_ENTER,&vm86s);
> >}
>
> This is NOT the way. Remember that V86 mode is NOT 32-bit and is NOT
> protect mode. It is the old 16:16 segmented memory model. Any code you
> compile with gcc is going to be 32-bit protect mode. The opcodes will be
> wrong.
>
> vm86 is primarily useful for two things: executing old DOS .COM and .EXE
> files, with an appropriate loader, and executing code in the ROM BIOSes.
>
> The values you pass to vm86 in the segment registers must be segment
> offsets. This means all code and data must be located in the low megabyte
> of real memory. This requires magic on the part of the application.
>
> >I have tried filling the other segment registers with __USER_DS/CS but
all
> >_appears_ to fail.
>
> Yep. You need to put 16:16 segments in there. To execute the VESA BIOS
at
> linear 000c0000, you'd set CS to C000 and IP to 0.
>
> >And how do return from "somecode" to the line after the syscall?
>
> Do something that causes a trap. You could insert an illegal instruction,
> or an int 3, for example. That causes vm86 to return control to you to
> handle the trap.
> --
> - Tim Roberts, [EMAIL PROTECTED]
> Providenza & Boekelheide, Inc.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: extend ethernet header to 18 bytes?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 02 Oct 2000 18:09:46 GMT
On Mon, 2 Oct 2000 17:21:40 +0000 (UTC), NortonNg <[EMAIL PROTECTED]> wrote:
>
> According to RFC 894 Ethernet Encapsulation header is 14 bytes,
>but i need to extend it to 18 bytes for setting some flag for local
>communication. Is it possbile? How can i do it? modify the device driver
>codes??
You can do that, but then you have to convince every other host on the network
that headers are 18 bytes. Hosts that are not aware of your scheme will simply
see four extra bytes of payload and get confused.
What you should do when you do something like that is use a separate ethernet
protocol number for these special packets. Hosts which don't understand the
modified scheme will just drop such packets, should they ever receive them, due
to their unknown protocol number. The machines that do participate in the
scheme have a way of telling apart regular packets and ``doctored'' packets
based on the protocol num.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: "Paul D. Smith" <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: 02 Oct 2000 14:21:12 -0400
Reply-To: [EMAIL PROTECTED]
%% MeekGeek <[EMAIL PROTECTED]> writes:
m> Incidentally, I could not find an implementation of alloca in the GCC
m> 2.95.2 source code that did not use dynamic allocation from the heap
m> for the memory, using malloc! I'm presuming that I haven't found the
m> right source file, but all of the implementations I found, including
m> inside alloca.c, use malloc for the memory.
Yes, you've not found the right one.
The compiler itself (GCC) uses alloca() in its implementation. The
alloca() you've found in alloca.c is the one that is used in GCC if you
compile it with a compiler that doesn't support alloca(), so you can get
a working GCC (then, I suppose, you could recompile GCC with itself and
it would use the builtin alloca()).
If you go look at _most_ GNU programs, they come with this same alloca.c
to allow them to be built on systems where alloca() isn't available.
The "configure" script checks for a system[*] alloca() and, if it doesn't
exist, compiles and links alloca.c into the resulting program.
[*] Either libc or compiler alloca().
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: [EMAIL PROTECTED] (Philip Armstrong)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How to load shared libs at runtime?
Date: 2 Oct 2000 18:25:42 +0100
In article <8raed7$hg$[EMAIL PROTECTED]>,
Peter Koch <[EMAIL PROTECTED]> wrote:
>"Markus Kossmann" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
>news:[EMAIL PROTECTED]...
>> Peter Koch wrote:
>> > I'm quite a rookie concerning linux programming, so this question
>> > may sound stupid.
>> >
>> > I am considering to port an application from win32 to linus. I need the
>> > ability to load a shared library at runtime and find the address of a
>> > function within it. Can somebody point me out what functions I need for
>> > this?
>> man dlopen
>Thanks, but there are no "man" pages available for these functions (I'm
>using SuSE 7.0). I found the necessary declarators in /usr/include/dlfcn.h
>meanwhile however and think I can work with this. Seems the tricky part of
>linux development is getting used to poor documentation.
Then you probably haven't installed all the documentation that came
with your system. There have been dlopen man pages on every linux
system I've ever used.
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
------------------------------
From: [EMAIL PROTECTED] (Frank Sweetser)
Subject: Re: extend ethernet header to 18 bytes?
Date: 2 Oct 2000 18:40:05 GMT
Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>On Mon, 2 Oct 2000 17:21:40 +0000 (UTC), NortonNg <[EMAIL PROTECTED]> wrote:
>>
>> According to RFC 894 Ethernet Encapsulation header is 14 bytes,
>>but i need to extend it to 18 bytes for setting some flag for local
>>communication. Is it possbile? How can i do it? modify the device driver
>>codes??
>
>You can do that, but then you have to convince every other host on the network
>that headers are 18 bytes. Hosts that are not aware of your scheme will simply
>see four extra bytes of payload and get confused.
and don't forget switches, routers, printers, and anything with
embedded ethernet!
--
Frank Sweetser rasmusin at wpi.edu, fs at suave.net | $ x 10
Full-time WPI Network Tech, Part time Linux/Perl guy |
tmps_base = tmps_max; /* protect our mortal string */
-- Larry Wall in stab.c from the perl source code
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: new project for linux in idea.....
Date: 02 Oct 2000 19:26:06 +0100
[EMAIL PROTECTED] (Bill Touchstone) writes:
> 3) Finally, I would say that if you ever created something to which you
> attached some value, and got to watch it proliferated from computer to computer
> without any showing of expected monetary renumeration, you will understand why
> so many are so upset about this type of technology use.
I've done that and wasn't surprised at all.
So has anyone else who's ever contributed to a free software project.
Hint: `value' != `expectation of remuneration'.
HTH.
--
`Ergotism is what you get if you overuse the word "therefore". Egotism
on the other hand is a form of "I" strain.' --- Paul Martin
------------------------------
** 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
******************************
