Linux-Development-Sys Digest #849, Volume #7     Fri, 12 May 00 16:13:13 EDT

Contents:
  Re: Computer Terms.....(was "Re: MS caught breaking web sites") ("Sean")
  Re: How to create memory in ptraced child process w/o child source code (Mario 
Klebsch)
  Re: ANSI C & void main() (Johan Kullstam)
  Re: [Help] is there any useful s/w for serial communication?? (Jens Kristian S�gaard)
  Re: Need to find my IP address (Rick Ellis)
  Re: Need to find my IP address (Rick Ellis)
  Process timeouts ("Jay Randall")
  Linux drivers for DVD drives? ("Jay Braun")
  Re: ANSI C & void main() (Kaz Kylheku)
  a simple question on serial mouse driver?? ([EMAIL PROTECTED])
  Re: Other than console (Rick Ellis)
  Re: Timers? ("Robert H. de Vries")
  Re: Computer Terms.....(was "Re: MS caught breaking web sites") ("Dan Hobbs")
  Re: ANSI C & void main() (Matthew Palmer)
  Bus timing & compiler optimization (Bill Waddington)
  Re: ANSI C & void main() (Kaz Kylheku)
  Re: 100 Mb thernet PCI on a 486 DX2 66MHz? (Jonathan Buzzard)
  Re: Interrupt handler problem (Mario Klebsch)

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

From: "Sean" <[EMAIL PROTECTED]>
Crossposted-To: 
comp.os.linux.advocacy,comp.os.ms-windows.advocacy,comp.os.ms-windows.nt.advocacy,comp.os.linux.networking,comp.os.linux.security,comp.os.ms-windows.networking.tcp-ip
Subject: Re: Computer Terms.....(was "Re: MS caught breaking web sites")
Date: Fri, 12 May 2000 15:42:05 GMT

personally, i belive that cpu fits better, cause there are so many mpu's in
your box.. that is if you get good hardware. MPU would end up like the term
memory, is it ram, or hdds?, though if you also look at it, cpu can be
refere to the whole damn system as well, but at least you can narrow it down
to the chip or the box as a whole. :-)
Sean


"Nobody" <[EMAIL PROTECTED]> wrote in message
news:gF3Q4.36$[EMAIL PROTECTED]...
> Back many years ago, Motorola like to called their processors MPU,
> as contrast to CPU. I think people should stick with MPU rather
> than CPU.
>
> MPU - Microprocessor Unit.
>
> David Gillam <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Chris Hedley wrote:
> > >
> > > In article <[EMAIL PROTECTED]>,
> > >         Mike Marion <[EMAIL PROTECTED]> writes:
> > > > My mom still calls the whole case the CPU, I can't convince her that
the
> CPU is
> > > > just the chip.
> > >
> > > The term CPU often refers to the enclosure in which the actual
processor
> > > complex(es) reside; the chip, OTOH, is more properly referred to as a
> > > microprocessor or logic array (depending on the system involved.)
Many
> > > people think otherwise, however, which is what I believe is referred
to
> > > as "small computer thinking."  :)
> > >
> > > Chris.
> >
> > Maybe I'm guilty of "small thinking", but.....
>
> ---8<--- snipped.
>
>



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

From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: How to create memory in ptraced child process w/o child source code
Date: Fri, 12 May 2000 12:16:13 +0200

"Bill Chen" <[EMAIL PROTECTED]> writes:

>I am trying to allocate a new segment of memory for the child process by way
>of the controlling parent process under the ptrace environment.  The
>underlying premise is that I do not want to change the child's source code
>(assume source code is not available).

>If I can changed the child's source, I can do a shmget() and shmctl().
>However, the child's source code is not available.

You could look into the source code of GDB. GDB is capable of
executing commands in the address space of the ptrace()d child. AFAIK,
GDB does put its code to execute somewhere on the stack of the target
process and executes it. But this does not work on systems, where the
stack pages do not have execute permissions (as on the Pyramid at my
university).

73, Mario
-- 
Mario Klebsch                                           [EMAIL PROTECTED]

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

From: Johan Kullstam <[EMAIL PROTECTED]>
Subject: Re: ANSI C & void main()
Date: 12 May 2000 12:31:41 -0400

[EMAIL PROTECTED] (Alexander Viro) writes:

> In article <[EMAIL PROTECTED]>,
> Johan Kullstam  <[EMAIL PROTECTED]> wrote:
> 
> >we are *not* at the mercy of the tools ghouls.  just use "int main"
> >and you have the C standard to smack them upside the head.  using the
> >tool in an improper way and getting hurt isn't the fault of the tool
> >or its implementors.  by flagrantly violating the C standard using
> >"void main" you *deserve* to lose.
> 
> Just to add some irony: while the guy in question acts like a luser,
> there is one environment where void main is _mandated_. And before you
> start mentioning $LUSERISH_COMPANY_OF_CHOICE - nope. It isn't. Yes, it's
> not UNIX. Nope, they don't pretend that it's ANSI C. However, you gotta
> give them their due - after all, one of them invented the language...

yes this true.  i've done "void main" for embedded systems which don't
really have any operating system.  there was just an assembly stub at
whatever address the CPU starts in to jump to "main".  we only had
room/need for scraps of libc too.  thus it is the operating
system/environment that dictates the standard way(s) of starting the
compiled C program.

that said, unix C (and ms-dos for that matter) does require

int main(
    int argc,
    char argv[])
{
    ....
    return r;
}

but C lets you ignore the arguments being passed.  however the return
is not optional.  (note that ms-dos command.com totally botches
handling the return code.)

> (The thing being: Plan 9 doesn't have exit(2), it has exits(2), with
> corresponding change in wait(2); they pass strings instead of the exit
> codes and char *main() would be even more against the spirit of language.
> Since in UNIX we only have exit codes...)

plan9 seems very interesting.  i wonder what inferno and brazil are
like.  i wish it weren't so painful to switch operating systems.
sometimes i feel the inertia of unix constrains linux pretty severly
at times.  oh well, maybe plan9 will get a chance some day.

-- 
johan kullstam l72t00052

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

From: [EMAIL PROTECTED] (Jens Kristian S�gaard)
Subject: Re: [Help] is there any useful s/w for serial communication??
Date: 12 May 2000 18:48:12 +0200

"Kim, Jeong-Hwan" <[EMAIL PROTECTED]> writes:

> Is there any useful s/w for x-window based serial communication
> which I wish to use for monitoring data from COM port.
> Many people recommend minicom, but it is text based.

Can you use seyon?


-- 
Jens Kristian S�gaard,
[EMAIL PROTECTED] -- http://www.jksoegaard.dk/
S�ger du noget? -- http://www.google.com/
echo|perl -ple'$_+=4E-6*!int rand()**2+rand()**2while$i++-1E6'

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

From: [EMAIL PROTECTED] (Rick Ellis)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Need to find my IP address
Date: 12 May 2000 16:56:33 GMT

In article <VLSQ4.1239$[EMAIL PROTECTED]>,
smylie <[EMAIL PROTECTED]> wrote:

>The only way i've been able to do it so far is by calling system("ifconfig
>ppp0"), and then parsing the result to get the ip. This however strikes me
>as a particularly inelegant and round-about solution.
>there must be a better way.
>any ideas anyone?

Get it from /proc instead.  You could also look at the source to
ifconfig and see how it is getting the information.

--
http://www.fnet.net/~ellis/photo/linux.html


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

From: [EMAIL PROTECTED] (Rick Ellis)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Date: 12 May 2000 17:06:13 GMT

In article <[EMAIL PROTECTED]>,
Chris <[EMAIL PROTECTED]> wrote:

>I would think that finding the address(es) of a specific interface should
>be a simple task.  The need is certainly common, judging by the amount of
>bandwidth wasted by news posts every other week asking how to do it.

I doubt that the need is really common.  The perception of the need
is though.

--
http://www.fnet.net/~ellis/photo/linux.html

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

From: "Jay Randall" <[EMAIL PROTECTED]>
Subject: Process timeouts
Date: Fri, 12 May 2000 10:12:05 -0700

I'm using Rubini's book to learn Linux device drivers and have come across a
problem implementing a process timeout as he describes on pp. 135-136.  His
method uses the field current-> timeout; the kernel I am working with is
2.2.12, and task_struct has changed and no longer has a timeout field.

Could somebody please let me know how timing out a process works in the
2.2.12 kernel.

Thanks for the help.

Jay Randall.



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

From: "Jay Braun" <[EMAIL PROTECTED]>
Subject: Linux drivers for DVD drives?
Date: Fri, 12 May 2000 09:53:22 -0700

Are there drivers for rewritable DVD drives on Linux?

Thanks,
Jay



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

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: ANSI C & void main()
Reply-To: [EMAIL PROTECTED]
Date: Fri, 12 May 2000 17:18:14 GMT

On Fri, 12 May 2000 12:55:12 GMT, Mark Graybill <[EMAIL PROTECTED]> wrote:
>
>Erik Max Francis wrote in message <[EMAIL PROTECTED]>...
>>Mark Graybill wrote:
>>
>>> Since my C days during my undergraduate studies were pre-ANSI
>>> standard, and
>>> figuring my memory was failing, I checked with the Computer Science
>>> and
>>> Engineering department at the University of Minnesota, and found that
>>> the
>>> original standard did allow void main().
>>
>>What in the world are you talking about?  What "original standard"?
>>ANSI C has always required that main return int.
>
>
>Tell me when the original standard was published. (Hint: 16 >> 4; 144 >> 4;
>128 >> 4; 144 >> 4;)
>
>Where you programming in C then?

You know, you are talking to some people that actually have a copy of that.  
(Or the ISO approved 1990 version which only differs from the 1989 ANSI one in
the numbering of the clauses).

That professor you called or e-mailed probably just blew you off without
looking anything up, or is simply too much of an academic to care or know about
trivial issues that affect life down in the trenches. Or maybe he thinks that
when you have a Ph. D. in computer science, you can just divine the answer
without having to look it up like the rest of us.

Remember, real computer scientists don't program in anything less portable than
a number 2 pencil. Talk about standards and undefined behaviors probably sounds
to these people like the buzzing of flies in the marketplace. ;)

-- 
#exclude <windows.h>

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

From: [EMAIL PROTECTED]
Subject: a simple question on serial mouse driver??
Date: Fri, 12 May 2000 17:23:42 GMT

hello friends,
             can anyone give me the source code or related links for
logitech 3 button serial mouse driver and/or microsoft 2 button serial
mouse driver.
i could not find it out in my system.(now i use intellimouse connected
to PS/2 compatible mouse port)

              i think psaux.c contains the source code for intellimouse
am i correct?( I also want to know basics of PS/2 connections regarding
keyboard and mouse.if possible send the links)

              please forgive my ignorance and help me
 thanks in advance
i use PII running redhat 5.2 ker ver 2.0.38



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

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

From: [EMAIL PROTECTED] (Rick Ellis)
Subject: Re: Other than console
Date: 12 May 2000 17:43:10 GMT

In article <8ff1u6$gbf$[EMAIL PROTECTED]>, prabha <[EMAIL PROTECTED]> wrote:

>Some commands are not working in terminals other than console on a RH 6.0
>system. I know there is a file to change all these stuff, but don't know
>where it is.

What do you mean by "not working?"  What are you using for "other than
console?"

Could it be the terminal type (the TERM environment variable) is 
set wrong?

--
http://www.fnet.net/~ellis/photo/linux.html

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

From: "Robert H. de Vries" <[EMAIL PROTECTED]>
Subject: Re: Timers?
Date: Fri, 12 May 2000 19:49:36 +0200

Colin Ford wrote:

> Hello There,
>
> I was wondering wether Linux implemented
> the Posix timers as in timer_create etc?
>
> Can't find them on my RedHat6.1 linux-2.2.12
>
> Do I need a later kernel?
>

You could use my kernel patch: http://www.rhdv.cistron.nl/posix.html

It implements all timer_* functions in the kernel.

    Robert


--
Robert de Vries
[EMAIL PROTECTED]




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

From: "Dan Hobbs" <[EMAIL PROTECTED]>
Crossposted-To: 
comp.os.linux.advocacy,comp.os.ms-windows.advocacy,comp.os.ms-windows.nt.advocacy,comp.os.linux.networking,comp.os.linux.security,comp.os.ms-windows.networking.tcp-ip
Subject: Re: Computer Terms.....(was "Re: MS caught breaking web sites")
Date: Fri, 12 May 2000 14:08:14 -0500

In article <[EMAIL PROTECTED]>, David Gillam
<[EMAIL PROTECTED]> wrote:
> Let's stick to the terms:
> 
> CPU = chip(s) Computer = collection of input/processing/output/storage
> devices that work together to process algorithms.  Commonly seen as that
> box sitting either on or near your desk, to which the cables from your
> keyboard and monitor run.  Sometimes "seen" as a collection of these
> boxes, connected by some type of network cabling, that work in concert
> to process algorithms.

CPU = brain of computer, single chip (multiple CPU's in one box allowed)
PIZZA BOX = computer case with CPU inside it on/under desk 

Well, if you get used to SUN boxes, that's the standard, anyway.  Even if
the newer ones don't quite look like pizza boxes anymore, everyone knows
what you're talking about.

Dan


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

From: [EMAIL PROTECTED] (Matthew Palmer)
Subject: Re: ANSI C & void main()
Reply-To: [EMAIL PROTECTED]
Date: 12 May 2000 23:17:22 +1000

Mark Graybill is of the opinion:
>Erik Max Francis wrote in message <[EMAIL PROTECTED]>...
>>Mark Graybill wrote:
>>> Since my C days during my undergraduate studies were pre-ANSI
>>> standard, and
>>> figuring my memory was failing, I checked with the Computer Science
>>> and
>>> Engineering department at the University of Minnesota, and found that
>>> the
>>> original standard did allow void main().
>>
>>What in the world are you talking about?  What "original standard"?
>>ANSI C has always required that main return int.
>
>Tell me when the original standard was published. (Hint: 16 >> 4; 144 >> 4;
>128 >> 4; 144 >> 4;)

1990.

I think Erik is taking issue with your "original standard" in
apparently referring to K&R C.  That was never a defined standard, in the
pure sense of the term, but rather just a loose agreement on what was to be
C and what wasn't.

The "original standard" is ANSI-<whatever>-1990 - "The C Programming
Langaage" (or whatever it is).

>Why would I read comp.lang.c.FAQ?  Unless it's run by ANSI committe members,

Actually, c.l.c has a few of the committee members there regularly, IIRC.

>We are always at the mercy of the code the compiler produces.

Which is why we have standards to specify what that code will do, given
specific input.  Writing code which invokes undefined behaviour is a
dangerous proposition, for exactly the reason which you've stated - it
leaves us entirely at the mercy of the compiler.  Staying within the realm
of defined behaviour allows us some degree of certainly (to the limits of
bugs, interpretation of the standard, etc) as to what the result will be.

>All the compilers I've used allows for its use, and they don't produce
>erratic behavior, or undefined behavior as you call it.  This is probably
>due to legacy compatibility (a good attention to detail to have.)

You've been lucky, then.  There is a list of compilers floating about (I
think it was compiled by c.l.c regulars, but I can't remember where it is)
which *do* perform strangely when given void main().  An embedded compiler I
used a few years ago did that, but I can't remember the name of it.  Dumped
it for micro-C soon after.  Basically on return from main() the stub loader
was expecting a legal value in a certain memory location, which a void main
didn't set.  Depending on what had been happeneing in the program, that
location could contain other data, possibly causing the stub to perform
erratically (it only worked well for a subset of possible return values -
which the program was supposed to adhere to).

>You obviously don't understand what reality (what we call reality), really
>is.

Reality doesn't come into a discussion on Real Programming.  We leave that
to managers and other suits.  <g>


-- 
=======================================================================
#include <disclaimer.h>
Matthew Palmer
[EMAIL PROTECTED]

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

From: Bill Waddington <[EMAIL PROTECTED]>
Subject: Bus timing & compiler optimization
Date: Fri, 12 May 2000 18:23:14 GMT

Hello all,

Bear with me, it will take a minute to set the stage for this one...

I have a Pci device that has several control registers, and data out
and data in registers.  In order to read the data in register, one first
writes to a control register to "prime" the read.  Once primed, it takes
a short time (100-200ns or so) for the data to become available - and
there is no "data available" flag.

Since cpu delays are not necessarily reflected on the bus (write posting
buffers, bridge chips, etc) I need some way to guarantee a short bus
delay between the control write and the data read.  My usual approach
is to insert a read to a some other register between the control write
and the data read.  This forces a write buffer flush and assures a delay
on the bus, with minimum performance penalty (these data reads are
infrequent - most traffic is via DMA).

What concerns me is making sure that the compiler won't optimize out the
extra timing read.

Is it sufficient to do something like:

volatile int read_dump;
volatile struct my_reg_struct_t *reg_base = ioremap(the usual);
int where_the_data_goes;



*(reg_base + CONTROL_OFFSET) = PRIME_DATA_READ;
read_dump = *(reg_base + SOME_OTHER_REG_OFFSET);
where_the_data_goes = *(reg_base + DATA_REG_OFFSET);

The above seems to work on SPARC, HP, and Intel boxes, but seems to and
really does work are a little different on machines with invisible i/o
buffers.

Are there any other ways to explicitly control optimization in the code
itself?

Sorry for all the wordage.

TIA
Bill

--
Bill Waddington
[EMAIL PROTECTED]
[EMAIL PROTECTED]


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

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

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: ANSI C & void main()
Reply-To: [EMAIL PROTECTED]
Date: Fri, 12 May 2000 18:56:24 GMT

On Fri, 12 May 2000 12:55:12 GMT, Mark Graybill <[EMAIL PROTECTED]> wrote:
>
>>Did you even read the original thread?
>
>
>All the compilers I've used allows for its use, and they don't produce

I'm using the EiC interpreter, which spits out a diagnostic and terminates.

-- 
#exclude <windows.h>

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

From: [EMAIL PROTECTED] (Jonathan Buzzard)
Subject: Re: 100 Mb thernet PCI on a 486 DX2 66MHz?
Date: Thu, 11 May 2000 22:34:58 +0100

In article <[EMAIL PROTECTED]>,
        [EMAIL PROTECTED] writes:
> Zirong Wang <[EMAIL PROTECTED]> wrote:
>: Hi groupmates,
> 
>: Can someone tell me if a old 486 Dx2 66Mhz PC can support a 100 Mb/s
>: ethernet PCI card ? or am I stuck with 10 Mb network if I want
>: include my old 486 machine in the network?
> 
> If it has PCI slots, then yes. Lots of 486s had a different
> standard called VLB (VESA local bus), and in that case, no,
> unless you can find a VLB 100 Mbps card. Good luck.
> 
> If you're using a switch rather than a hub you should be
> able to run each machine at its maximum capacity - ie. 10
> or 100 Mbps as each supports. Of course switches are a
> bit more pricey :-)
> 

Have you seen the price on a Netgear FS105 these days?

JAB.

-- 
Jonathan A. Buzzard                 Email: [EMAIL PROTECTED]
Northumberland, United Kingdom.       Tel: +44(0)1661-832195

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

From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: Interrupt handler problem
Date: Fri, 12 May 2000 21:06:09 +0200

Arnaud Westenberg <[EMAIL PROTECTED]> writes:

>To address my hardware I had to write low-level read and write
>functions. These functions first write the desired address to the base
>address of my hardware and then I can read or write the contents of the
>desired address from the base address plus 1.

Ugly :-(

>(could somebody tell me the name of this sort of memory addressing?)

Multiplexing???

>The problem begins at interrupt time. The lowlevel hardware access is so
>slow that I loose the next interrupt and message (no hardware buffer). I
>have to read several successive bytes wich means several low-level
>operations. Normally one would use insb.

WHen having multiplexed register access, you need to disable
interrupts (didn't someone wrote, that cli() shall not be used
anymore?) prior to the first access, and you have to reenable the
original state after the second access.

73, Mario
-- 
Mario Klebsch                                           [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
******************************

Reply via email to