Linux-Development-Sys Digest #128, Volume #7 Tue, 31 Aug 99 05:14:15 EDT
Contents:
Re: Outlook Express (Stewart Stremler)
Re: why not C++? (Don Waugaman)
Re: Emulating network interfaces in user space (Phil Howard)
Re: why not C++? (Don Waugaman)
Re: why not C++? (Don Waugaman)
Re: Avoid Zombies (Sven Heursch)
Re: why not C++? (Don Waugaman)
Re: My Boot-Loader: No Root FS :(( (Peter Samuelson)
Re: why not C++? (Timo Tossavainen)
Re: Getting the Ethernet ID from directly from the network card. (Peter Samuelson)
Funny behaviour booting from a MO device (Mike Dowling)
Re: Funny behaviour booting from a MO device (Peter Samuelson)
Re: Outlook Express (Peter Samuelson)
Re: Question: Child Process I/O (Peter Samuelson)
Re: SCSI device scan order. (Peter Samuelson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Stewart Stremler)
Crossposted-To: comp.os.linux.alpha,comp.os.linux.development.apps
Subject: Re: Outlook Express
Date: 31 Aug 1999 05:19:07 GMT
Kaz Kylheku ([EMAIL PROTECTED]) wrote:
[snip]
: It's actually a smart strategy. It often takes a Linux guru to get Windows
: shit working. ;)
Look at the headers... and remember, M$ owns hotmail now. If you have
a suspicious turn of mind, start the ominious music now.
>From
>newshub.sdsu.edu!news.sgi.com!news-peer-west.sprintlink.net!news.sprintlink.net!nntp.primenet.com!nntp.gctr.net!newsfeed.berkeley.edu!nntp-relay.ihug.net!ihug.co.nz!remarQ60!rQdQ!supernews.com!remarQ.com!news.supernews.com!not-for-mail
> Mon Aug 30 22:17:03 1999
>Path:
>newshub.sdsu.edu!news.sgi.com!news-peer-west.sprintlink.net!news.sprintlink.net!nntp.primenet.com!nntp.gctr.net!newsfeed.berkeley.edu!nntp-relay.ihug.net!ihug.co.nz!remarQ60!rQdQ!supernews.com!remarQ.com!news.supernews.com!not-for-mail
>From: <[EMAIL PROTECTED]>
>Newsgroups:
>comp.os.linux.alpha,comp.os.linux.development.apps,comp.os.linux.development.system
>Subject: Outlook Express
>Date: Sun, 29 Aug 1999 04:31:01 GMT
>Organization: Posted via Supernews, http://www.supernews.com
>Lines: 10
>Message-ID: <[EMAIL PROTECTED]>
>X-Complaints-To: [EMAIL PROTECTED]
>Content-Type: text/plain
>Content-Disposition: inline
>Mime-Version: 1.0
>X-Mailer: MIME-tools 4.103 (Entity 4.115)
>Xref: newshub.sdsu.edu comp.os.linux.alpha:12257 comp.os.linux.development.apps:84739
>comp.os.linux.development.system:101081
>
[snip]
--
============================================================================
Stewart Stremler SDSU Graduate
Java, C, Pascal, Scheme, Forth, CPL, Rexx, csh, TCL/TK, Prolog, & Automata
Employed by Compendium Technologies LLC.
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 30 Aug 1999 23:25:16 -0700
In article <[EMAIL PROTECTED]>,
Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>On 29 Aug 1999 15:29:10 -0700, Don Waugaman <[EMAIL PROTECTED]> wrote:
>>References are extremely important for use with operator overloading
>>and templates.
>These are non-essential reasons for their existence.
Please explain, then, how to make operator overloading work without
reference types or "compiler magic".
[ snips ]
>The only time you need to use references is in defining copy constructors and
>assignment operators. These language features could have easily been designed
>around pointers instead of references; there is no inherent, essential need for
>references.
It seems that you would prefer the sudden invocation of compiler magic
in those instances when passing by reference is needed for correct
semantics. I would tend to disagree - C++ has too many special cases
already. A general tool such as references, while retaining the potential
for abuse, remains a better solution than a host of "special" functions
or operators, which IMHO would be worse than the typically-cited issue of
the similarity of reference and value syntax.
--
- 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..." | <><
The older a man gets, the farther he had to walk to school as a boy.
------------------------------
From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: Emulating network interfaces in user space
Date: Tue, 31 Aug 1999 06:48:32 GMT
On Mon, 30 Aug 1999 08:27:20 -0500 Dave Weis ([EMAIL PROTECTED]) wrote:
| Take a look at the source for diald, they do something like that.
| Basically, you set up a pty with your program listening on it and the
| point pppd/slip at that pty and you will get the packets that are routed
| via the routes you make to the device.
How "clean" are those packets? Do I have to implement ppp logic to strip
them down to pure IP?
--
Phil Howard KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 30 Aug 1999 23:44:08 -0700
In article <[EMAIL PROTECTED]>,
NF Stevens <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Don Waugaman) wrote:
>>
>
>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.
I don't see how this follows from what I have written.
> 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.
In other words, the statement "references must be non-NULL" fails the
Machiavelli test.
However, considering the difficulty of creating code that exercises the
compiler this way, compared to the ease of creating code that dereferences
a NULL pointer, I would say that C++ references pass the "Murphy" test
with flying colors.
I might add that a suitable compiler design would be to check for NULL or
otherwise illegal pointers when they are dereferenced, which would mean
that incorrect dereferencing happens in the caller code rather than the
called code, thus moving the effect of the error closer to the site of the
error.
--
- 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..." | <><
All generalizations are false.
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 30 Aug 1999 23:47:20 -0700
In article <[EMAIL PROTECTED]>,
Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>The notion of strict conformance is of no consequence to the engineer using the
>language to make software.
Except when an engineer attempts to write software easily portable from one
processor, OS, or compiler to another one, in which case an understanding
of the conformance demands of the standard will certainly ease problems
down the road.
--
- 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..." | <><
Three out of every four people make up 75 percent of the population.
------------------------------
Date: Tue, 31 Aug 1999 08:21:37 +0200
From: Sven Heursch <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Avoid Zombies
I am using RedHat 6.0 with glibc 2.1.1 and the gcc 2.7.2 on a 486er machine.
S. Heursch
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 30 Aug 1999 23:14:24 -0700
In article <[EMAIL PROTECTED]>,
Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>On 30 Aug 1999 07:48:28 -0700, Don Waugaman <[EMAIL PROTECTED]> wrote:
>>I'll agree that it's possible to use templates without references, but
>>much of the power of templates comes from argument deduction, which
>>would be a rather painful process without the use of references.
>
>Template argument deduction is done by the compiler and works over pointers as
>well as references. So I don't see where the pain comes in.
>
>E.g.
>
> template <type T> void foo(T *) { /*...*/ }
>
> int *p;
> //...
> foo(p); /* foo<int *> deduced */
Deduction does work with pointers.
However, pointers are a poor way to pass items into value-based containers.
>>containters/iterators/algorithms libraries are incredibly powerful, but
>>would become rather painful to use without references.
>
>Why is that? Because you have to type -> instead of . and use * from time to
>time? Good reminders that the container holds pointers to the objects,
>rather than copies of objects.
Containers - at least the containers in the C++ Standard Library - do hold
copies of objects, though the objects held in the objects in question can
themselves be pointers (and, in my code, often are).
--
- 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..." | <><
A jury consists of 12 persons chosen to decide who has the better lawyer.
-- Robert Frost
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: My Boot-Loader: No Root FS :((
Date: 31 Aug 1999 02:31:22 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[mailed and posted per request]
[<[EMAIL PROTECTED]>]
> Well, I noticed in most any linux docu that it could not be booted if
> the image is not located in the 8 GB limit.
Hmmm, would that be the 1K-cyl limit or the LBA limit? Either way it's
a BIOS problem not a Linux problem (or, more precisely, a problem of
nobody wanting to try to fit a proper IDE or SCSI driver into a boot
loader so they all have to rely on the BIOS API limitations).
> Because of that I wrote direct-Linux support. I defined a new
> partition (8Ah) and wrote a program, which writes the kernel image to
> that. (why did nobody do such thing?)
Maybe because an alternative solution -- creating a 10MB partition
below the BIOS limit, making this ext2 or minix and mounting it as
/boot, putting kernel images in there and pointing to them in lilo.conf
-- works fine and is more flexible.
> Then I did the loader, which is working, BUT (hehe, you knew it)
> Linux says something about "no root FS" and that�s it :(
OK, splendid. You need to define the root filesystem in your new
kernel. Three ways to do this: (a) use the same root filesystem when
you compile as after you reboot -- the compile process will pick up the
current root; (b) use `rdev'; or (c) pass a command line to the kernel
on boot. Since evidently your environment precluded (a), and you can't
do (c) until you get a command line working, I would recommend (b).
> I know there�s a command-line, but I could not figure out how to get
> that working. What do I have to do ?
There are at least five Linux boot loaders out there with full source
code (lilo, grub, syslinux, loadlin and one I can't remember); go see
how one of those does it. I don't know offhand but it can't be that
hard to figure out.
When you get the command line working, tackle the initrd concept.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Timo Tossavainen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Tue, 31 Aug 1999 11:37:53 +0300
Don Waugaman wrote:
> I might add that a suitable compiler design would be to check for NULL or
> otherwise illegal pointers when they are dereferenced, which would mean
> that incorrect dereferencing happens in the caller code rather than the
> called code, thus moving the effect of the error closer to the site of the
> error.
C++ers usually miss the point of that Lispers and Smalltalkers have known for
some time. I think there's a "market" for a GPL'd C++ interpreter that checks
the code for array bounds, invalid casts, pointer dereferencing, memory
deallocation, etc. all the stuff that C++ doesn't check at run-time. The
interpreter could be used to debug the code and then it could be compiled when
there's reasonable evidence that it is acceptably bugless. Also the environment
should support adding and fixing functions/classes as the program is running
(i.e. no edit-compile-debug-cycle). This would reap many of the benefits of the
dynamic language environments in terms of development speed. It's weird that
even the leading compiler vendors have missed the option of using interpretation
during development.
Timo
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.development,linux.dev.kernel
Subject: Re: Getting the Ethernet ID from directly from the network card.
Date: 31 Aug 1999 03:27:29 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Vincent <[EMAIL PROTECTED]>]
> I'm developping a driver that it must getting the Ethernet ID
> directly on the network card.
This is confusing. Are you developing a network driver? If so, we
can't help you without knowing what the hardware is like.
If you're writing a *different* driver that wants this information, why
get the info "directly from the network card" as you put it? Just call
the function dev_ifsioc() in net/core/dev.c with a second argument of
SIOCGIFHWADDR.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Mike Dowling)
Subject: Funny behaviour booting from a MO device
Date: 31 Aug 1999 08:18:02 GMT
I made system backups on a SCSI MO device. I then wanted to boot from
it, but I forgot first to boot from a floppy, and run lilo. The MO
device had SCSI id 0, and the hard disk SCSI id 1.
I would have thought that the system would have tried to boot from the
MO device, as ithad the lowest SCSI id, and then discover that it could
not do so without first running lilo.
What actually happened was that the system used the kernel from the hard
disk with SCSI id 1, and the root partition of the MO device.
Can anybody please explain what was going on here?
Cheers,
Mike Dowling
--
My email address [EMAIL PROTECTED] above is a valid email address.
It is, in fact, a sendmail alias; the digit 'N' is incremented regularly.
Spammed aliases will be deleted. Currently, mike[5,7-9,10,12,13,16,17] have
been deleted. If email to mikeN bounces, try mikeN+1.
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Funny behaviour booting from a MO device
Date: 31 Aug 1999 03:49:18 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Mike Dowling <[EMAIL PROTECTED]>]
> I made system backups on a SCSI MO device. I then wanted to boot
> from it, but I forgot first to boot from a floppy, and run lilo. The
> MO device had SCSI id 0, and the hard disk SCSI id 1.
> I would have thought that the system would have tried to boot from
> the MO device, as ithad the lowest SCSI id, and then discover that it
> could not do so without first running lilo.
> What actually happened was that the system used the kernel from the
> hard disk with SCSI id 1, and the root partition of the MO device.
What device to boot is entirely the domain of the BIOS. Did your BIOS
recognize the MO as something bootable? Sounds like it didn't. A
"SCSI disk" from the perspective of the kernel drivers is not
necessarily the same thing as a "SCSI disk" from the perspective of a
SCSI card's BIOS.
After LILO gets run by the BIOS and loads up the kernel, said kernel
chooses whatever root filesystem it wants, preferring (in order of
preference) the "root=" command line argument passed to it, or the
device major:minor numbers embedded in it. This is after the kernel
has detected SCSI interfaces and SCSI disks, and the disks are numbered
in order of detection. Meaning that the MO will get sda while the HD
gets sdb. Note, in any case, that the root filesystem has *nothing* to
do with where LILO loaded the kernel from.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.alpha,comp.os.linux.development.apps
Subject: Re: Outlook Express
Date: 31 Aug 1999 03:41:42 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Stewart Stremler <[EMAIL PROTECTED]>]
> Look at the headers... and remember, M$ owns hotmail now. If you have
> a suspicious turn of mind, start the ominious music now.
So let's get this straight. The guy has Outlook Express, which should
be able to handle news and mail, yet since Outlook isn't lame enough he
uses supernews.com for posting news and hotmail.com for receiving mail.
Cute.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
[for the last five years: trn for news and vm for mail]
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Question: Child Process I/O
Date: 31 Aug 1999 03:34:09 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Herng-Jeng Jou <[EMAIL PROTECTED]>]
> In the parent process, how do I determine when the child process has
> done its number crunching and is waiting for further input? Should I
> use /proc?
Don't bother trying. Just send it input as fast as you can, and let
the kernel block you when it's tired of buffering you.
> How do I determine whether there is still something in the output
> buffer?
Not easy. I still don't understand why you need to do this.
> In a sense, I need an I/O facility similar to a debugger so the
> parent process can talk to the child program.
The only way I can think of to do this without source code would be to
insert hacked stdio functions into the binary via LD_PRELOAD. This is
of course assuming that your binary's stdio is dynamically linked.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.help,comp.os.linux.setup
Subject: Re: SCSI device scan order.
Date: 31 Aug 1999 02:50:46 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Seth Mason <[EMAIL PROTECTED]>]
> My system is setup to boot off of /dev/hda which resides on the NCR
> internal scsi adapter,
^^^sda
> and I use the qlogic adapter to for external high speed storage. My
> problem is, the kernel appears to load the driver for the qlogic
> adapter first and then the NCR scsi adapter. This is a problem, b/c
> the kernel then tries to mount root off of the qlogic adapter and not
> off of the NCR scsi adapter.
Sages have pondered this problem, which is somewhat Linux-specific, for
aeons. It's much worse when you have something like a SCSI Zip disk
which is sometimes online and sometimes not. For this reason the
kernel probes for parallel-port Zip interfaces *after* the "builtin"
SCSI cards, and if your Zip drive is direct SCSI you are encouraged to
use a higher SCSI ID than your "builtin" drives....
The probe order is defined in drivers/scsi/hosts.c. I can't remember
whether you can affect without just editing the file, but there's
always the possibility of compiling the qlogic driver as a module; that
way it will be loaded after the root filesystem is mounted.
The other thing to do would be just to give in and call your root
filesystem /dev/sdb1. Remember, the drive with LILO on it doesn't have
to be the drive with your root filesystem on it. If necessary, make a
separate /boot partition on the NCR drive (the one the NCR BIOS will
call "C:").
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
** 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
******************************
