Linux-Development-Sys Digest #860, Volume #6 Tue, 22 Jun 99 14:14:40 EDT
Contents:
Re: Help with RedHat 5.2 initrd.img file (Villy Kruse)
Re: Linux uid limits! (Johan Kullstam)
PCNFS (Merryweather Management Systems Ltd.)
Re: using C++ for linux device drivers (Don Waugaman)
Re: using C++ for linux device drivers (Frank Sweetser)
Re: using C++ for linux device drivers (Don Waugaman)
[CONTRACT] kernel programming tutorials (Gary Lawrence Murphy)
Re: Linux uid limits! (bill davidsen)
Re: Red Hat 6.0 not fscking the root partition! (Ronald Cole)
Re: Making dynamic libraries (David Fox)
Re: Linux uid limits! (Georg Acher)
Re: Problems reading CD created under Win9x (Rod Smith)
Re: Making dynamic libraries (mongoose)
Re: Difficulty in compiling kernel 2.2.10 (Bob Tennent)
Re: WinModems and Linux ("James Addison")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: Help with RedHat 5.2 initrd.img file
Date: 17 Jun 1999 09:13:42 +0200
In article <7k8rca$anl$[EMAIL PROTECTED]>,
Leslie Smith <[EMAIL PROTECTED]> wrote:
>Dose anyone know how to make a the initrd.img file, also could
>anyone tell me what is in the file ?
>ie. RedHat initrd.img file.
1) mkinitrd
2) A ramdisk file system for loading a scsi driver module before
mounting the root file system. This avoids the chicken and egg
problem that youy need access to the disk before you can load the
module that is required to access the disk, etc...
Villy
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Linux uid limits!
Date: 22 Jun 1999 09:38:24 -0400
[EMAIL PROTECTED] (Georg Acher) writes:
> IMHO nobody is thinking about the possibility that an int can be
> 16bit when programming for Linux.
and rightly so. considering 16 bits is a pain in the ass. i refuse
to use a platform/compiler with less than 32 bit ints.
> The clean solution is to specify
> the length you want for your variable (__int32 etc.), all other
> assumptions lead to portability problems.
the clean solution is to get a decent programming language that
doesn't inflict this kind of pain upon you. consider common-lisp.
integers can be as big as you like - limited only by your memory.
> As mentioned in types.h
> for Alpha, there exist even 32bit compilers for Alpha, so you simply
> can't rely on the C types...
no. this is part of why C sucks.
--
johan kullstam
------------------------------
From: [EMAIL PROTECTED] (Merryweather Management Systems Ltd.)
Crossposted-To: comp.os.linux.development.apps
Subject: PCNFS
Date: Mon, 21 Jun 1999 15:01:58 GMT
Reply-To: [EMAIL PROTECTED]
Slackware 3.6
Kernel 2.0.36
Hello,
I have a client who is using WRQ's Reflection Suite for X to mount
Linux disks on his NT workstation. Copying files ( using drag and drop
) from Linux to NT works OK, but copying files fom NT to Linux
generates an error
cannot copy <filespec>
the request could not be satisfied because of an io device error
I have checked all the settings on the Linux and NT boxes and
everything seems OK.
The curious thing is that I have a similar setup at my workplace and
everything is OK. I am running an earlier version of Slackware and an
earlier version of Reflection so it may be that later versions have
un-improved things!
I know there is precious little to use here, but if anyone has had a
similar problem or has any ideas I would be very grateful to receive
any help.
And finally, regarding the pcnfsd daemon running on Linux. Will it be
the latest available or is there an ftp site where I can get the
latest version from?
Kind regards,
Paul Ainscough
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Subject: Re: using C++ for linux device drivers
Date: 21 Jun 1999 11:40:23 -0700
In article <[EMAIL PROTECTED]>,
Frank Sweetser <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Nathan Myers) writes:
>
>> >> Compile with -nostdinc++ -fno-exceptions.
>> >>
>> >> Static constructors may need a C++ link phase, or you could warn that
>> >> C++ static constructors will not be executed.
>> >
>> >don't forget about name mangling, call by reference, the whole
>> >private/public/protected mess...
>>
>> Name mangling is dealt with by 'extern "C"'.
>
>hrm... IIRC, there were some issues that came up with the last time this
>matter got hashed out regarding exporting symbols from C++ code - ie, going
>the other way. i may be misremembering, though...
Not a problem. If you compile a function in C++ like this:
extern "C" int do_something(int, char*)
{
}
then the function will be generated with C linkage, meaning that you can
call do_something() from C code without having to worry about its name
being mangled.
Naturally, this means you can't pass any C++ data types to do_something()
or have it return a C++ object. Since the function will be implementing
a C interface to a kernel written in C, this doesn't lose anything.
>> Call-by-reference is a non-issue; no kernel function or callback uses it.
>
>another feature of C++ that can't be used.
Call-by-reference can be used, just not in the interface between the C++
code and the C code (the bulk of the kernel).
The do_something() code shown above could call another (C++) function
passing its integer parameter by reference, and it will work with no
problem.
>> There is no such thing as a "private/public/protected" mess.
>> Those keywords have no effect on the emitted object code.
>
>another feature of C++ that can't be used.
You can create C++ classes which use public, private, and protected data,
and use those classes in the subsystem that is implemented in C++. You
won't be able to use those classes in the rest of the kernel written in
C.
>> That they are keywords at all might break some kernel headers.
>
>i guess my biggest point here is - once you take away all of the extra
>feautures that won't work or don't make sense in the kernel context, what
>advantages does C++ realy have for writing a kernel module?
I think that, judging by the above, you overestimate the number of
"extra features that won't work." The main ones that I can think of would
be use of exceptions and statically declared objects (C++ requires some
magic to call constructors before the program starts). There are a number
of other features that a programmer has to take care with before using,
such as RTTI / dynamic_cast and use of templates, largely because these
features can cause significant runtime or memory usage costs. But I
wouldn't want a noncareful programmer hacking away at a kernel anyway.
--
- Don Waugaman ([EMAIL PROTECTED]) O- _|_ Will pun
Web Page: http://www.cs.arizona.edu/people/dpw/ | for food
In the Sonoran Desert, where we say: "It's a dry heat..." | <><
Always drive defensively! Of course, the best defense is a good offense!
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Subject: Re: using C++ for linux device drivers
Date: 21 Jun 1999 15:36:35 -0400
[EMAIL PROTECTED] (Nathan Myers) writes:
> Frank Sweetser <[EMAIL PROTECTED]> wrote:
> >[EMAIL PROTECTED] (Nathan Myers) writes:
> >> Frank Sweetser <[EMAIL PROTECTED]> wrote:
> >> >Justin Vallon <[EMAIL PROTECTED]> writes:
> >> >> [EMAIL PROTECTED] (Alexander Viro) writes:
> >> >> void *operator new(size_t s) { return malloc(s); /* kmalloc, etc */ }
> >> >> void operator delete(void *p) { free(p); }
this is what i was replying to. a version basically intended to look
C++ish.
> >> >...which is a higher-overhead version of
> >> >
> >> >#define new((x)) malloc((x))
> >> >#define delete((x)) free((x))
> >>
> >> Frank, you are confused beyond salvation on this point.
> >> Best drop it.
> >
> >exactly how am i confused? (honest question, i'm not trying to flame...)
>
> The new operator in C++ is not (normally) called as a function,
> so your macros would just break code. The argument to it is
> a type, not a number, so it cannot be passed to malloc. It
> calls a constructor. In allocation, it has different semantics
> from malloc. Need I go on?
how is my #define method any less broken than the function version to which
i was replying? this was not intended to replace the real C++ new/delete
operators, but rather to replace the C pseudo version that someone else
posted.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.5 i586 | at public servers
I think that's easier to read. Pardon me. Less difficult to read.
-- Larry Wall in <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Subject: Re: using C++ for linux device drivers
Date: 21 Jun 1999 13:16:12 -0700
In article <[EMAIL PROTECTED]>,
Frank Sweetser <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Nathan Myers) writes:
>
>> Frank Sweetser <[EMAIL PROTECTED]> wrote:
>> >[EMAIL PROTECTED] (Nathan Myers) writes:
>> >> Frank Sweetser <[EMAIL PROTECTED]> wrote:
>> >> >Justin Vallon <[EMAIL PROTECTED]> writes:
>> >> >> [EMAIL PROTECTED] (Alexander Viro) writes:
>
>> >> >> void *operator new(size_t s) { return malloc(s); /* kmalloc, etc */ }
>> >> >> void operator delete(void *p) { free(p); }
>
>this is what i was replying to. a version basically intended to look
>C++ish.
No, this is C++, not merely C++ish.
I'll go through another example:
Foo *f = new Foo;
goes through two steps:
1) Calls the operator new function to get memory for the object. The
operator new function can be class-specific, globally overridden, or
built-in. If it's class-specific, class Foo will include:
class Foo {
public: void* operator new(size_t s)
{ /* Code to allocate space for one object of this type
goes here */ }
If there is no class-specific function, the new operator will call
the globally overridden void* operator new(size_t s) function. If
there is no such function, then the built-in operator new() function
will be called.
This behavior is built in to the new operator. It can't be changed
with a preprocessor directive - only by overriding operator new.
2) The constructor Foo::Foo() is called, with this = the address returned
by the operator new called in step 1.
>> >> >...which is a higher-overhead version of
>> >> >
>> >> >#define new((x)) malloc((x))
>> >> >#define delete((x)) free((x))
>> >>
>> >> Frank, you are confused beyond salvation on this point.
>> >> Best drop it.
>> >
>> >exactly how am i confused? (honest question, i'm not trying to flame...)
>>
>> The new operator in C++ is not (normally) called as a function,
>> so your macros would just break code. The argument to it is
>> a type, not a number, so it cannot be passed to malloc. It
>> calls a constructor. In allocation, it has different semantics
>> from malloc. Need I go on?
>
>how is my #define method any less broken than the function version to which
>i was replying? this was not intended to replace the real C++ new/delete
>operators, but rather to replace the C pseudo version that someone else
>posted.
For starters, your #define method won't work, because (as Nathan said)
new is not normally called as a function. You can't replace the real C++
new/delete operators in C++ - some people call it that, but their
terminology is off. You can only control how the new operator gets its
memory - step 1 above, which is done by the operator new function.
The new operator != operator new.
--
- Don Waugaman ([EMAIL PROTECTED]) O- _|_ Will pun
Web Page: http://www.cs.arizona.edu/people/dpw/ | for food
In the Sonoran Desert, where we say: "It's a dry heat..." | <><
Last week a cop stopped me in my car. He asked me if I had a police record.
I said, no, but I have the new DEVO album. Cops have no sense of humor.
------------------------------
From: Gary Lawrence Murphy <[EMAIL PROTECTED]>
Subject: [CONTRACT] kernel programming tutorials
Date: 21 Jun 1999 16:33:49 -0400
Reply-To: [EMAIL PROTECTED]
We need experienced kernel programmers to explain Linux 2.2/2.3 to an
intermediate/advanced programmer audience. Our goal is to spark
development of new device support (like Winmodems! ) and to inspire
new programmers to join the kernel project. It doesn't pay big, but
this is a paid gig for a LI member, and you're free to fold what you
write back into LDP docs. If you're interested, please let me know.
--
Gary Lawrence Murphy <[EMAIL PROTECTED]> TeleDynamics Communications Inc
Business Telecom Services : Internet Consulting : http://www.teledyn.com
Linux/GNU Education Group: http://www.egroups.com/group/linux-education/
"You don't play what you know; you play what you hear." -- (Miles Davis)
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Linux uid limits!
Date: 21 Jun 1999 21:31:20 GMT
In article <[EMAIL PROTECTED]>,
Justin Vallon <[EMAIL PROTECTED]> wrote:
| > sizeof(short int) >= 2
| > sizeof(int) >= 2
|
| I don't think so. You could have 8-bit short, 8-bit int, 8-bit long.
No. Int must be 16 bits minimum, long 32.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
From: Ronald Cole <[EMAIL PROTECTED]>
Subject: Re: Red Hat 6.0 not fscking the root partition!
Date: 21 Jun 1999 14:41:43 -0700
Ronald Cole <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Villy Kruse) writes:
> > Standard redhat install puts the read-only flag in the /etc/lilo.conf
> > and it is essential that this flag is retained.
> >
> > Thus with standard redhat lilo setup or standard redhat created boot
> > floppy the root is mounted read-only just to be able to fsck it.
> >
> > The other distributions do excatly the same.
>
> You know, I think linuxconf hosed lilo.conf when I used it to add a
> password to lilo (thought I'd see what all the hoopla over linuxconf
> was about). I'll investigate further. Thanks for all the responses!
Yes, indeed, one of the linuxconf lilo garglers thought it knew better
than me and added "vga=normal" and "read-write" to the global section;
despite the fact that "read-only" was still the last line in the file.
It was unexpected (to me anyway) that, when confronted with *both*
"read-write" and "read-only" in the config file, lilo silently chose
"read-write".
Apparently, linuxconf has quite a bit of a way to go before it's
reliable in all areas. Think I'll be editing lilo.conf by hand from
now on.
--
Forte International, P.O. Box 1412, Ridgecrest, CA 93556-1412
Ronald Cole <[EMAIL PROTECTED]> Phone: (760) 499-9142
President, CEO Fax: (760) 499-9152
My PGP fingerprint: 15 6E C7 91 5F AF 17 C4 24 93 CB 6B EB 38 B5 E5
------------------------------
From: d s f o x @ c o g s c i . u c s d . e d u (David Fox)
Crossposted-To: comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: Making dynamic libraries
Date: 22 Jun 1999 09:21:43 -0700
mlw <[EMAIL PROTECTED]> writes:
> John Burton wrote:
> >
> > mlw wrote in message <[EMAIL PROTECTED]>...
> > >mongoose wrote:
> > >>
> > >> Ok I know how to make a static library that I can compile my programs
> > >> with but how do I make a dynamic library? Is there a webpage or could
> > >> anyone give me some info on how to do it? Also when compiling in a
> > >> library as dynamic or static does it make any performance differences as
> > >> to the speed of the program?
> > >
> > >I have big issues with how Linux does shared libraries. Phylosophically,
> > >they are implemented in a way that is environmentally specific, even
> > >though versions are the same, the environment on which they were built
> > >is incorporated into the shared object.
> >
> > Specifically what do you mean? Which parts of the environment are you
> > talking about?
>
> The shared library depends on the environment in which it was compiled.
> Software being developed in a different environment (i.e. a different c
> lib) can not use the shared object.
I'm still not quite following you. What sort of dependency do you
mean? Can you give a specific example?
--
David Fox http://hci.ucsd.edu/dsf xoF divaD
UCSD HCI Lab baL ICH DSCU
------------------------------
From: [EMAIL PROTECTED] (Georg Acher)
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Linux uid limits!
Date: 22 Jun 1999 14:34:19 GMT
In article <[EMAIL PROTECTED]>, Johan Kullstam <[EMAIL PROTECTED]>
writes:
|> [EMAIL PROTECTED] (Georg Acher) writes:
|>
|> > IMHO nobody is thinking about the possibility that an int can be
|> > 16bit when programming for Linux.
|>
|> and rightly so. considering 16 bits is a pain in the ass. i refuse
|> to use a platform/compiler with less than 32 bit ints.
Hm, what about Pure-C for Atari? Since it's 68000, it was 32bit-capable from the
beginning (no 64k segments and other horror), but you have to use long to get
a 32bit variable. On the other hand, you get used to 'long' for storing
pointers in general data structures, so it's the same as on Alpha ;-)
|> > The clean solution is to specify
|> > the length you want for your variable (__int32 etc.), all other
|> > assumptions lead to portability problems.
|>
|> the clean solution is to get a decent programming language that
|> doesn't inflict this kind of pain upon you. consider common-lisp.
|> integers can be as big as you like - limited only by your memory.
I've written some larger programs in Scheme (even with Motif-GUI. It's a nice
language concept, but I don't think that it is suitable for fast execution
of HW-near software (except if the Merced has a car and cdr-register ;-)
--
Bye
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
------------------------------
From: [EMAIL PROTECTED] (Rod Smith)
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.networking
Subject: Re: Problems reading CD created under Win9x
Date: Tue, 22 Jun 1999 16:55:27 GMT
Reply-To: [EMAIL PROTECTED]
[Posted and mailed]
In article <GxMb3.365$[EMAIL PROTECTED]>,
"R Potts" <[EMAIL PROTECTED]> writes:
> I recently donwloaded a 140MB file and had some one copy it to a CD for me
> under Win95. When I look at the CD under Linux I can see 68MB of the file
> but when I look at it under a Win95 macine I can see the whole thing.
>
> What's up with this and how can I see the whole file. I don't have access
> to a CD-RW under Linux or another UNIX OS.
Chances are the file was copied using a packet writing program. This is a
program that lets you treat the CD-R drive as if it were a regular hard
disk. The problem is that Linux doesn't like CDs created in this way.
If the only way you can get this file into Linux is directly off the CD,
your best bet is to have your friend try again using conventional CD-R
software like Easy CD Creator, Nero, or whatnot. Alternatively, you might
have luck if you ran VMWare on Linux and accessed it from Windows under
VMWare, but then you'd have to install Windows in VMWare, and that's a lot
of work to get one file.
--
Rod Smith
[EMAIL PROTECTED]
http://www.channel1.com/users/rodsmith
NOTE: Remove the "uce" word from my address to mail me
------------------------------
From: mongoose <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: Making dynamic libraries
Date: Tue, 22 Jun 1999 10:55:01 -0500
mlw wrote:
>
> mongoose wrote:
> >
> > Ok I know how to make a static library that I can compile my programs
> > with but how do I make a dynamic library? Is there a webpage or could
> > anyone give me some info on how to do it? Also when compiling in a
> > library as dynamic or static does it make any performance differences as
> > to the speed of the program?
>
> I have big issues with how Linux does shared libraries. Phylosophically,
> they are implemented in a way that is environmentally specific, even
> though versions are the same, the environment on which they were built
> is incorporated into the shared object.
>
> As the .so files are built today, it is difficult to develop and
> distribute shared object across multiple systems.
Well when you give out the source and a makefile, that pretty much
solves all those problems of system dependancy right?
> The story of my life. Twain is a personal hero of mine.
Ya twain seems like a bit of a slacker so I can asociate with him
better. :)
-Mongoose, WPI student majoring in Computer Science.
"Whenever you find yourself on the side of the majority,
it's time to pause and reflect." -Mark Twain
------------------------------
From: [EMAIL PROTECTED] (Bob Tennent)
Subject: Re: Difficulty in compiling kernel 2.2.10
Date: 22 Jun 1999 16:45:37 GMT
Reply-To: rdt(a)cs.queensu.ca
On Tue, 22 Jun 1999 16:32:26 GMT, Wei-shi Tsai wrote:
>I recently downloaded the source to the 2.2.10 kernel. I configured
>using make menuconfig to my satisfaction.
>
>However, when I compiled the kernel using "make zlilo", it goes almost
>perfectly (a few warnings) but suddenly while the assembler portion of
>the kernel is being compiled, the whole compilation stops with an error
>message.
>
>I tried again with "make zImage", but the compilation stops at the exact
>same point. What is going on????
It would help if you told us what the message said :+)
But perhaps you don't have bin86 installed?
Bob T.
------------------------------
From: "James Addison" <[EMAIL PROTECTED]>
Subject: Re: WinModems and Linux
Date: Tue, 22 Jun 1999 11:17:18 -0400
Not trying to flame anyone or any entity, but don't you think that Microsoft
probably has deals signed and crap like that to prevent the provision of
LinModem Drivers for WinModems?
After all, creating a monopoly isn't about letting such controlling
circumstances get out of control by letting manufacturers write drivers for
every OS available.
It's safe to ignore this post - honestly. :-)
--
James Addison
========================
- "You know you're in sad shape when clouds remind you of zeros and ones."
Lew Pitcher <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I've suspected that (at least some) WinModems would be that simple.
>
> Here's a challenge then:
>
> Could someone with the specs for an existing WinModem (i.e. manufacturer
> or licencee) write a two-part driver for your WinModem, and publish it
> (either as LGPL modules or GPL source) for use?
> - Part 1 would implement a state machine to translate Hayes AT commands
> to WinModem module calls. This module would be generic so as to be
able
> to drive different WinModems, and would simply process the AT
commandset
> into something useable by the WinModem driver. Sorta like Ghostscript
> does for the postscript language.
> - Part 2 would implement a modem driver (data pump and modem control)
for
> your specific WinModem. The public API should be generic enough that
> other manufacturers/authors could write similar drivers for alternate
> WinModems. This driver would provide
> a) read() and write() exits for data transfer to and from the modem,
and
> b) an ioctl() exit (or similar) for manipulation of the WinModem
controls.
> Publish the requirements of the driver API (which ioctls perform what
functions),
> and make the AT command interpreter free. You'll get *alot* of
purchasers from
> the non-windows community this way.
>
> On Tue, 22 Jun 1999 11:08:22 +0000, Craig Graham
<[EMAIL PROTECTED]>
> wrote:
>
> >pzdev <[EMAIL PROTECTED]> wrote:
> >> Please excuse me for not threading this with the main WinModems thread,
> >> but I'm having problems with my newsreader.
> >>=20
> >> A few comments about using WinModems under Linux. Contrary to what has
> >> been said in this forum, the reason that a WinModem is less expensive
> >> and consumes more of the host CPU is not because it is using the host
> >> CPU to perform the work of a UART in a normal modem. Rather, the
> >> interface card in a typical WinModem is has very little hardware at
all=
> >:
> >> typically a CODEC (D/A and A/D converter) and not much else. Most of
> >> the modem functionality, including all the modulation, protocols, link
> >> layers, and AT command processing happen on the host processor. In
> >> essence, the driver for the WinModem *is* the modem, running on the
hos=
> >t
> >> processor.
> >
> >Are you sure about that? I ask because I've programmed the Rockwell DP
> >series chips direct before (we used the data pump chip directly in a
sett=
> >op
> >box project I worked on a few years back). Admitedly they have no AT
> >command set - all you have is a set of registers that you can access, but
> >most of what you had to do was implement a state machine to control
> >the data pump. The cost saving in a win-modem actually comes from not
> >having a dedicated CPU and UART to translate AT commands from the
> >serial port into direct register access sequences to control the data
pum=
> >p
> >eg.=20
> > ATDT 0181
> >translates to=20
> > 1) set the DTMF mode bit
> > 2) set the output attenuation and DTMF twist to whatever the country's
> > local telecoms spec is (it's different for each country, rockwell
ch=
> >ips
> > default to US standards).
> > 3) write each digit one at a time, waiting for a digit-done interupt
bef=
> >ore
> > dialing the next one.
> >You can then handle the connect/negotiation sequence via a simple
> >set a bit/poll the next phase bit sequence. Once the connection is made,
> >you have one register for data out, one for data in, an interupt line for
> >transmit/recieve and a status register. Simple.
> >There isn't really any DSP done on the Host CPU, and it's not that much
> >harder than an AT type modem to write a driver for - in fact, you should
> >be able to do a much better linux driver for it than for an AT type modem
> >(what everyone here considers a 'real' one).
> >
> >
> >> pzdev
> >
> >Craig Graham.
> >
>
>
> Lew Pitcher
> System Consultant, Integration Solutions Architecture
> Toronto Dominion Bank
>
> ([EMAIL PROTECTED])
>
>
> (Opinions expressed are my own, not my employer's.)
------------------------------
** 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
******************************
