Linux-Development-Sys Digest #734, Volume #8 Fri, 18 May 01 23:13:09 EDT
Contents:
Re: SIGSEGV is not blocking (Rene Herman)
Re: transpareny ("Darren LS")
Re: passing messages to a forked thread ("Darren LS")
Re: Behavior of read() w.r.t.memory protection (John Reiser)
Re: Behavior of read() w.r.t.memory protection ("Arthur H. Gold")
Re: interrupts too frequent? (Robert Redelmeier)
stupid question about bluetooth ("gary zhu")
Re: Behavior of read() w.r.t.memory protection (John Reiser)
Re: Trouble using large amount of memory with Redhat 7 ("J. P. Montgomery")
Distributions on CD (was Re: Free OS ?) (Shankar Unni)
----------------------------------------------------------------------------
From: Rene Herman <[EMAIL PROTECTED]>
Subject: Re: SIGSEGV is not blocking
Date: Fri, 18 May 2001 22:23:35 +0200
[ deleted comp.os.linux.development.apps and comp.programming.threads ]
Robert Redelmeier wrote:
> On i386 a trap _is_ an interrupt. The only difference is
> the pushed IP corresponds to the faulting instruction, not
> the next instruction. This greatly facilitates re-start.
>
> When an int is executed, hardware disables all other ints.
> The ISR (OS) may re-enable interrupts (or not). Usually
> it will, but for some critical code, it cannot.
By i386, are you refferring to the CPU itself or Linux-i386? I know
hardly anything about Linux internals but the Intel 80386 Programmer's
Reference Manual says that, unlike an interrupt (ie, a transfer of
control through an interrupt gate), a trap (transfer of control trough
a trap gate) does not affect IF. But perhaps everything's an interrupt
gate on Linux-i386?
Rene.
------------------------------
From: "Darren LS" <[EMAIL PROTECTED]>
Crossposted-To:
alt.linux,comp.os.linux.development.apps,linux.redhat.devel,linux.redhat.development
Subject: Re: transpareny
Date: Fri, 18 May 2001 22:16:35 +0100
Kasper Dupont <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Kasper Dupont wrote:
> >
> [...]
> >
> > The attached example demonstrates a lot of theese
> > features. You can remove the parts you don't like.
> > All this program does could have been by using the
> > open command with some appropriate options.
> >
> [...]
>
> Oops I just discovered a small mistake the line:
> if (!ioctl(0,VT_OPENQRY,&number))
> is wrong it should instead have been:
> if (!ioctl(i,VT_OPENQRY,&number))
thank you I will treasure you code :-)
------------------------------
From: "Darren LS" <[EMAIL PROTECTED]>
Subject: Re: passing messages to a forked thread
Date: Fri, 18 May 2001 22:32:39 +0100
Greg Copeland <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Darren LS" <[EMAIL PROTECTED]> writes:
>
> > Greg Copeland <[EMAIL PROTECTED]> wrote in message
> >
> >
> > >
> > > See ipc, semget, etc., and pipe for more info on the above.
> >
> >
> > hmm. sounds good but i may not own all the processes
>
> Do you mean that you may not be the process owner or that the
> process may not have been written by you? You can set permissions
> on SYS V IPC resources if you mean the first and not the latter.
> If on the other hand, you are limited to someone else's implementation,
> obviously, you're going to have to conform somehow.
The former. I am looking for some common messaging system used by
applications in general like signlling
> > > > >
> > > > >
> > > > > | 3. must be able to send signals to other processes both local
and
> > remote
> > > > >
> > > > > What do you mean by remote? On a different computer?
> > > >
> > > > yes
> > >
> > > So you are wanting to develop a message passing scheme? CORBA? RPC?
> > SOAP?
> > > Something simpler? I don't think there is enough information to
directly
> > > answer your question.
> >
> > RPC? thats Microsoft isn't it. no i am just looking for some common
message
> > piping system that runs on linux and can be uses remotely as well as
locally
> > i mean lets face it, thats what unix is about:-)
>
> No, RPC was created by Sun.
You do not realise how happy i am to hear you say that :-)
Likewise, NFS is also implemented via RPC. If you
> need common (RPC is) and simple (IMOHO, RPC is not), you may want to look
at,
> again, sockets and/or SOAP. I do know that SOAP now exists for perl,
python,
> I think C and C++, and even Microsoft has stated that they wish to adopt
SOAP
> for .NET. So, I'd *guess* that support is available for Win platforms
too.
> Other than that, you'll need to look back to sockets (surprise), RPC, or
even
> something heavy duty like CORBA.
Thats cool but supposing the applicationi wish to talk to does not use a
socket?
I am happy and competent with socket programming bu as you know this is not
built in to every application
> >
> > >
> > > Long story short, you need to make sure you have a reliable means to
> > convey
> > > this signal via a network path. It sure would stink to have someone
send
> > > bogus signals which cause all of your applications to shutdown because
you
> > > couldn't validate the source or intent. This could even be as simple
as
> > > sending a GPG encrypted message which the recipient decrypts and
verifies
> > > the signature.
> >
> > I agree but first things first :-)
> >
> >
> > The message could be the signal to use. This is just one
> > > example, but I hope you can see the importance of verifying who a
message
> > > is coming from if signals are directly acted upon from network events.
> >
> > I have my own encyption algorythms sorted, i could use them
>
> Excellent. If you know how to do crypto at the API level, I'd rather
recommend
> that!!!
thank you. They are not unbreakable but i am quite proud of them :-)
> > >
> > > If process monitoring is what you are trying to do, the previous
poster is
> > > absolutely correct. You need to have a parent process start your
child
> > which
> > > then waits for it to exist, logging that it did, which means you can
also
> > > monitor why it terminated as well.
> >
> > I am with you with the logging it exist bit but how would the parent
know
> > if the child terminates?
>
> See wait() and waitpid(). Both allow you get obtain the reason why the
child
> terminated. You can determine not only the return code (via exit or the
last
> return value), but also if it was via an unhandled signal and what the
signal
> was. Using these mechanisms, you can create very powerful process
monitoring
> facilities.
if i understand you correctly, then i get the parent to to perform a waitpid
on its child then it will "baby sit" it if you will :-)
>
> If you are looking for distributed cross platform middleware, which is
what
> it sounds like you are describing, it looks like you need to think about
> something like: MQSeries; http://www-4.ibm.com/software/ts/mqseries/ or
the
> like. XIPC is probably another option, but I will *NEVER* recommend them
> as I've actually used their products. Ack!
sounds good to me.
Thank you
------------------------------
From: John Reiser <[EMAIL PROTECTED]>
Subject: Re: Behavior of read() w.r.t.memory protection
Date: Fri, 18 May 2001 15:22:56 -0700
> I've asked this before (quite a while ago) but got no response:
As I recall, it was a couple years ago.
[program snipped]
>
> Run in linux, it behaves as follows:
>
> pbuf = 40015000, read() returned -1
> pbuf = 40014fff, read() returned -1
> pbuf = 40014ffe, read() returned -1
> pbuf = 40014ffd, read() returned -1
What is the value of errno in the cases above? It's important.
I get EFAULT, which tells you that the buffer address is bad.
> pbuf = 40014ffc, read() returned 4
> pbuf = 40014ffb, read() returned 4
> pbuf = 40014ffa, read() returned 4
> pbuf = 40014ff9, read() returned 4
> pbuf = 40014ff8, read() returned 8
> pbuf = 40014ff7, read() returned 8
>
> i.e. it will happily read as many four-byte chunks as will fit in
> unprotected memory (failing if there is not at least 4 bytes of such
> memory available).
>
> On FreeBSD, however, it seems as if the entire buffer is checked first,
> and the results are:
>
> On FreeBSD 4.3
>
> pbuf = 280fc000, read() returned -1
> pbuf = 280fbfff, read() returned -1
> pbuf = 280fbffe, read() returned -1
> pbuf = 280fbffd, read() returned -1
> pbuf = 280fbffc, read() returned -1
> pbuf = 280fbffb, read() returned -1
> pbuf = 280fbffa, read() returned -1
> pbuf = 280fbff9, read() returned -1
> pbuf = 280fbff8, read() returned -1
> pbuf = 280fbff7, read() returned -1
Again, what is the value of errno? I don't have a FreeBSD box to run it,
but I bet that it's EFAULT, which tells you that there is a problem
with the buffer address.
>
> It seems that the FreeBSD behavior is `more' correct -- at least you can
> tell that something's wrong
The meaning of "more correct" is debatable. "Something's wrong"
needs a precise definition. The value of errno tells you [almost]
everything that you need to know.
> In Linux, in the case where there's at
> least 4 bytes of unprotected memory available, the result is
> indistinguishable from a situation where there are only that many bytes
> available in the file to be read.
Except for the granularity being 4 bytes instead of only 1 byte,
the Linux behavior is 100% consistent with the contract to which
read() adheres: it reads as much as can be read successfully
(at most the length of the buffer), and tells you how many
bytes were read. And if it fails to read any bytes at all
because of an error [return value of 0 is not an error], then the
return value is -1 and errno is set to indicate the cause
[one of them, anyway]. What more could you ask?
--
John Reiser, [EMAIL PROTECTED]
------------------------------
Date: Fri, 18 May 2001 17:58:24 -0500
From: "Arthur H. Gold" <[EMAIL PROTECTED]>
Subject: Re: Behavior of read() w.r.t.memory protection
John Reiser wrote:
>
> > I've asked this before (quite a while ago) but got no response:
>
> As I recall, it was a couple years ago.
Yes it was!
>
> [program snipped]
> >
> > Run in linux, it behaves as follows:
> >
> > pbuf = 40015000, read() returned -1
> > pbuf = 40014fff, read() returned -1
> > pbuf = 40014ffe, read() returned -1
> > pbuf = 40014ffd, read() returned -1
>
> What is the value of errno in the cases above? It's important.
> I get EFAULT, which tells you that the buffer address is bad.
Of course.
>
> > pbuf = 40014ffc, read() returned 4
> > pbuf = 40014ffb, read() returned 4
> > pbuf = 40014ffa, read() returned 4
> > pbuf = 40014ff9, read() returned 4
> > pbuf = 40014ff8, read() returned 8
> > pbuf = 40014ff7, read() returned 8
It is these cases that I find interesting (and to which you have have
not responded).
> >
> > i.e. it will happily read as many four-byte chunks as will fit in
> > unprotected memory (failing if there is not at least 4 bytes of such
> > memory available).
> >
> > On FreeBSD, however, it seems as if the entire buffer is checked first,
> > and the results are:
> >
> > On FreeBSD 4.3
> >
> > pbuf = 280fc000, read() returned -1
> > pbuf = 280fbfff, read() returned -1
> > pbuf = 280fbffe, read() returned -1
> > pbuf = 280fbffd, read() returned -1
> > pbuf = 280fbffc, read() returned -1
> > pbuf = 280fbffb, read() returned -1
> > pbuf = 280fbffa, read() returned -1
> > pbuf = 280fbff9, read() returned -1
> > pbuf = 280fbff8, read() returned -1
> > pbuf = 280fbff7, read() returned -1
>
> Again, what is the value of errno? I don't have a FreeBSD box to run it,
> but I bet that it's EFAULT, which tells you that there is a problem
> with the buffer address.
Naturally.
>
> >
> > It seems that the FreeBSD behavior is `more' correct -- at least you can
> > tell that something's wrong
>
> The meaning of "more correct" is debatable. "Something's wrong"
> needs a precise definition. The value of errno tells you [almost]
> everything that you need to know.
>
> > In Linux, in the case where there's at
> > least 4 bytes of unprotected memory available, the result is
> > indistinguishable from a situation where there are only that many bytes
> > available in the file to be read.
>
> Except for the granularity being 4 bytes instead of only 1 byte,
> the Linux behavior is 100% consistent with the contract to which
> read() adheres: it reads as much as can be read successfully
> (at most the length of the buffer), and tells you how many
Well, not the length of the buffer, the length specified as the third
argument.
> bytes were read. And if it fails to read any bytes at all
> because of an error [return value of 0 is not an error], then the
> return value is -1 and errno is set to indicate the cause
> [one of them, anyway]. What more could you ask?
Right. But when the number of bytes read is limited by protections on
_part_ of the buffer, you're non the wiser. At least the FreeBSD
behavior lets you know that something `out of the ordinary' has happened
(i.e. that you're tried to read into protected space).
_That's_ the question!
Cheers,
--ag
--
Artie Gold, Austin, TX (finger the cs.utexas.edu account for more info)
mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
--
I am looking for work. Contact me.
------------------------------
Date: Fri, 18 May 2001 18:14:59 -0500
From: Robert Redelmeier <[EMAIL PROTECTED]>
Subject: Re: interrupts too frequent?
Barry Smyth wrote:
>
> Using rdtscl I get around 75000 as the max. number of cycles to execute the
> interrupt routine. I have worked out the time by dividing this by the CPU
> speed which is ~900MHz to get a time of about 0.1 ms which seems to be
> satisfactorally within the 1ms limit. Is this right?
75000 /900,000,000 = 0.0000833 seconds (0.083 ms) This is correct and
almost certainly acceptable for an interrupt that occurs every 1 ms.
Check `hdparm` ,especially -tT to see your transfer speeds. If you
don't have DMA enabled, you will get < 4MB/s. This will be death
to your interrupt, because writing out a 4 KB inode will take 1 ms.
You really need DMA enabled.
-- Robert
------------------------------
From: "gary zhu" <[EMAIL PROTECTED]>
Subject: stupid question about bluetooth
Date: Fri, 18 May 2001 17:07:26 -0700
As I found from kernel 2.4, there is bluetooth driver for USB. My question
is whether this driver supports all bluetooth card and I do not need extra
driver for bluetooth card?
------------------------------
From: John Reiser <[EMAIL PROTECTED]>
Subject: Re: Behavior of read() w.r.t.memory protection
Date: Fri, 18 May 2001 17:12:08 -0700
> > > Run in linux, it behaves as follows:
> > > pbuf = 40014ffc, read() returned 4
> > > pbuf = 40014ffb, read() returned 4
> > > pbuf = 40014ffa, read() returned 4
> > > pbuf = 40014ff9, read() returned 4
> > > pbuf = 40014ff8, read() returned 8
> > > pbuf = 40014ff7, read() returned 8
> It is these cases that I find interesting (and to which you have have
> not responded).
I'll repeat, using different words: Linux is an "eager beaver",
and finds a way to succeed partially, as if by "truncating" the buffer.
Due to vagaries of x86 protection, speed, and programming convenience,
Linux does this on the basis of aligned, 4-byte units. FreeBSD
chooses to be diffident, quibbling that part of the buffer is
off limits, and says, 'No, I won't," even though the start of the
buffer is valid and data is available. You could say that FreeBSD
does the _same_ as Linux, except with buffer-length units
instead of aligned 4-byte units.
> But when the number of bytes read is limited by protections on
> _part_ of the buffer, you're non the wiser.
On the contrary, you can tell that the number of bytes read is less
than the third argument; in some sense, a "short read". A sufficiently-
motivated program[mer] will use that information to deduce that an
interesting case has arisen.
> At least the FreeBSD
> behavior lets you know that something `out of the ordinary' has happened
> (i.e. that you're tried to read into protected space).
Linux does let you know: the return value is less than the
third argument to read(). This is a clue. If the next read
is into the same buffer at the next adjacent byte, then
the return value will be -1 with EFAULT, the same as FreeBSD.
If the next read is into the same buffer at the beginning,
then once again Linux will successfully read a few bytes.
The EFAULT on Linux is "out of phase" with FreeBSD
by "half a cycle," but during that half cycle Linux delivers
good bytes into the good part of the buffer.
So, Linux chooses to make progress whenever it can, and FreeBSD
chooses to be as strict as possible. I consider both choices
to be consistent with the interface contract, and my programs
work the way I want on both systems with no conditional compilation
or runtime querying of OS type. (And I wrote the code that way
in the first place, before either FreeBSD or Linux existed.)
--
John Reiser, [EMAIL PROTECTED]
------------------------------
From: "J. P. Montgomery" <[EMAIL PROTECTED]>
Subject: Re: Trouble using large amount of memory with Redhat 7
Date: Fri, 18 May 2001 22:28:49 -0500
Another day and more information ... I now believe that I mostly have a
compiler issue. I ran an f90 code that allocates memory in a do loop until
error and I found that it crashed at 1365MB of the 1.5 G of real memory.
This compares with the f77 code which crashed about 540MB ... of course, the
older heritage f77 code allocates only thru a dimension statement and does
not use an allocate call. I have now sent back an email to my compiler
people to ask what's up?
Nevertheless, after examining my limits which were all unlimited ... I am
wondering why the f90 code wouldn't just aquire the 2G limit imposed by
signed integer addressing? After all, I have 2G of disk space for VM.
I spent a good bit of the morning looking at kernel issues and 4G memory,
etc. but I now believe that this was a red herring ...
At this point I may well find out about the compiler issue from Portland or
a fortran newsgroup but I am now wondering about the 1365MB limit. Any
suggestions on this one?
Incidently, the executable crashes with a segmentation fault and no
additional information. I haven't read a core dump in years ... but any
pointers to a how-to on this would also be helpful. I mostly use common
sense, added printout, and occassionally a debugger to find these kind of
sticky problems. I haven't read a dump since the good ole '60's when it
proved to be very helpful when there were only mainframes and the turnaround
was maybe 3-4 runs a day! Maybe this old dog can learn a few new tricks!
Thanks
"Cary Jamison" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "J. P. Montgomery" wrote:
> >
> > I have a K7 AMD 1.2 G machine with 1.5 G of ram using an ASUS
motherboard
> > and am running Redhat 7. I use a Portland Fortran compiler (and
sometimes
> > g77 and gcc). I have found that when I write a simple program I can
only
> > dimension a complex array by about 72000000 before the job will core
dump (a
> > job size of about 549M as verified by computation and running top). The
> > Portland people point to the OS and say that perhaps I can recompile the
> > kernel. Okay ... so I've checked the Redhat site and done searching on
> > newsgroups, etc. The hint I have found is that my stack size is 8M in
the
> > kernel. I can certainly recompile ... but I am trying to figure if this
> > will solve the problem. I have noted that g77 has a different limit
> > (somewhat lower ... the Portland guy said however, that they have no
such
> > limitation in the compiler). Also a coworker uses a Lahey compiler on a
> > Win98 machine with 512M of memory. He can dimension the array mentioned
> > above by 110000000 or about 840M.
> >
> > Can anyone point me in the right direction and explain what is
happening. I
> > have written a small c code which pulls all of the resource limits and
most
> > are set at unlimited but the stack and pipe. Top and other means of
> > examining the memory indicate that all of the memory is recognized by
the
> > system ... so I am inclined to agree with the Portland guy.
> >
> > Thanks for the help,
> > J Montgomery
>
> An array that size is not going to be on your stack, so I don't think
> that increasing your stack size will help. What error do you get when
> it core dumps?
>
> Cary
------------------------------
From: Shankar Unni <[EMAIL PROTECTED]>
Subject: Distributions on CD (was Re: Free OS ?)
Date: Fri, 18 May 2001 19:34:37 -0700
Jim Cochrane wrote:
> Finding a linux distribution that can be downloaded for free is
> straightforward (although it will take a long time if you have a slow
> connection)
And if you want to save yourself the aggravation of downloading 2 GB of
stuff (for a full RedHat 7.1 distribution), there are several vendors
who'll sell you Linux distributions on CD for "nearly free" (i.e. the
cost of burning and distributing CDs).
E.g. http://www.cheapbytes.com, which sells several distributions of
Linux for under $5 each + s/h. I've used them in the past and they've
been pretty reliable. There are several other such distributors, too..
--
Shankar Unni
[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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
