Linux-Development-Sys Digest #126, Volume #7 Mon, 30 Aug 99 21:14:33 EDT
Contents:
Re: libc or glibc? (Tristan Wibberley)
Re: Avoid Zombies (Sven Heursch)
Re: why not C++? (Kaz Kylheku)
Re: Problem With dlopen()'d Libraries (David Schwartz)
Re: why not C++? (Andomar)
Re: why not C++? (Johan Kullstam)
Re: Jesus: the ultimate OS (Steve Mading)
Re: why not C++? (Kaz Kylheku)
Re: why not C++? ("Noah Roberts (jik-)")
Re: Problem With dlopen()'d Libraries (Ulrich Weigand)
Re: why not C++? (Kaz Kylheku)
Re: why not C++? (NF Stevens)
Re: why not C++? (NF Stevens)
Re: Avoid Zombies (David Wragg)
Re: Crossing gcc to my new system (Ross Vandegrift)
Getting the Ethernet ID from directly from the network card. (Vincent)
----------------------------------------------------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: libc or glibc?
Date: Tue, 31 Aug 1999 05:53:35 +0100
Reply-To: [EMAIL PROTECTED]
Arthur Chiu wrote:
>
> I'm new to Linux.
>
> People are talking about changing from libc to glibc. I'm using RH5.2. I can find
> descriptions of libc by 'info libc' but get nothing with 'info glibc'. What's the
> difference between libc and glibc?
libc is the name of a library present on all UNIX's. It has a particular
interface. The free software foundation has implemented libc like so
many UNIX vendors - this implementation is called glibc to distinguish
it.
A long time ago (well, a long time in Free Software terms) Linux had
it's own special libc, but the FSF added support for Linux in their
standard source tree, so (almost) everyone has stopped using the old one
- refered to as libc, in favour of the the FSF's better supported one.
It is essentially just a different version - though libc is difficult to
upgrade and RedHat 5.2 uses glibc already :)
--
Tristan Wibberley
------------------------------
Date: Tue, 31 Aug 1999 01:03:51 +0200
From: Sven Heursch <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Avoid Zombies
Kaz Kylheku wrote:
> On Mon, 30 Aug 1999 16:31:41 +0200, Sven Heursch
> <[EMAIL PROTECTED]> wrote:
> >Hello,
> >
> >I have now idea how do avoid Zombies which are created from threads over
> >the pthread_exit() call.
> >Any ideas?
>
> Threads that are not marked detached must be collected with pthread_join().
yes, but I have a thread thats marked as detached! And after the
pthread_exit() call of the thread I got a zombie task struct.
Why?
With processes I can destroy the zombies by calling wait(). Is there a
possibility to do the same with threads?
S. Heursch
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 30 Aug 1999 22:36:35 GMT
On Mon, 30 Aug 1999 22:27:38 GMT, NF Stevens <[EMAIL PROTECTED]> wrote:
>>References also cannot be induced to point to NULL in a strictly-conforming
>>program, which can eliminate a lot of checking of input conditions (or more
>>practically, since most C routines don't check their input parameters
>>anyway, can make the use of such routines much more reliable).
>
>So you cannot then determine what is and what is not a
>conforming program.
The notion of strict conformance is pure standardeze. In the C standard, a
strictly conforming program is defined for the purpose of establishing the
implementation limits. A C implementation is required to accept at least one
strictly conforming program which tests each of the limits.
The notion of strict conformance is of no consequence to the engineer using the
language to make software.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Problem With dlopen()'d Libraries
Date: Mon, 30 Aug 1999 16:28:59 -0700
My personally preferred solution is simply to define an initialization
function in the module (which you have already done, it seems,
'load_module') and pass it a pointer to a function in the main program.
This function serves out all the callbacks by whatever means you prefer.
Beware of C++ name mangling as well. 'extern "C"' is your friend.
DS
[EMAIL PROTECTED] wrote:
>
> Hopefully somebody can help me out with this. I'll even try to be
> clear with what the problem is. (But let me know if there's confusion
> on it...I'm confused enough without everyone else's coconfusion. ;)
>
> What I'm doing is writing a program that can be expanded through the
> use of runtime-linked libraries. It has a lot of things that can be
> expanded, but the problem is consistent across all of them, so I'll
> just give a bit of an example.
>
> The main program dlopen()'s the library, does a dlsym("load_module"),
> and calls the resulting function pointer to allow the library to
> initialize its hooks into the main program. One example of this would
> be adding a new command to a language interpreter. Here are some code
> snippets to help illustrate: (Note that, although the code is C++, I
> have determined that that is not the root of the problem.)
>
> -- main.h --
> class Hash {
> protected:
> // Implementation of a hash table goes here.
> public:
> // Rest of interface, including constructor, et al, goes here.
> add(char *, void *);
> };
>
> extern Hash command_hash;
> ------------
> -- main.cpp --
> #include "main.h"
>
> Hash command_hash;
>
> int main(void) {
> char *libname;
> void *handle;
> void (*func)(void);
>
> libname = getlibname(); // We'll pretend, for the sake of simplicity,
> // that this returns the right thing.
> handle = dlopen(libname);
> func = dlsym(handle, "load_module");
> func();
> return 0;
> }
> --------------
> -- module.cpp --
> #include "main.h"
>
> extern "C" {
> void load_module(void);
> };
>
> void new_command(void) {
> // ~I wanna new command, one that won't crash my box...~
> }
>
> void load_module(void) {
> command_hash.add("NC", (void *) new_command);
> }
> ----------------
>
> This works perfectly well on my IRIX 6.2 box, but Linux won't allow the
> dlopen() to work, complaining about command_hash being an unresolved
> symbol. A call to dlerror() immediately after the dlopen() will
> return "undefined symbol: command_hash". Is there a way to let dlopen
> ()'d libraries use symbols from the dlopen()ing program? Thanks for
> any help I get on this. It is greatly appreciated.
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
Date: Mon, 30 Aug 1999 23:14:44 +0200
From: Andomar <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Don Waugaman wrote:
>
> In article <[EMAIL PROTECTED]>,
> NF Stevens <[EMAIL PROTECTED]> wrote:
> >[EMAIL PROTECTED] (Don Waugaman) wrote:
>
> [ snipped - null references not allowed, and I moved the question below
> to before the program for the sake of readability ]
>
> >Which part of the this program is not strictly
> >conforming?
>
> >#include <cstdio>
>
> >char *GetAddress (char &c)
> >{
> > return &c;
> >}
>
> >int main (void)
> >{
> > char *p = NULL;
> > printf ("%p\n", GetAddress (*p));
> ^^ deref'ing a NULL pointer
> > return 0;
> >}
>
How else would you pass the char at address 0 ? I mean,
there must be a way to allow that.
The reference construct will block direct NULLS.
i.e. GetAddress(NULL) will fail. The reference
makes sure you are at least passing a variable.
So there is some form of extra protection.
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 30 Aug 1999 18:09:35 -0400
[EMAIL PROTECTED] (Don Waugaman) writes:
> In article <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
> >From: [EMAIL PROTECTED] (Don Waugaman) wrote:
> >>C++ I/O is considerably more powerful and less error-prone than the
> >>various C equivalents. It provides a number of capabilities that are
> >>extremely difficult to engineer code for in C:
>
> >>- type-safe I/O
>
> >If you want a typesafe language don't use a typed one. Besides which you'll
> >soon know if you've sent the wrong type to printf/scanf.
>
> I don't understand the first sentence above. C++ is a typed language,
> and I/O in C++ is type-safe.
C++ is a *statically* typed language. C++ is typed during compile.
you can always lie to the compiler with a cast. furthermore, a
runaway pointer can always point to something not of its (the
pointer's) declared type. at run-time C++ will blithly dispatch the
wrong print function. C++ is not type safe.
more to the point, once C++ has compiled, you lose a great deal of
type information. printf is not extendable to your own new types.
RTTI doesn't go far enough. C++ io really sucks when it comes to
variable formating of the same data type.
printf("%6.2f %#8.4g\n", a, b);
is somewhat painful with C++ iostreams. C and C++ lose type
information when calling via varargs, hence fixing printf would be
difficult.
compare this to a dynamically typed language such as lisp. the
common-lisp format statement is the analog to C/C++ printf. however,
since lisp variables carry both their value *and* their type, format
knows the default print form. you get the ease of use of printf with
the extensibility of iostreams. (this involves some overhead, on the
other hand you get fewer boneheaded mistakes. lisp can also be
persuaded to assume a particular type and open code for efficiency
when needed.)
in lisp format, the ~A printer uses the default printer (which is a
method you bind to the class). thus you can write
(format t "~A ~A ~A~%" 1 1.2 (complex 1.0 3.4))
and ~A dispatches to the proper printer for the type of variable -
here integer float and complex respectively. you can define a printer
for any class.
> There's no guarantee that "you'll soon know" that you have mismatched
> format strings, particularly as such strings become more complex via the
> maintenance process. As a general principle, I prefer that errors be
> caught at compile time, as early in the process as possible, rather than
> tested out during the debugging stage.
>
> >>- I/O of user-defined types is syntactically equivalent to that of
> >> builtin types
>
> >And fprintf and sprintf arn't syntactically equivalent to printf?
>
> Given an object of a certain type (say, ComplexNumber) with a defined
> output inserter operator (i.e. ostream& operator<<(ostream&, ComplexNumber))
> you send it to cout by:
> ComplexNumber my_complex;
> cout << my_complex;
> This looks just like how you send an object of a builtin type to cout:
> int my_int;
> cout << my_int;
> Using printf, and substituting a C struct for the ComplexNumber type, you
> would have to output the elements individually:
> printf("(%f,%f)", my_complex.real, my_complex.imaginary);
> for which the syntax is a lot different than outputting an int:
> printf("%d"), my_int);
> The format string argument makes the printf family of functions look
> similar, but the fact that you have to use several different kinds of
> functions which have to be selected differently based on the type of
> data sink makes it cumbersome to redirect I/O from/to a different family
> of functions. In C++, it's done for you via the streambuf type (the
> back end of istream/ostream) and the virtual function mechanism.
on the other hand, if you are not satisfied with the output that >>
gives you, you have a more difficult time altering it than with printf
and a built-in type.
> I might add that there are some hidden gotchas in the use of printf
> format strings with regards to similar scanf format strings - for example,
> %f can write a double, but it can only read a float. In C++, the coder
> just writes so that whatever is output by << can be input by >>.
>
> >>- redirecting I/O to user-created data sinks / data sources is
> >> syntactically identical to I/O builtin data sinks/streams
>
> >Ah , so fprintf(file_ptr,"... is different to fprintf(stdout,"..." ?
>
> No, but fprintf(file_ptr, ...) is different from sprintf(string, ...),
> and you have to know the difference between the different sinks you are
> using for output. For that matter, using printf(...) doesn't allow you
> to redirect the data in any way ("Printf considered harmful!" :-)
>
> >>- facilitated error checking, including delaying error checking/reporting
>
> >So wrap printf etc in a wrapper function.
>
> And call the wrapper rather than printf. However, you can't get a
> library to use your wrapper - it will still be calling printf.
>
> (Yes, I like open source software too, and using it would allow changes
> to the library. However, I also like to spend time at home with my wife,
> and going through a library changing printf() calls takes away from the
> time I can spend with her.)
this is where a dynamic language can really help. C++ has its place,
but it's not as flexible as common lisp. you can, on the fly, at
runtime, redefine much more in lisp than in C++. this would be a
disaster if it weren't for the support environment lisp provides (good
error messages, automatic garbage collection, dynamic types with check
and dispatch, debugger, run-time code evaluation).
i use many languages, mostly C, C++, matlab and lisp. each has its
place. it helps to know more than one so you can choose according to
that language's strengths.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: Steve Mading <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Jesus: the ultimate OS
Date: 30 Aug 1999 23:29:50 GMT
In comp.os.linux.advocacy Nix <$}xinix{[email protected]> wrote:
: Nix <$}xinix{[email protected]> writes:
:> "Christopher R. Thompson" <[EMAIL PROTECTED]> writes:
:> > Java will always require a
:> > translator and therfore an inefeciancy.
:>
:> Wrong:
: Pardon me, you are right, but it does not negate my point.
: *All* languages save for raw opcodes require translators. They're called
: `compilers' or `assemblers'. Yes, they take time to run, and thus are
: `an inefficiency'. But until someone builds a CPU which natively parses
: Java source[1] and runs the code, this will remain true of Java.
: [1] note that handling the bytecode isn't enough, as you still need a
: translator to get it that far, and the whole point of this is to
: avoid translators, as they are `inefficient'.
Are you *trying* to advocate having everyone manually toggle bits to
create machine code in hardware? Because that's what it sounds like.
All languages have to have translators. It's just a question of when
the translation occurs: Just once, when the programmer is making it,
in which case it's a 'compiler', or every time it is run, in which
case it's an interpeter. (Or once per user session, in which case
it's a JIT compiler.)
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 30 Aug 1999 22:02:19 GMT
On Mon, 30 Aug 1999 21:56:35 GMT, Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>On Mon, 30 Aug 1999 23:14:44 +0200, Andomar <[EMAIL PROTECTED]> wrote:
>>The reference construct will block direct NULLS.
>>i.e. GetAddress(NULL) will fail. The reference
>>makes sure you are at least passing a variable.
>>So there is some form of extra protection.
>
>You can do almost as well with an assertion. If the function call passes a null
>constant, and the target function checks for it. In any run of the program in
>which the function call is actually executed, the assertion will go off, so
>it's a simple matter of coverage.
Oh and a little foonote: sure the reference parameter blocks constant
nulls. But it also silently steals pointers to objects. Because
references exist, you cannot be sure whether, after the call
#undef foo
foo(x);
the object x still has the same value as it did before the call.
In the face of the new possibilities for error, the static diagnosis of
foo(NULL);
is a worthless consolation prize.
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
From: "Noah Roberts (jik-)" <[EMAIL PROTECTED]>
Date: 30 Aug 1999 16:20:43 -0700
[EMAIL PROTECTED] (Phil Hunt) writes:
> In article <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] writes:
> > My point was that he's added even more pointless and obscure things to C++
> > such as reference variables. What the hells the point of those when you
> > already have pointers? Also overloading the << and >> to produce a less
> > powerfull (for most things) I/O system than *printf and *scanf and to
> > produce confusing statements like "cout << 2 << 3". In general IMO
> > operator overloading produces impossible to follow code and the syntax for
> > declaring an overloaded operator is a joke as are other things such as
> > class inheritance. Also why give constructor functions the same name as the
> > class and make destructors have a tilda in front? Even worse the copy
> > function is the same as the constructor except it takes an argument!
> > Whats wrong with constructor() , destructor() and copy() for chrissake??
> > I could go on but whats the point. C++ is a dogs dinner like I said before.
>
> Since you feel like that, may I suggest you design something better.
Something better has already been created....Objective-C.
------------------------------
From: [EMAIL PROTECTED] (Ulrich Weigand)
Subject: Re: Problem With dlopen()'d Libraries
Date: 31 Aug 1999 02:16:46 +0200
[EMAIL PROTECTED] writes:
>This works perfectly well on my IRIX 6.2 box, but Linux won't allow the
>dlopen() to work, complaining about command_hash being an unresolved
>symbol. A call to dlerror() immediately after the dlopen() will
>return "undefined symbol: command_hash". Is there a way to let dlopen
>()'d libraries use symbols from the dlopen()ing program? Thanks for
>any help I get on this. It is greatly appreciated.
'man dlopen' says:
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.
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-7688
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 30 Aug 1999 21:56:35 GMT
On Mon, 30 Aug 1999 23:14:44 +0200, Andomar <[EMAIL PROTECTED]> wrote:
>The reference construct will block direct NULLS.
>i.e. GetAddress(NULL) will fail. The reference
>makes sure you are at least passing a variable.
>So there is some form of extra protection.
You can do almost as well with an assertion. If the function call passes a null
constant, and the target function checks for it. In any run of the program in
which the function call is actually executed, the assertion will go off, so
it's a simple matter of coverage.
If the value is dynamic, then the error hard to catch whether a pointer or
reference receives the value.
------------------------------
From: [EMAIL PROTECTED] (NF Stevens)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Mon, 30 Aug 1999 22:27:39 GMT
Andomar <[EMAIL PROTECTED]> wrote:
>He means the pointer can't be null, like in:
>
>void my_function( char** str ) { ... }
>
>char **i_am_dumb = NULL;
>my_function( i_am_dumb );
>
>
>I.e., with references you can pass a NULL,
>but never a NULL pointer.
>
>The equivalent with references is:
>
>void my_function( char*& str ) { ... }
>
>You can see that you cannot fool the new
>my_function into taking a NULL pointer.
char **a = NULL;
my_function (*a);
This seems to me to do the trick.
The reference is only syntactic sugar. It merely
calls the pointer you pass to the function by
a different name. There will be no difference in the
assembler generated by the two notations. The
purported guarantee is worthless.
Norman
------------------------------
From: [EMAIL PROTECTED] (NF Stevens)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Mon, 30 Aug 1999 22:27:38 GMT
[EMAIL PROTECTED] (Don Waugaman) wrote:
>In article <[EMAIL PROTECTED]>,
>NF Stevens <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] (Don Waugaman) wrote:
>
>[ snipped - null references not allowed, and I moved the question below
>to before the program for the sake of readability ]
>
>>Which part of the this program is not strictly
>>conforming?
>
>>#include <cstdio>
>
>>char *GetAddress (char &c)
>>{
>> return &c;
>>}
>
>>int main (void)
>>{
>> char *p = NULL;
>> printf ("%p\n", GetAddress (*p));
> ^^ deref'ing a NULL pointer
>> return 0;
>>}
>
>This program dereferences a NULL pointer where I've noted above. It is
>legal by the standard for the compiler to pass the address from p through
>to create the reference parameter c because p cannot be NULL in a
>strictly conforming program - dereferencing a NULL pointer is undefined
>behavior and illegal in a strictly conforming program.
The original quote to which I replied was
>References also cannot be induced to point to NULL in a strictly-conforming
>program, which can eliminate a lot of checking of input conditions (or more
>practically, since most C routines don't check their input parameters
>anyway, can make the use of such routines much more reliable).
So you cannot then determine what is and what is not a
conforming program. The guarantee of having a valid object
to work with is no more watertight than having an interface
definition which states that a function may not be passed
a NULL pointer.
Norman
------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Subject: Re: Avoid Zombies
Date: 31 Aug 1999 00:07:29 +0000
[EMAIL PROTECTED] (Kaz Kylheku) writes:
> On Mon, 30 Aug 1999 16:31:41 +0200, Sven Heursch
> <[EMAIL PROTECTED]> wrote:
> >I have now idea how do avoid Zombies which are created from threads over
> >the pthread_exit() call.
> >Any ideas?
>
> Threads that are not marked detached must be collected with pthread_join().
True, but this has nothing to do with zombies -- LinuxThreads has a
separate manager thread that reaps the zombies produced when kernel
threads exit almost immediately. If it isn't doing this, something is
wrong (it sounds like it could be a LinuxThreads bug, but there isn't
enough information given to know).
Regards,
David Wragg
------------------------------
From: Ross Vandegrift <[EMAIL PROTECTED]>
Crossposted-To: gnu.gcc.help
Subject: Re: Crossing gcc to my new system
Date: Mon, 30 Aug 1999 20:50:51 -0100
Reply-To: [EMAIL PROTECTED]
> On Tue, 24 Aug 1999 22:47:15 -0100, Ross Vandegrift <[EMAIL PROTECTED]>
> wrote:
>
> >So I installed what one might call a "development" suite subset of
> >Slackware 4.0 on a spare partition, and began compiling cross compilers
> >to generate i586-pc-linux-gnu code on an i586-pc-linux-gnulibc1 machine.
>
> As I understand, you installed a 'native i586-pc-linux-gnu'
> host/target toolset on a 'i586-pc-linux-gnulibc1' host ? And not
> booted the libc6-based Slackware 4.0 first?
No, I installed a Slackware-4.0 (linux-gnulibc1) host. Then I
configured and compiled gcc to produce linux-gnu code. Also, I didn't
install the libc6 Slackware packages - it was pure gnulibc1.
> You don't now have a cross-compiler, but a native 'i586-linux-gnu'
> toolset running under a 'i586-linux-gnulibc1' system... The
> libc6-binaries can be run under a libc5-based system, if the shared
> libs and the dynamic linker for libc6 are added on the libc5 system...
> This is just the same kind of thing as running SCO 3.2 or SVR4
> binaries under the Linux-ibcs2-emulation.
see above. Sorry for being unclear in my original post.
> > Now I have a usable system up, with the exception of gcc. gcc is being a
> >real pain.I tried the obvious thing first - configuring it straight up as
> >a native compiler,
[snip]
> --build=i586-linux-gnulibc1 --host=i586-linux-gnulibc1 \
> --target=i586-linux-gnu --enable-shared
These are the exact options I used to compile the cross-compiler.
> install the target system's glibc-2.x headers and libs at:
>
> /usr/local/i586-linux-gnu/...
This could be my problem. In /usr/local/i586-pc-linux-gnu/..., I
symlinked lib and include to the respective directories in the root of
my new distribution. This is what I had done before with The Hurd, and
it worked, so I simply assumed that to be correct. Should I try simply
copying the necessary headers and libraries into those directories?
> You tried to make a native GCC for 'i586-pc-linux-gnu' on a
> 'i586-pc-linux-libc1' build machine. To get this happen, you should
> have the 'i586-linux-gnulibc1-to-i586-linux-gnu' cross-compiler (the
> GCC-driver having the name 'i586-pc-linux-gnu-gcc') already built and
> ready. Then this could have happened nicely... The situation is quite
> the same as building a native Win32, DOS, FreeBSD etc. compiler under
> Linux...
Hmm, but I had an i586-pc-linux-gnu-gcc that compiled libc6 binaries
correctly. Is it possible the library problem I mentioned above
contributed to this not working? Are there any common reason gencheck
will dump core?
Thanks,
Ross
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: Vincent <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.development,linux.dev.kernel
Subject: Getting the Ethernet ID from directly from the network card.
Date: Mon, 30 Aug 1999 15:50:32 +0200
HI.
I'm developping a driver that it must getting the Ethernet ID directly
on the network card.
I found all network cards this their physical address in my PC but where
is the ethernet number ??? What address ?
Thanks.
--
=========================================
DEVERRE Vincent - MCII : [EMAIL PROTECTED]
=========================================
------------------------------
** 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
******************************
