Linux-Development-Sys Digest #534, Volume #6     Fri, 26 Mar 99 11:14:11 EST

Contents:
  Re: Device Drivers - IOCTL (Scott Lanning)
  Re: RS485 & Linux: Must toggle DTR quickly (Etienne Lorrain)
  /dev/tun (Andreas Gustafsson)
  Re: Devloping Linux apps on NT? (Gordon Scott)
  Re: Linux Driver help needed (Polled interface) (Gerard van der Sel)
  ISP Hookup, doesn't work ?? ([EMAIL PROTECTED])
  scandir problem... ("Thierry BUCCO")
  Re: modprobe ERROR -- what's wrong??? (Karl Heyes)
  NT has IOCompletionPort() ("jacob")
  Re: Device Drivers - IOCTL (Mark Tranchant)
  Re: 256 threads limit on linux (Existant)
  Re: After Week 1 With Linux -- licking wounds. ("Anders Östling")
  Re: /dev/tun (Emile van bergen)
  Re: Compiling 2.2.4, error in kernel/acct.c (Bernd Strieder)
  Re: DMA cache cohrency? (Robert Kaiser)
  Re: Intel i/o chip has bug? ( lpt ) (Roope Anttinen)
  Re: RS485 & Linux: Must toggle DTR quickly (Peter)
  Re: Where can I find the ELF format specification. (Kalle Olavi Niemitalo)
  Re: modprobe ERROR -- what's wrong??? ("Dan")
  Re: Debugging terrible stack corruption problems - tips or tools? (Erwin S. 
Andreasen)

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

From: [EMAIL PROTECTED] (Scott Lanning)
Subject: Re: Device Drivers - IOCTL
Date: 25 Mar 1999 13:50:42 GMT

jacob ([EMAIL PROTECTED]) wrote:
: no , he wants to know how u can do the same from user-space instead of
: kernel-space (moron)!

At least he can spell and capitalize (asshole)....

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

From: Etienne Lorrain <[EMAIL PROTECTED]>
Crossposted-To: comp.arch.embedded
Subject: Re: RS485 & Linux: Must toggle DTR quickly
Date: Fri, 26 Mar 1999 09:21:51 +0000
Reply-To: [EMAIL PROTECTED]

  Hi,

Olav Woelfelschneider wrote:

> [...] So, to send some data, I turn DTR on, write() the bytes and turn DTR off
> again after the last byte fell out of the UART.
>
> Now waiting for end of transmission to turn off DTR is my problem.
>
> If I use tcdrain() to wait, it takes too long, since the kernel doesn't
> return quick enough to my process for it to turn DTR off. This means I
> lose the response from the device which received the data, as it answers
> really quick.
>
> The alternative is a busy loop polling with TIOCSERGETLSR, waiting for
> end of transmission. This works, but I don't like it, since it hogs the
> CPU, uses tons of system calls and feels very ugly. [...]

  The main problem here is hardware: none of the 16450, 16550 and
 other UART give the information "char completely sent", they just
 give the information "Tx serialisator empty"... a small difference: the
 stop and parity bits. Linux could calculate when the char will go
 out of the chip to switch a pin (quite a complex calculus) but after
 some experiment you will see that each manufacturer has implemented
 the "Tx serialisator empty" bit his own way and the only way to
 get reliable result is to wait "enough" before returning to tcdrain().
  I do not think there is a software solution to your problem...

  Etienne.


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

From: [EMAIL PROTECTED] (Andreas Gustafsson)
Subject: /dev/tun
Date: 26 Mar 1999 12:56:03 +0200

Does Linux have anything similar to the /dev/tun driver in BSD-derived
systems?  This is a pseudo-device for tunneling IP packets between the
kernel and a user process.  On the kernel side, it behaves like a
network interface and is recognized by ifconfig, netstat, etc.  A user
process can access the packet queues of this network interface by
opening a corresponding character device /dev/tun0 and reading and
writing IP packets using read(2) and write(2).

Note that this functionality is entirely different from that other
kind of "tunneling", encapsulating packets in other packets (as in
GRE).  It is also not quite the same thing as packet capture,
as discussed in the "Raw IP Networking FAQ".
-- 
Andreas Gustafsson, [EMAIL PROTECTED]

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

From: [EMAIL PROTECTED] (Gordon Scott)
Subject: Re: Devloping Linux apps on NT?
Date: 26 Mar 1999 11:20:03 GMT
Reply-To: Gordon Scott <[EMAIL PROTECTED]>

Seyed Razavi ([EMAIL PROTECTED]) wrote:
: Hi,

: Without sounding like treason can anyone provide any useful advice on how i
: can go about developing linux apps on a NT workstation?

Look on http://www.cygnus.com for CygWin

Treason's an offence; you just need help, advice and councelling <Big Grin>

G.
--
Gordon Scott             Opinions expressed are my own.
[EMAIL PROTECTED]   (official)     [EMAIL PROTECTED]  (backdoor)
[EMAIL PROTECTED]  (home)         http://www.apis.demon.co.uk
Linux  ...............   Because I like to _get_ there today.

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

From: Gerard van der Sel <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.development
Subject: Re: Linux Driver help needed (Polled interface)
Date: Fri, 26 Mar 1999 09:30:06 +0100
Reply-To: [EMAIL PROTECTED]

jharrell wrote:
>      >
>      > I am currently working on a device driver for a modem card
>      that has a
>      > "back door" to allow data to be passed through "attribute
>      memory" in a
>      > PCMCIA interface.  The problem is that no interrupt is
>      available to
<knip>
>      > periodically go and read from the attribute memory and
>      move the data to
>      > a circular buffer in user space?  Can I use jiffies or
>      wait queues or
>      > something along that lines to read the interface?   Any
>      help would be
>      > greatly
>      > appreciated.
>      >
>      > Thanks,
>      > Jeff Harrell
> 
>From user space you can use read (on /dev/rtc). It gives you a suspended
read for 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192 Hz.
(from 256 upward as root only). The rtc hardware in a PC is used to give
a X-tal stable interrupt (irq 8).

(the documentation of the rtc-chip mentions also the posibility for
16384 an 32764 Hz interrupt rate.)
-- 
Met vriendelijke groet,

Gerard van der Sel
Mailto:[EMAIL PROTECTED]
"De dinosaurussen hadden hun komeet, wij hebben de Windows computer" -
me

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

From: [EMAIL PROTECTED]
Subject: ISP Hookup, doesn't work ??
Date: Fri, 26 Mar 1999 01:50:53 -0800

I have installed Linux RedHat 5.2, and can't seem to get hookup to my
provider to work.
I think I have done all the correct thinks(read it in the HOW-TO file).
The modem dials the number, logs in, starts authentication and about 30
seconds later it disconnects.

Can anyone help me out ??

Thanks,

Arno (The Netherlands)



**** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ****

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

From: "Thierry BUCCO" <[EMAIL PROTECTED]>
Subject: scandir problem...
Date: Fri, 26 Mar 1999 09:46:02 +0100

Hi,

When i use scandir (like to the man scandir example), to list files into
directory the allocated memory is not liberated. How can i do that ?

free(namelist ?)

Thanks a lot.

Thierry - FRANCE

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

From: Karl Heyes <[EMAIL PROTECTED]>
Subject: Re: modprobe ERROR -- what's wrong???
Date: Fri, 26 Mar 1999 09:55:07 -0500



Dan wrote:

> I compiled and installed the latest version of iBCS on my 2.2.3 kernel (RH
> 5.2).
>
> When I run:  modprobe iBCS  -- I get the following error:
>    no dependency information for module: "/lib/modules/2.2.3/misc/iBCS"
>
> Does anyone know why this error occurs and what I can do to resolve it?
> Thanks.
>

depmod -a springs to mind


karl



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

From: "jacob" <[EMAIL PROTECTED]>
Subject: NT has IOCompletionPort()
Date: 26 Mar 1999 10:14:55 GMT

If  thread1 wants to signal thread2 with some data u can use iocompletion
ports in NT.
How would i convert this logic to Linux??

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

From: Mark Tranchant <[EMAIL PROTECTED]>
Subject: Re: Device Drivers - IOCTL
Date: Fri, 26 Mar 1999 11:24:21 +0000
Reply-To: [EMAIL PROTECTED]

jacob wrote:
> 
> ellis <[EMAIL PROTECTED]> schreef in artikel <7dbt87$j85$[EMAIL PROTECTED]>...
> > In article <7d2n0g$8ta$[EMAIL PROTECTED]>,
> >  <[EMAIL PROTECTED]> wrote:
> >
> > >I wrote an IOCTL to read PCI Configuration registers. I am using
> 'printk' to
> > >view what I have read. Can anyone please tell me, how to display the
> values
> > >read in the IOCTL, from a user program ? The value is an 'unsigned int'.
> >
> > I'm not sure what you're asking.  Do you mean you have to know how
> > to return the value?
> >
> no , he wants to know how u can do the same from user-space instead of
> kernel-space (moron)!
> 

Well, thanks for that helpful comment. A suggestion: write the value to
be read to a "file" in /proc?

Mark.

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

From: Existant <[EMAIL PROTECTED]>
Subject: Re: 256 threads limit on linux
Date: Fri, 26 Mar 1999 13:17:09 +0100
Reply-To: [EMAIL PROTECTED]

Peter Samuelson wrote:

> [Existant <[EMAIL PROTECTED]>]
> > For comparaison, under Solaris 2.5.1 the maximum number of processes
> > is a tunable parameters. On my system is set to 3994 (strange !!).
>
> Per user, or total?
>
> --
> Peter Samuelson
> <sampo.creighton.edu!psamuels>

  3994 it's the total. Per user, my system is configured at 3989. I think
that the difference is to prevent a overload system processes.

--
R. Manus


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

From: "Anders Östling" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: Fri, 26 Mar 1999 14:12:09 +0100
Reply-To: [EMAIL PROTECTED]

Mickey Lane wrote:

> Thomas Forlenza wrote:
> >NT was modeled after
> >UNIX and still is not as feature full.
>
> Minor nit. NT was modeled after VMS.
>
> I'm not 100% sure of the exact titles (project director,
> chief designer, etc.) but Dave Cutler was certainly a major
> player in first RSX, then VMS, then NT.
>

I remember when I bought the first NT book (5 years ago ?) written by
Helen <something>. Since I am an old VMS'er, I had dejavue's on every
single page of the book. The VM system, the IO system and most of the
kernel was not only modeled from VMS, the names and terms were exactly
the same... talk about reusing good concepts...but a shame that the
implementation
sucks ...

/Anders

>
> Mickey.

--
========================================================
Anders Östling
IKEA Corporate Technology Group
Email: anders dot ostling AT neurope dot ikea dot com
Phone: +46-42-25 73 45
Fax  : +46-42-25 73 70
Mobil: +46-70-753 70 39
========================================================




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

From: Emile van bergen <[EMAIL PROTECTED]>
Subject: Re: /dev/tun
Date: Fri, 26 Mar 1999 13:47:32 +0100

On 26 Mar 1999, Andreas Gustafsson wrote:

>Does Linux have anything similar to the /dev/tun driver in BSD-derived
>systems?  This is a pseudo-device for tunneling IP packets between the
>kernel and a user process.  On the kernel side, it behaves like a
>network interface and is recognized by ifconfig, netstat, etc.  A user
>process can access the packet queues of this network interface by
>opening a corresponding character device /dev/tun0 and reading and
>writing IP packets using read(2) and write(2).

The semantics look like those provided bu mod_ppp, only without the
ppp-encapsulation. This would really be nice for diald, for example; it
currently works with ppp on a pty, with the slave opened by diald which
parses the packets. This rather ugly type of thing would definitely be
helped by /dev/tun; you get rid of the ppp overhead. Maybe you should
look into it? (I mean  /usr/src/linux ;-).


-- 

M.vr.gr. / Best regards,

Emile van Bergen (e-mail address: [EMAIL PROTECTED])

This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.


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

From: Bernd Strieder <[EMAIL PROTECTED]>
Subject: Re: Compiling 2.2.4, error in kernel/acct.c
Date: Fri, 26 Mar 1999 14:08:36 +0100

Hi,

I wrote:
> My Linux is SuSE 6.0, unmodified, Kernel 2.2.2 running for some weeks
> without
> problems.
> =

> I=B4ll give a try without system accounting activated, hope it works th=
en.

With BSD process accounting deactivated, the kernel compiles fine and
works without patches. Sound, printing, ethernet, X11, all ok.

I don=B4t know programs to try out this BSD process accounting, so I got
it out.
I got it in at first because it was declared to be a good idea in
general in the help text of this option.

Bye,
 =

Bernd

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

Date: Fri, 26 Mar 1999 08:12:32 -0000
From: [EMAIL PROTECTED] (Robert Kaiser)
Subject: Re: DMA cache cohrency?

In article <[EMAIL PROTECTED]>,
        hyosang lim <[EMAIL PROTECTED]> writes:
> Pat Crean wrote:
>> 
>> You shouldn't have to worry about it.  If the cache subsystem is properly
>> designed, the hardware will snoop the system bus during dma and invalidate
>> the cache as required.
>> 
> The data read from RAM (computer B) was incorrect.
> I think it is cache coherency problem.
> In VxWorks (RealTimeOS), cacheFlush() and cacheInvalidate() system calls
> are used
> to sync cache and memory.
> Is there any functions to control cache in Linux?
> 

Is this an x86 System ? If so, you really shouldn't have to worry
about cache coherency unless your cache hardware is somewhat broken.

However, if you are talking about a 68K or PowerPC system, now that's
different! For these Processors, you need to use functions similar
to the cacheFlush()/cacheInvalidate() in VxWorks. I don't know the
names of the appropriate functions in Linux but I'm pretty sure they
are there. A little use of grep and find on the m68k Linux source
tree reveals, for instance, functions called cache_clear() and
cache_push() in file arch/m68k/mm/memory.c which look like they
would probably do what you want for a 68K-based system.

If I were you, I'd take a close look at some driver running on your
platform that you know uses DMA and see how they do it. Shouldn't
be too hard to find.

Hope this helps

Rob

============================================================
Robert Kaiser                        rkaiser AT sysgo DOT de
Sysgo RTS GmbH
Mainz/Germany


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

From: Roope Anttinen <[EMAIL PROTECTED]>
Subject: Re: Intel i/o chip has bug? ( lpt )
Date: 26 Mar 1999 13:45:22 GMT
Reply-To: [EMAIL PROTECTED]

jacob <[EMAIL PROTECTED]> wrote:
> I think it means that your parallel port is not "enhanced" EPP= Enhanced
> Parallel Port.
> This means a greater throughput speed then normal. donno if intel is
> facking an EPP though.

I have Intel 440FX mainboard and the i/o chip is defective in it. It appears
to work most of the time but no way you could us it with paride drivers. I
tried HP's external CD-RW drive with two quite similiar PPro machines. One
with Intel motherboard and one with Compaqs. The compaq one worked and with
exactly same setup Intel board didn't.

Roope

-- 
MicroSoft? is that some kind of a toilet paper?
PS: Look for address here, not from headers. And remove NOSPAM's
___________________________________________________________________________
   [EMAIL PROTECTED]  /  [EMAIL PROTECTED]
        +358 9 812 7567  /  +358 500 445 565  /  +358 49 445 565
                http://myy.helia.fi/~anttiner/index.html
===========================================================================
   Helsinki Business Polytechnic - Institute of information technology

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

From: [EMAIL PROTECTED] (Peter)
Crossposted-To: comp.arch.embedded
Subject: Re: RS485 & Linux: Must toggle DTR quickly
Date: Fri, 26 Mar 1999 13:06:09 GMT

They do give the "all sent" info but only as a status bit - you cannot
program an interrupt from it.

>  The main problem here is hardware: none of the 16450, 16550 and
> other UART give the information "char completely sent", they just
> give the information "Tx serialisator empty"...


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to [EMAIL PROTECTED] but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.

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

From: Kalle Olavi Niemitalo <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.bsd.freebsd.misc,comp.unix.programmer
Subject: Re: Where can I find the ELF format specification.
Date: 26 Mar 1999 15:23:23 +0200

Here's something about ELF, I don't know how complete it is:
http://www.sco.com/developer/gabi/contents.html

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

From: "Dan" <[EMAIL PROTECTED]>
Subject: Re: modprobe ERROR -- what's wrong???
Date: Fri, 26 Mar 1999 16:05:56 GMT

That was it.  Thanks!

DR

Karl Heyes wrote in message <[EMAIL PROTECTED]>...
>
>
>Dan wrote:
>
>> I compiled and installed the latest version of iBCS on my 2.2.3 kernel
(RH
>> 5.2).
>>
>> When I run:  modprobe iBCS  -- I get the following error:
>>    no dependency information for module: "/lib/modules/2.2.3/misc/iBCS"
>>
>> Does anyone know why this error occurs and what I can do to resolve it?
>> Thanks.
>>
>
>depmod -a springs to mind
>
>
>karl
>
>



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

From: [EMAIL PROTECTED] (Erwin S. Andreasen)
Subject: Re: Debugging terrible stack corruption problems - tips or tools?
Date: 26 Mar 1999 16:04:04 GMT
Reply-To: [EMAIL PROTECTED]

On 26 Mar 1999 00:49:26 -0500, Justin Vallon wrote:

>> I have a problem where function parameters become inaccessible part way
>> through a function, as a result of stack corruption - caused by something
>> the function has done. I get a segmentation fault when I access them.
>> 
>> Unfortunately I can not reproduce the problem under Windows, or I would use
>> Purify to try to find the source of the problem.
>
>Some tips:

In addition - although obvious - turn all optimization off.

If you are using C++, use -fno-inline so you are sure nothing gets inlined.

If this is a problem with sprintf(), consider defining a macro that copies
e.g. __LINE__ into a global variable then goes ahead with the sprintf (gcc
allows for macros with variable arguments).


There is also some patch to the gcc compiler called StackGuard (?) which
lays out the stack in a special way so buffer overflows are hard to exploits
for would-be crackers. Perhaps (but I don't know for sure) it also has some
mode that could check if the stack has been overflowed.

Also what might be helpful is examining the registers (info registers) and
looking for unusual values.

Especially if the stack pointer or the instruction counter seems to
have an address that consists of ascii letters - do a p /c 0x42 etc. on
each of the bytes in the address. Perhaps you'll be able to see the
piece of memory that overflowed it.


One exampe of stack overflow which is almost invisible until too late is
something like this:

char buf[SOME_VALUE];

memcpy(buf, some_data, SOME_VALUE);
buf[SOME_VALUE] = '\0';

If the bug is in the right places, this changes the return address slightly,
so you return to the middle of a function. It may not crash right away
and when it does, you're left wondering.



-- 
==============================================================================
Erwin Andreasen   Herlev, Denmark <[EMAIL PROTECTED]>          UNIX System Programmer
<URL:http://www.andreasen.org>              <*>         (not speaking for) DDE
==============================================================================

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


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