Linux-Development-Sys Digest #689
Linux-Development-Sys Digest #689, Volume #8 Fri, 4 May 01 04:13:14 EDT Contents: Re: IO system throughput (Greg Copeland) Re: Is linux kernel preemptive?? (Greg Copeland) Re: IO system throughput ([EMAIL PROTECTED]) programming the serial port (Javier Loureiro Varela) Re: Cannot get PHP 4 to compile for my system (Bjorn Pearson) Re: About jiffies in Kernel (=?iso-8859-1?Q?Andr=E9?= David) Re: Interprocess Communication...help (Eric P. McCoy) Re: Cannot load shared object file (Martin) Re: how to register a pci device? Re: About jiffies in Kernel Re: Transfer data to mySQL Server (Frank Ranner) Test (Mulder H.) STLport 4.0 g++ 2.96 (Steve Connet) Hot plug PCI device (Mulder) Re: Is linux kernel preemptive?? (Rik van Riel) Re: Startup service (D. Stimits) Re: Hot plug PCI device (D. Stimits) Re: STLport 4.0 g++ 2.96 (D. Stimits) Re: malloc Bug? (Torsten Blank) Subject: Re: IO system throughput From: Greg Copeland [EMAIL PROTECTED] Date: 03 May 2001 11:17:28 -0500 It's important to remember that the implementation requires kernel support. This is the only way it can dispatch on the number and type of events that it can. Think of this as being a hybrid approach much in the same way that threads often require both kernel and user space support. Greg [EMAIL PROTECTED] writes: Greg Copeland [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: [snip] What do you think of the following system call that exists under FreeBSD and allows to do the thing you like, if i don't err: int kqueue(void) Ya, I read an article about this a number of months back. I think it's pretty cool. From that I've *read*, it is doing exactly what I've been talking about. My memory is a little fuzzy on this, but I think a similar project is underway for Linux. I don't remember if it was being built on the kqueue system or not. Sorry. As for how well the above implementation works, I honestly don't know, but from what I've read, they've done an excellent job. From what i have read also in FreeBSD mailing lists, this mechanisms allows very good performance in some cases. Note that forking a new process is extremely fast on Linux, more than in FreeBSD, so that this mechanism is perhaps not as useful as in FreeBSD. -- 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 -- -- Michel Talon -- 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 == -- Subject: Re: Is linux kernel preemptive?? From: Greg Copeland [EMAIL PROTECTED] Date: 03 May 2001 11:35:53 -0500 Thanks. That's been my point. Please clarify why you think that interrupt handlers do not count as system calls. Let's review this. Both reside within the kernel. Both are functions. Both are called to service a specific level of functionality. The only distinction is that one is invoked directly by an asynchronous interrupt handler while the other is a synchronous call. Hardly worth making the distinction unless you are getting into a microscopic conversation, which I have pointed out that I was specifically trying to avoid. Now then, since I feel sure that we can agree on the above, adding this level of detail to a high level conversation, I would submit, offers no additional value. Keep in mind, interrupt handlers can and do call other system calls. In essence, when you say an interrupt handler, you are really describing an asynchronous entry point to a system call. In the original conversation, the fact that something was being called asynchronously was specifically deemed, by me, as irrelevant because the level of detail at that point in time could not make any meaningful distinction as to it exact behavior to make mention worthy. The use of system call is a very ambiguous term which I feel people often assign specific attributes that does not really exist. I like to avoid all of that and think of system calls as just that. A function residing within the system. In this case, I think of system as being the kernel. I find that for the vast majority of conversations, the concept holds true and greatly simplifies the thread as far fewer assumptions are needed by the participants. Hope this helps. Thanks, Greg [EMAIL PROTECTED] (Neal Tucker) writes: Greg Copeland [EMAIL PROTECTED] wrote: Kasper Dupont [EMAIL PROTECTED] writes: A system call cannot preempt another system call, no matter what the system looks
Linux-Development-Sys Digest #690
Linux-Development-Sys Digest #690, Volume #8 Fri, 4 May 01 11:13:18 EDT Contents: serial port autodetection (Javier Loureiro Varela) Re: Is linux kernel preemptive?? (Neal Tucker) losing bottom halves (Barry Smyth) Re: Interprocess Communication...help (Nick Lockyer) Re: Is there a limit of the number of kernel modules? (Nick Lockyer) Re: malloc Bug? (Wolfram Gloger) Re: serial port autodetection (Roberto Nibali) Re: Kernel 2.4.4 Problems (Fruitbat) Re: losing bottom halves (Arne Driescher) floppy problem with kernel 2.4.2 (jerome corre) simple processus termination (Karim Atiki) Re: serial port autodetection (Grant Edwards) Help: Kernel module doesn't compile after kernel upgrade. (Stefan) Re: Help: Kernel module doesn't compile after kernel upgrade. (Peter T. Breuer) Re: simple processus termination (Chris) Re: Is linux kernel preemptive?? (Greg Copeland) Re: simple processus termination (Steve Connet) Re: IO system throughput (Greg Copeland) Re: STLport 4.0 g++ 2.96 (Steve Connet) Re: Need your recommendation for a full-featured text editor (Keith Lomax) Large file support on Linux? (Dragan Cvetkovic) From: [EMAIL PROTECTED] (Javier Loureiro Varela) Subject: serial port autodetection Date: Fri, 04 May 2001 09:04:27 GMT hI! I'd like to autodetect some params from a serial port attached to my serial port (like modems do). I was searching for it, but I dont know where to start on. any keyword will be apreciated!! -- signed, Javier Loureiro Varela Class One System Research Leader -- From: [EMAIL PROTECTED] (Neal Tucker) Subject: Re: Is linux kernel preemptive?? Date: 4 May 2001 02:09:45 -0700 Greg Copeland says: The use of system call is a very ambiguous term which I feel people often assign specific attributes that does not really exist. I like to avoid all of that and think of system calls as just that. A function residing within the system. In this case, I think of system as being the kernel. This is where we differ. As I was taught in my Operating Systems classes back in school, a system call is a function in the kernel which a user level program calls to use the OS functionality. The system calls are the interface to the OS from the applications. At any rate, the whole disagreement in this thread is based on you guys not agreeing on the terminology. It doesn't matter how you define system call, as long as the participants agree on how to define it. You don't, so your discussion is going in circles. -Neal Tucker -- From: Barry Smyth [EMAIL PROTECTED] Subject: losing bottom halves Date: Fri, 4 May 2001 10:11:07 +0100 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. 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? I am using kernel 2.2.17. Thanks -- From: Nick Lockyer [EMAIL PROTECTED] Crossposted-To: comp.os.linux.development.apps Subject: Re: Interprocess Communication...help Date: Fri, 4 May 2001 10:44:57 +0100 Another really good book which clearly shows this with nice pretty picture (which even I could follow) is the Beginning Linux Programming, ISBN 1861002971 (see www.amazon.co.uk/www.amazon.com). Karim Atiki [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hi all, I have to implement a way to communicate between tow applications. For some reasons, I've chosen the pipe() function . Basically, her's what I want to do: 1) I've an application, qt based,named APP1. this application gets some parameters from Gfx Widgets. Then , user pushes a run button in order to launch another application (APP2) I launch it by using fork() and execle() 2) So the next step is: to communicate between the 2 application. I want APP1 gives orders to APP2 such like RUN, PAUSE, RESUME. For each of these commands, I want APP2 to notifiy APP1 that commands have been correctly handled. So, I'm not very experienced with Interprocess-Communication under Unix/Linux. I would like to know how should my applications structured in order to manage such an IPC. How should I use the fork() and pipe() calls ? Please let me know if you have an
Linux-Development-Sys Digest #691
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
Linux-Development-Sys Digest #692
Linux-Development-Sys Digest #692, Volume #8 Fri, 4 May 01 16:13:19 EDT Contents: Re: STLport 4.0 g++ 2.96 (John Beardmore) Re: Large file support on Linux? (Dragan Cvetkovic) Re: serial port autodetection (John Beardmore) Re: losing bottom halves (Barry Smyth) Re: serial port autodetection (Roberto Nibali) Re: simple processus termination (Nate Eldredge) Re: Hot plug PCI device (Philip Armstrong) Re: STLport 4.0 g++ 2.96 (Philip Armstrong) Re: serial port autodetection (Grant Edwards) Re: Large file support on Linux? ([EMAIL PROTECTED]) Re: serial port autodetection (Grant Edwards) Re: Hot plug PCI device (=?iso-8859-1?Q?Andr=E9?= David) Re: simple processus termination Re: Just a curiosity... Re: Large file support on Linux? (Greg Copeland) Re: How to get a number of processors (Greg Copeland) Re: Transfer data to mySQL Server (D. Stimits) Re: Large file support on Linux? (Dragan Cvetkovic) From: John Beardmore [EMAIL PROTECTED] Subject: Re: STLport 4.0 g++ 2.96 Date: Fri, 4 May 2001 18:17:04 +0100 In message [EMAIL PROTECTED], Steve Connet [EMAIL PROTECTED] writes D. Stimits [EMAIL PROTECTED] writes: Steve Connet wrote: I am trying to compile the STLport4.0 with g++ 2.96. I get to a file called money_put_w.cpp and I get the following: 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. Well I think it turns out gcc 2.96 was a beta compiler and never released, and has major problems. But Redhat [mistakenly] decided to put it in their RH7.0 system anyway. And like I said before, I heard it's almost next to impossible to revert back to an older version of gcc (ie. 2.95) on a RH7.0 system that has gcc 2.96 on it. So it looks like my only option here is to move forward with the beta GCC 3.0 branch, of which I've heard only good things so far. And since the GCC 3.0 beta branch has more support for the Standard C++ Library (ie. ostringstream istringstream), I won't have to compile STLport 4.0 anyway. Anyone else in the same boat as I or who have gone through a similar experience? I have RH 6.2 and upgraded 2.91.66 with 2.95.3. That fixed the problem with ostringstream and ifstream but I've not used it much yet. As that problem was resolved by upgrading the compiler, I didn't install the copy of STLport that I downloaded. I don't understand how it interacts with the two compilers that I now have installed and don't want to break what doesn't need fixing ! If you upgrade to RH 7.1, does that get you a safe compiler ? Do you nave any reason to stick with 7.0 ? Cheers, J/. -- John Beardmore -- Subject: Re: Large file support on Linux? From: Dragan Cvetkovic [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: 04 May 2001 13:24:08 -0400 Andreas Jaeger [EMAIL PROTECTED] writes: 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 Yes, I did read that one and found the most helpful info there. Thanks a lot for the information provided. However, it doesn't mention RedHat 6.2 so I just hoped RH had included some patches of their own. However, it seem not to be the case. :-( You need to recompile glibc and a kernel that understands LFS. Unfortunately this is (at this stage) not possible since this is one of our main developers' machine that a lot of people rely on. It seems that I will have to exclude LFS on Linux for the time being :-( since we can't force the customers to run latest and the best Linux distro (with kernel 2.4.x and glibc-2.2). Thanks a lot to all answers. Dragan Andreas -- Andreas Jaeger SuSE Labs [EMAIL PROTECTED] private [EMAIL PROTECTED] http://www.suse.de/~aj -- Dragan Cvetkovic, To be or not to be is true. G. Boole -- From: John Beardmore [EMAIL PROTECTED] Subject: Re: serial port autodetection Date: Fri, 4 May 2001 18:22:31 +0100 In message E8BI6.22342$[EMAIL PROTECTED], Grant Edwards [EMAIL PROTECTED] writes You send it a string starting with AT and it autodetects the baud rate etc. and adjusts it's settings to match. But modems seem to get the baud rate set very quickly, within one or two characters in fact. Are they just getting lucky with the UART settings, or are they doing something smarted along the lines of looking 'around' they UART to the incoming wave form and working out the baud rate from the length of the start
