Linux-Development-Sys Digest #691, Volume #8 Fri, 4 May 01 13:13:09 EDT
Contents:
Just a curiosity... (David Vidal Rodriguez)
Re: Just a curiosity... (Lew Pitcher)
Re: losing bottom halves ("Barry Smyth")
Re: Just a curiosity... (Lew Pitcher)
Re: STLport 4.0 & g++ 2.96 ("Peter T. Breuer")
Re: simple processus termination ("Peter T. Breuer")
Re: Just a curiosity... (David Vidal Rodriguez)
Re: Just a curiosity... ("Peter T. Breuer")
Re: serial port autodetection (Roberto Nibali)
Re: Just a curiosity... (Florian =?iso-8859-1?Q?Gro=DFe=2DCoosmann?=)
Transport Layer Protocols ("J.P. Foster")
Re: Large file support on Linux? (Greg Copeland)
Re: losing bottom halves (=?iso-8859-1?Q?Andr=E9?= David)
Re: Transfer data to mySQL Server ("Julia Donawald")
Re: simple processus termination (Greg Copeland)
Re: serial port autodetection (Grant Edwards)
Re: Large file support on Linux? (Andreas Jaeger)
----------------------------------------------------------------------------
From: David Vidal Rodriguez <[EMAIL PROTECTED]>
Subject: Just a curiosity...
Date: Fri, 04 May 2001 17:20:57 +0200
Hi out there!
Yesterday I was "playing" the following game with my computer:
# echo -n "a" > foo
# cat foo | cat >> foo
# ls -l foo # (2 bytes)
# cat foo | cat >> foo
# ls -l foo # (4 bytes)
...
If you go on doing this (stupid) procedure, you'll get a file called foo
with 8, 16, 32, 64, 128,... bytes, that's (still) no problem. But try it
when foo has 32768 bytes! Instead of becoming a 64k file, the file
system becomes full. So what's going on here exactly? The kernel's
version is 2.4.0.
Regards...
--
------------------------------------------------------------------------
David Vidal R. ([EMAIL PROTECTED])
------------------------------
From: [EMAIL PROTECTED] (Lew Pitcher)
Subject: Re: Just a curiosity...
Reply-To: [EMAIL PROTECTED]
Date: Fri, 04 May 2001 15:39:38 GMT
On Fri, 04 May 2001 17:20:57 +0200, David Vidal Rodriguez
<[EMAIL PROTECTED]> wrote:
>Hi out there!
>Yesterday I was "playing" the following game with my computer:
>
># echo -n "a" > foo
># cat foo | cat >> foo
># ls -l foo # (2 bytes)
># cat foo | cat >> foo
># ls -l foo # (4 bytes)
>...
>If you go on doing this (stupid) procedure, you'll get a file called foo
>with 8, 16, 32, 64, 128,... bytes, that's (still) no problem. But try it
>when foo has 32768 bytes! Instead of becoming a 64k file, the file
>system becomes full. So what's going on here exactly? The kernel's
>version is 2.4.0.
>
>Regards...
My guess would be that 'cat' uses a 32K read buffer.
cat is probably written like this:
loop until EOF
read up to 32 K
write the read block
end-loop
For files that are less than 32K long, the first read gathers the
entire file and encounters EOF. The write appends the data, and the
loop terminates.
For files that are 32K or greater, the first read gathers the first
32K, but doesn't encounter EOF within the block. The write appends the
first 32K, and the loop starts again. Now, we read the next 32K, but
(because we just _appended_ 32K to the buffer) we won't get the EOF on
this block either (at best, we read into the block of data that we
just wrote). The loop continues until there's no more space to write
to, or until externally interrupted, because it can't encounter EOF
with any single read.
(BTW: the same behaviour occurs on the 2.2.13 kernel)
Lew Pitcher, Information Technology Consultant, Toronto Dominion Bank Financial Group
([EMAIL PROTECTED])
(Opinions expressed are my own, not my employer's.)
------------------------------
From: "Barry Smyth" <[EMAIL PROTECTED]>
Subject: Re: losing bottom halves
Date: Fri, 4 May 2001 16:45:22 +0100
"Arne Driescher" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Barry Smyth wrote:
> >
> > Hi,
> >
> > I am writing a driver for a PCI card using interrupts. I have a main
> > interrupt service routine and inside this I schedule a bottom half to
the
> > immediate task queue.
> >
> > Most of the time when running the program everything works fine, however
> > occasionally all the interrupts occur and the isr gets run but the
bottom
> > half does not occur for every interrupt.
> Just a wild guess: you forgot to call mark_bh(IMMEDIATE_BH) after
> queuing the task?
>
> >
> > I have replaced the scheduling of the bottom half with a direct call to
the
> > bottom half from the interrupt service routine and the program works
every
> > time.
> >
> > Could anyone explain why skipping of bottom halves could be occuring
when
> > using scheduling? Is it because the code in the bottom half takes too
long
> > to run? If it is then why does calling the bottom half directly fix the
> > problem?
> BH have been designed to handle exactly the case where the irq-handler
> might
> need more time to handle the request than it has till the next IRQ.
> However,
> to use this concept you have to remember that the IRQ handler must
> save all data that might change between IRQs (e.g. must read all PCI
> card data registers).
> The BH will than work on these data and never on the hardware.
>
> >
> > I am using kernel 2.2.17.
> >
> > Thanks
>
>
> -Arne
Thanks Arne,
I was using the mark_bh(IMMEDIATE_BH) statement after adding the BH to the
immediate task queue.
I have replaced all my code in the BH with one printk statement to show when
the BH is called. I also have a printk statement in the isr directly before
I add the BH to the task queue.
In running the application 256 interrupts are generated from the PCI card.
However once in every 7 or 8 times I run the application, the printk
statement in the isr routine gets displayed 256 times but the BH printk
statement only gets displayed 255 times. So the BH is not being run for one
of the interrupts.
With the original code in the BH, the BH gets run sometimes the full 256
times but other times only about 240. I am starting to wonder if it is a
problem with the kernel.
Anyone any ideas?
Thanks.
Barry
------------------------------
From: [EMAIL PROTECTED] (Lew Pitcher)
Subject: Re: Just a curiosity...
Reply-To: [EMAIL PROTECTED]
Date: Fri, 04 May 2001 15:49:36 GMT
On Fri, 04 May 2001 15:39:38 GMT, [EMAIL PROTECTED] (Lew Pitcher)
wrote:
>On Fri, 04 May 2001 17:20:57 +0200, David Vidal Rodriguez
><[EMAIL PROTECTED]> wrote:
>
>>Hi out there!
>>Yesterday I was "playing" the following game with my computer:
>>
>># echo -n "a" > foo
>># cat foo | cat >> foo
>># ls -l foo # (2 bytes)
>># cat foo | cat >> foo
>># ls -l foo # (4 bytes)
>>...
>>If you go on doing this (stupid) procedure, you'll get a file called foo
>>with 8, 16, 32, 64, 128,... bytes, that's (still) no problem. But try it
>>when foo has 32768 bytes! Instead of becoming a 64k file, the file
>>system becomes full. So what's going on here exactly? The kernel's
>>version is 2.4.0.
>>
>>Regards...
>
>My guess would be that 'cat' uses a 32K read buffer.
>cat is probably written like this:
> loop until EOF
> read up to 32 K
> write the read block
> end-loop
>
>For files that are less than 32K long, the first read gathers the
>entire file and encounters EOF. The write appends the data, and the
>loop terminates.
>
>For files that are 32K or greater, the first read gathers the first
>32K, but doesn't encounter EOF within the block. The write appends the
>first 32K, and the loop starts again. Now, we read the next 32K, but
>(because we just _appended_ 32K to the buffer) we won't get the EOF on
>this block either (at best, we read into the block of data that we
>just wrote). The loop continues until there's no more space to write
>to, or until externally interrupted, because it can't encounter EOF
>with any single read.
Some playing with this shows that the 'cat' buffer is less than 32K
long (somewhere between 16K and 32K for sure).
Lew Pitcher, Information Technology Consultant, Toronto Dominion Bank Financial Group
([EMAIL PROTECTED])
(Opinions expressed are my own, not my employer's.)
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: STLport 4.0 & g++ 2.96
Date: Fri, 4 May 2001 17:27:09 +0200
Steve Connet <[EMAIL PROTECTED]> wrote:
> "D. Stimits" <[EMAIL PROTECTED]> writes:
>> Steve Connet wrote:
>> > c++: Internal error: Segmentation fault (program cpp0)
>>
>> It isn't unusual to see an error similar to that when a template is
>> told to work with a data type that it does not know about (such as
>> because it is missing the right include file to understand that
>> type). Check to be sure that any type the template is told to use
>> has its definition available to the templates.
> I am getting that internal error at random places during compile of
> the STLport 4.0. I've tried many times now.
Turn off optimization when compiling those files (unless they're kernel
files, when -O is needed for inlining to work).
Peter
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: simple processus termination
Date: Fri, 4 May 2001 17:28:10 +0200
In comp.os.linux.development.system Steve Connet <[EMAIL PROTECTED]> wrote:
> Chris <[EMAIL PROTECTED]> writes:
> What's the difference between:
> kill(pid, SIGTERM);
> and
> raise(SIGTERM);
> Which one is preferred?
They're not comparable. One sends a signal to your process. One sends a
signal to any porcess. The man page is clear on the issue.
Peter
------------------------------
From: David Vidal Rodriguez <[EMAIL PROTECTED]>
Subject: Re: Just a curiosity...
Date: Fri, 04 May 2001 17:55:11 +0200
Lew Pitcher wrote:
>
> My guess would be that 'cat' uses a 32K read buffer.
> cat is probably written like this:
> loop until EOF
> read up to 32 K
> write the read block
> end-loop
>
> For files that are less than 32K long, the first read gathers the
> entire file and encounters EOF. The write appends the data, and the
> loop terminates.
>
> For files that are 32K or greater, the first read gathers the first
> 32K, but doesn't encounter EOF within the block. The write appends the
> first 32K, and the loop starts again. Now, we read the next 32K, but
> (because we just _appended_ 32K to the buffer) we won't get the EOF on
> this block either (at best, we read into the block of data that we
> just wrote). The loop continues until there's no more space to write
> to, or until externally interrupted, because it can't encounter EOF
> with any single read.
That's what I've imagined. So pipes don't send data to the destination process when the
source has reached EOF but do the job in blocks (of 32k in this case), isn't it? But
what is responsible for this, "cat" or the kernel?
--
------------------------------------------------------------------------
David Vidal R. ([EMAIL PROTECTED])
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: Just a curiosity...
Date: Fri, 4 May 2001 17:48:06 +0200
David Vidal Rodriguez <[EMAIL PROTECTED]> wrote:
> Hi out there!
> Yesterday I was "playing" the following game with my computer:
> # echo -n "a" > foo
> # cat foo | cat >> foo
> # ls -l foo # (2 bytes)
> # cat foo | cat >> foo
> # ls -l foo # (4 bytes)
> ...
> If you go on doing this (stupid) procedure, you'll get a file called foo
> with 8, 16, 32, 64, 128,... bytes, that's (still) no problem. But try it
> when foo has 32768 bytes! Instead of becoming a 64k file, the file
> system becomes full. So what's going on here exactly? The kernel's
> version is 2.4.0.
You appear to have pipes with a 32KB buffer.
Peter
------------------------------
From: Roberto Nibali <[EMAIL PROTECTED]>
Subject: Re: serial port autodetection
Date: Fri, 04 May 2001 18:01:52 +0200
> >> any keyword will be apreciated!!
> >
> >tcgetattr(3)
>
> Care to elaborate? I've been doing Unix serial programming for
> 15 years, and I don't see how you can autodetect anything using
> tcgetattr.
Well, I obviously seem to have completely misunderstood the OP
question and you obviously remarked that I haven't yet done huge
serial programming stuff. With tcgetattr you get the serial terminal
control settings from the termios structure. I thought by getting
the struct termios options you get everything you need on how to
send your data but then again this is really not autodetect. You're
right and I apologize to the OP.
But if you did 15 years of serial programming, could you explain
me what autodetection on serial port really means and could you
give an example?
Another question: I've been writing some serial stuff too. I'm
never sure about the CBAUDEX. Example:
struct termios options;
void set_options(void) {
tcgetattr(fd, &options);
options.c_cflag |= (CLOCAL | CREAD);
options.c_cflag &= ~PARENB;
.
.
.
/* maybe we have to set cfsetispeed(&options, B115200 & CBAUDEX);
* to enable higher then POSIX.1 speeds (57600 baud). See
* cfsetiospeed(3) for further information.
*/
cfsetispeed(&options, B115200);
cfsetospeed(&options, B115200);
tcsetattr(fd, TCSANOW, &options);
}
Is the CBAUDEX needed to proper address the B115200 speed?
Best regards,
Roberto Nibali, ratz
--
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`
------------------------------
From: Florian =?iso-8859-1?Q?Gro=DFe=2DCoosmann?= <[EMAIL PROTECTED]>
Subject: Re: Just a curiosity...
Date: Fri, 04 May 2001 18:05:21 +0200
"Peter T. Breuer" wrote:
> You appear to have pipes with a 32KB buffer.
Pipes have buffers of exactly one page, e.g. 4K on x86.
Cheers, Florian
------------------------------
From: "J.P. Foster" <[EMAIL PROTECTED]>
Subject: Transport Layer Protocols
Date: Fri, 04 May 2001 17:29:00 +0100
Looking for advice as to where new transport
layer protocols should be added.
In the kernel, alongside UDP and TCP or
In the user space calling BSD or INET sockets
with the packet to go out on IP directly.
I have no views on this either way. My main
priority would be an elegant solution and am
open to other alternatives.
J.P.
--
;'
,.,
=============================== ,'` / /
John-Paul Foster ' / /__
T A L I T Y ' | / /
Senior Consulting Engineer .''` _/
email: [EMAIL PROTECTED] '.' .'__
1 The Alba Campus . '| * \
Livingston .'/ .'
Scotland /__,.''` ScS
------------------------------
Crossposted-To: comp.unix.programmer
Subject: Re: Large file support on Linux?
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 04 May 2001 11:38:15 -0500
Let me say up front that I've never used LFS on Linux before. So,
this is completely a guess. Do you know if you have to link with
another library like, lfs.a?
For what it's worth, here's a link which talks about getting kernel
support for LFS. It says 2.4 has default support for it. Since
you say you are using 2.2.16 (BTW, that kernel has a possible
root exploit, you may want to upgrade), you may want to look here:
http://www.sas.com/service/admin/unix/linux/lfs/
So, based on that, I *guess* you don't need to link any different,
rather, just make sure your kernel has proper support.
Thanks,
Greg
Dragan Cvetkovic <[EMAIL PROTECTED]> writes:
> Hi,
>
> I am trying to enable LFS on Linux Redhat 6.2 and although I am setting all
> predefines as in documentation i.e.
>
> #define _LARGEFILE_SOURCE
> #define _LARGEFILE64_SOURCE
> #define _FILE_OFFSET_BITS 64
>
> gcc will still use open and pwrite instead of open64 and pwrite64 and
> therefore fail at 2GB. Even if I use open64 and pwrite64 explicitly in my
> program, it still fails on 2GB. The size of off_t is 8 bytes, though. So,
> what I am doing wrong?
>
> The system in question is RedHat 6.2 (I think) with Linux 2.2.16,
> glibc-2.1.3 and egcs-2.91.66
>
> Thanks a lot, Dragan
>
> --
> Dragan Cvetkovic,
>
> To be or not to be is true. G. Boole
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
From: =?iso-8859-1?Q?Andr=E9?= David <[EMAIL PROTECTED]>
Subject: Re: losing bottom halves
Date: Fri, 04 May 2001 18:25:29 +0200
This is a multi-part message in MIME format.
==============795A93FB06F7C6DE2D50CA50
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> I have replaced all my code in the BH with one printk statement to show when
> the BH is called. I also have a printk statement in the isr directly before
> I add the BH to the task queue.
I think I read somewhere that you shouldn't rely in printk inside
isr's...
HIH,
Andre
--
"Share the code. If you hide it ain't good."
Popular knowledge
==============795A93FB06F7C6DE2D50CA50
Content-Type: text/x-vcard; charset=us-ascii;
name="Andre.David.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for André David
Content-Disposition: attachment;
filename="Andre.David.vcf"
begin:vcard
n:David;André
tel;work:+41792013849
x-mozilla-html:FALSE
org:CERN - Centre Europeen de Recherche Nucleaire;Experimental Physics Division - NA60
Experiment
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
note:Geneva, Switzerland
x-mozilla-cpt:;-11552
fn:André David
end:vcard
==============795A93FB06F7C6DE2D50CA50==
------------------------------
From: "Julia Donawald" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Transfer data to mySQL Server
Date: Fri, 4 May 2001 18:51:55 +0200
Hi,
> However, I am getting this feeling that you are developing an application
> which is purely using the DBMS as a data store while allowing a client
program
> to maniuplate the data.
Yes, you are right! I want only to insert some data in a table on a mySQL
database.
>
> If that is the case, then you will want to look at the MySQL manual and
> interface with the database over its TCP/IP port.
I have download the manual, but I really can't find some usefull information
on this kind of problem.
How will I communicate over the internet ( without ODBC ) with mySQL?
Bye and thanks in advance
Julia
------------------------------
Crossposted-To: comp.os.linux.development.apps
Subject: Re: simple processus termination
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 04 May 2001 11:50:49 -0500
Steve Connet <[EMAIL PROTECTED]> writes:
> Chris <[EMAIL PROTECTED]> writes:
>
> > Karim Atiki wrote:
> > >
> > > What should I use ? kill(pid, SIGTERM)..... Is the first parameter of
> > > kill() the id returned by fork() ?
> >
> > Yes.
>
> What's the difference between:
>
> kill(pid, SIGTERM);
>
> and
>
> raise(SIGTERM);
>
> Which one is preferred?
>
You may want to do a "man 2 _exit". This will allow your child process to
gracefully terminate. Your parent process can then simply issue a wait(),
or a waitpid() to monitor the termination of the child. I personally prefer
waitpid().
As someone else already pointed out, raise will signal the current process,
I'm assuming it would be the parent, in this case it being SIGTERM, while
kill will signal the designated process, as specified by the pid, with the
desired signal. They are very different indeed.
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: serial port autodetection
Date: Fri, 04 May 2001 16:53:56 GMT
In article <[EMAIL PROTECTED]>, Roberto Nibali wrote:
>> >> any keyword will be apreciated!!
>> >
>> >tcgetattr(3)
>>
>> Care to elaborate? I've been doing Unix serial programming for
>> 15 years, and I don't see how you can autodetect anything using
>> tcgetattr.
>
>I thought by getting the struct termios options you get
>everything you need on how to send your data but then again
>this is really not autodetect.
Sorry if I sounded over sarcastic -- it's been one of those
days...
The termios struct only tells you the current settings for the
serial port on your end. It doesn't tell you the settings for
the serial port on the other end of the cable.
Autodetection refers to the ability to automatically detect the
characteristics (baud, parity, etc.) of receive data and adapt
accordingly. For example, when you hook up a serial port to
most modern modems you don't have to set the baud rate in the
modem. You send it a string starting with "AT" and it
autodetects the baud rate etc. and adjusts it's settings to
match.
--
Grant Edwards grante Yow! This ASEXUAL
at PIG really BOILS
visi.com my BLOOD... He's
so... so... URGENT!!
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: Large file support on Linux?
Date: 04 May 2001 17:53:02 +0200
Dragan Cvetkovic <[EMAIL PROTECTED]> writes:
> Hi,
>
> I am trying to enable LFS on Linux Redhat 6.2 and although I am setting all
> predefines as in documentation i.e.
>
> #define _LARGEFILE_SOURCE
> #define _LARGEFILE64_SOURCE
> #define _FILE_OFFSET_BITS 64
>
> gcc will still use open and pwrite instead of open64 and pwrite64 and
> therefore fail at 2GB. Even if I use open64 and pwrite64 explicitly in my
> program, it still fails on 2GB. The size of off_t is 8 bytes, though. So,
> what I am doing wrong?
>
> The system in question is RedHat 6.2 (I think) with Linux 2.2.16,
> glibc-2.1.3 and egcs-2.91.66
Read http://www.suse.de/~aj/linux_lfs.html
You need to recompile glibc and a kernel that understands LFS.
Andreas
--
Andreas Jaeger
SuSE Labs [EMAIL PROTECTED]
private [EMAIL PROTECTED]
http://www.suse.de/~aj
------------------------------
** 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
******************************
