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 idea.
>
> Regards,
>
>
> Karim
>
>
>
>



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

From: "Nick Lockyer" <[EMAIL PROTECTED]>
Subject: Re: Is there a limit of the number of kernel modules?
Date: Fri, 4 May 2001 10:41:17 +0100

I would think only memory and the number of processes available.  I believe
modules must be in real memory, they cannot be paged out, but I am not
certain on that.  I would not think anybody is ever going to have a problem
though!

Pei Zheng <[EMAIL PROTECTED]> wrote in message
news:9crskq$290d$[EMAIL PROTECTED]...
> Hi there,
> I am wondering that if there is a limit of the number of loadable kernel
> modules for current linux kernel(2.4).
> anybody any idea?
>
> -Pei
>
>



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

From: Wolfram Gloger <[EMAIL PROTECTED]>
Subject: Re: malloc Bug?
Date: 04 May 2001 11:56:21 +0200

Torsten Blank <[EMAIL PROTECTED]> writes:

> Everything works with sysctrl, but changing the parameter shows no
> effect. You can try it. I will append the test program (speichertest)
> at the end of this mail.
> 
> -> "cat /proc/sys/vm/overcommit_memory" shows:
> 
> 0

This variable only has a very specific effect (`overcommit
aggressively' I would call it) when it is _set_.

> -> "speichertest 100" shows:
> 
> speichertest: Blocksize = 100 MByte
> 
...
> memsize = 2800 MByte     ptr = 33c49728

You will only get the `out of memory' effect you're looking for if you
actually touch the pages that you've allocated, _or_ if you start
using resource limits, especially `ulimit -v' (recommended if the
default behaviour worries you).

This has nothing to do with malloc.  It's already been discussed many,
many times.

Regards,
Wolfram.

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

From: Roberto Nibali <[EMAIL PROTECTED]>
Subject: Re: serial port autodetection
Date: Fri, 04 May 2001 12:13:54 +0200

>         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!!

tcgetattr(3)

Cheers,
Roberto Nibali, ratz

-- 
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`

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

From: "Fruitbat" <[EMAIL PROTECTED]>
Subject: Re: Kernel 2.4.4 Problems
Date: Fri, 04 May 2001 10:50:01 GMT

Thanks guys

"ioan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi, Fruitbat, i can confirm that this problem does indeed exist for other
people
> as well, more precisely..me..heh, i have problems when using rp-pppoe 3.0
with
> 2.4.4, i have also tried upgrading pppd to the latest version but it did
no goo,
> i tried reaching you at your e-mail address but it could not be reached so
i
> tried usenet.well, if you do manage to find a solution please e-mail me at
> [EMAIL PROTECTED] (i'll give you my real-email address if you ask for
it,
> main reason not posting it here is obvious, spam ;)
>
> as to what could be causing this problem, my guess would be some changes
in the
> new kernel with regard to ppp, ppp_generic, ppp_async to be more exact.
>
> well, i gotta go, thanks for posting this message here, otherwise i would
have
> also never been able to confirm that im not the only one with this
problem..
>
> take care, also dont reply to this message cause im not a avid usenet user
and i
> will not post another message again, e-mail me and we can discus fixes or
> whatever.
> later..
>
> Fruitbat wrote:
>
> > I have just compiled the 2.4.4 kernel and have found that my pppoe based
> > ADSL connection times out when attempting to connect on my RH7.1 system,
the
> > system log is as follows:
> >
> > Apr 29 10:45:31 fruitbat pppd[1301]: Exit.
> > Apr 29 10:45:57 fruitbat pppd[1351]: pppd 2.4.1 started by root, uid 0
> > Apr 29 10:45:57 fruitbat pppd[1351]: Using interface ppp0
> > Apr 29 10:45:57 fruitbat pppd[1351]: Connect: ppp0 <--> /dev/pts/2
> > Apr 29 10:46:28 fruitbat pppd[1351]: LCP: timeout sending
Config-Requests
> > Apr 29 10:46:28 fruitbat pppd[1351]: Connection terminated.
> > Apr 29 10:46:32 fruitbat pppoe[1352]: Timeout waiting for PADO packets
> > Apr 29 10:46:32 fruitbat pppd[1351]: Exit.
> >
> > I have backed out to kernel 2.4.3 and everything is fine. Has anyone
else
> > experienced this problem with 2.4.4?
> >
> > --
> > ^^Fruitbat^^
>



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

From: Arne Driescher <[EMAIL PROTECTED]>
Subject: Re: losing bottom halves
Date: Fri, 04 May 2001 13:59:38 +0200

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

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

Crossposted-To:  comp.os.linux.hardware
From: jerome corre<[EMAIL PROTECTED]>
Subject: floppy problem with kernel 2.4.2
Date: Fri, 04 May 2001 12:58:06 GMT

hi,

I have just installed Red Hat 7.1 on an old PC,
However I cannot do enything with the floopy (mount, fsck, mk2fs...)
The floppy seems to work as I could access it normally when booting
with RedHat 6.2.

I don't really know what to do to fix the problem? any idea?

Here is the message i get when using 
fsck.ext2 /dev/fd0

May  4 13:43:43 S003 kernel: floppy driver state
May  4 13:43:43 S003 kernel: -------------------
May  4 13:43:43 S003 kernel: now=656638 last interrupt=430 diff=656208 last
called handler=c0166c00
May  4 13:43:43 S003 kernel: timeout_message=redo fd request
May  4 13:43:43 S003 kernel: last output bytes:
May  4 13:43:43 S003 kernel:  0  0 0
May  4 13:43:43 S003 last message repeated 6 times
May  4 13:43:43 S003 kernel:  8 80 429
May  4 13:43:43 S003 last message repeated 3 times
May  4 13:43:43 S003 kernel:  8 80 430
May  4 13:43:43 S003 last message repeated 3 times
May  4 13:43:43 S003 kernel:  e 80 430
May  4 13:43:43 S003 kernel:  8 80 430
May  4 13:43:43 S003 last message repeated 3 times
May  4 13:43:43 S003 kernel: last result at 430
May  4 13:43:43 S003 kernel: last redo_fd_request at 656338
May  4 13:43:43 S003 kernel: 
May  4 13:43:43 S003 kernel: status=ff
May  4 13:43:43 S003 kernel: fdc_busy=1
May  4 13:43:43 S003 kernel: DEVICE_INTR=c0166c00
May  4 13:43:43 S003 kernel: cont=c025c398
May  4 13:43:43 S003 kernel: CURRENT=c10e8840
May  4 13:43:43 S003 kernel: command_status=-1
May  4 13:43:43 S003 kernel: 
May  4 13:43:43 S003 kernel: floppy0: floppy timeout called
May  4 13:43:43 S003 kernel: end_request: I/O error, dev 02:00 (floppy), sector
0

Thanks for any help


Jerome

===========
Mr Jerome Corre 
[EMAIL PROTECTED]

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

From: Karim Atiki <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: simple processus termination
Date: Fri, 04 May 2001 14:16:42 +0200

Hi all,

I've written a simple application which launches a second application
using fork() / execle() functions.
Now, I'd liketo have the possibility to stop the launched application.
What should I use ? kill(pid, SIGTERM)..... Is the first parameter of
kill() the id returned by fork() ?

thanks,

Karim



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

From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: serial port autodetection
Date: Fri, 04 May 2001 13:30:18 GMT

In article <[EMAIL PROTECTED]>, Roberto Nibali wrote:
>>         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!!
>
>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.

-- 
Grant Edwards                   grante             Yow!  What's the MATTER
                                  at               Sid?... Is your BEVERAGE
                               visi.com            unsatisfactory?

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

From: "Stefan" <[EMAIL PROTECTED]>
Subject: Help: Kernel module doesn't compile after kernel upgrade.
Date: Sat, 05 May 2001 15:35:50 +0200

Some time ago I wrote a kernel module for a data acquisition card (Data
Translation 2838). Now, after upgrading my complete system incl. kernel
to debian potato I cannot compile this kernel module anymore. Trouble is:
The errors come from the kernel sources, which I never touched.

I modified an example from the kmpg to clarify what happens:

#include <linux/config.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/fs.h>

int init_module()
{
        printk("Hello world. Kernel-module inserted\n");
        return 0;
}

void cleanup_module()
{
        printk("Hello world. Kernel-module stopped.\n");
}

This, compiled with 
 gcc -O2 -Wall -DMODULE -D__KERNEL__ -DLINUX -c hello.c

leads to abundant error messages in the form of 

In file included from /usr/include/linux/fs.h:272,
                 from hello.c:6:
/usr/include/linux/hpfs_fs_i.h:5: parse error before `ino_t'
/usr/include/linux/hpfs_fs_i.h:5: warning: no semicolon at end of struct or unio
n
and so on.

What can i do, do get the compilation up and running again?

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

From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: Help: Kernel module doesn't compile after kernel upgrade.
Date: Fri, 4 May 2001 15:47:44 +0200

Stefan <[EMAIL PROTECTED]> wrote:
> Some time ago I wrote a kernel module for a data acquisition card (Data
> Translation 2838). Now, after upgrading my complete system incl. kernel
> to debian potato I cannot compile this kernel module anymore. Trouble is:
> The errors come from the kernel sources, which I never touched.

> I modified an example from the kmpg to clarify what happens:

> #include <linux/config.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/fs.h>

> This, compiled with 
>  gcc -O2 -Wall -DMODULE -D__KERNEL__ -DLINUX -c hello.c

> leads to abundant error messages in the form of 

> In file included from /usr/include/linux/fs.h:272,
>                  from hello.c:6:
> /usr/include/linux/hpfs_fs_i.h:5: parse error before `ino_t'
> /usr/include/linux/hpfs_fs_i.h:5: warning: no semicolon at end of
> struct or union
> and so on.

> What can i do, do get the compilation up and running again?

Fix your include headers. You are including /usr/include/linux instead
of /usr/src/linux/include. Replace you /usr/include/linux and
/usr/include/asm with links to the right place, or use -I.

(a kernel programmer should be able to solve that one!)

Peter

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

From: Chris <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: simple processus termination
Date: Fri, 04 May 2001 15:06:50 +0100

Karim Atiki wrote:
> 
> What should I use ? kill(pid, SIGTERM)..... Is the first parameter of
> kill() the id returned by fork() ?

Yes.

-- 
Chris Lightfoot -- chris at ex dash parrot dot com -- www.ex-parrot.com/~chris/
 Never wrestle with a pig.
 You both get dirty, and the pig likes it.

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

Subject: Re: Is linux kernel preemptive??
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 04 May 2001 09:19:43 -0500


Yes, I agree and *think* I have been saying this.  The post
that was replied to makes it clear that such details make no
difference in a macroscopic conversation.  He is unable to
pull back from the microscopic detail, which is great for
coding, but horrible for communication to laymen.  I wonder
how many people here actually understood his latest post?
I doubt many.  I think at this point it safe to say we are
on the same page, just coming from different directions.

Having thought about it a second, I guess I asked for the last
response.  While in the same thread as clearly stating that I
was talking about macroscopic scale, I did ask for the
destinctions, which I thought implied at the macroscopic scale.
Having looked back, I did not say the distinctions at the
macroscopic, which I guess opened the door for that.

At any rate, nuff said...


Thanks,
        Greg


[EMAIL PROTECTED] (Neal Tucker) writes:

> 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

-- 
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
==================================================

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

Crossposted-To: comp.os.linux.development.apps
Subject: Re: simple processus termination
From: Steve Connet <[EMAIL PROTECTED]>
Date: Fri, 04 May 2001 14:22:36 GMT

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?


-- 
Steve Connet            Remove USENET to reply via email
[EMAIL PROTECTED]

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

Subject: Re: IO system throughput
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 04 May 2001 09:26:16 -0500


Hey, thanks for the link.  I didn't know anyone was working on that for Linux.
I guess 2.5 and 2.6 will have AIO in it.  Cool!  From SGI's page, they said that
they saw 35% improvement in database performance tests.  That's pretty awesome!

Thanks again for the link!

Hmmm....just imagine PostgreSQL with AIO implemented....cool beans...  :)  I'm
sure Oracle will be happy to see it too.

Greg


[EMAIL PROTECTED] writes:

> Greg Copeland <[EMAIL PROTECTED]> wrote:
> > 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
> 
> 
> I have recently read a quite complete discussion of the subject that you
> may find interesting. It is
> http://www.kegel.com/c10k.html
> and speaks a lot about linux issues.
> 
> -- 
> 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: STLport 4.0 & g++ 2.96
From: Steve Connet <[EMAIL PROTECTED]>
Date: Fri, 04 May 2001 14:30:25 GMT

"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?

-- 
Steve Connet            Remove USENET to reply via email
[EMAIL PROTECTED]

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

From: "Keith Lomax" <[EMAIL PROTECTED]>
Crossposted-To: 
alt.comp.shareware.programmer,comp.editors,comp.lang.java.help,comp.lang.java.programmer,comp.lang.java.softwaretools,comp.os.linux.advocacy
Subject: Re: Need your recommendation for a full-featured text editor
Date: Fri, 4 May 2001 14:57:48 +0000 (UTC)

If you program often, I would highly recommend VisualSlickEdit. It is
wonderful for Java.

Keith Lomax

Nils O. Selåsdal <[EMAIL PROTECTED]> wrote in article
<40WH6.5332$[EMAIL PROTECTED]>...
> 
> "Nick Lockyer" <[EMAIL PROTECTED]> wrote in message
> news:9cp672$hs0$[EMAIL PROTECTED]...
> > ultra edit version 8 for Windows
> > How about kdevelop, part of the KDE.  It is a compete
> > editor/compiler/linker/debugger all in one!
> Unfortunatly it doesnt work wery well...
> 
> 
> 
> 

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

Crossposted-To: comp.unix.programmer
Subject: Large file support on Linux?
From: Dragan Cvetkovic <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: 04 May 2001 10:59:48 -0400


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

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


** 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
******************************

Reply via email to