Linux-Development-Sys Digest #967, Volume #7 Thu, 22 Jun 00 05:13:10 EDT
Contents:
Re: UDI (Warren Young)
error number ([EMAIL PROTECTED])
Re: read(2) error EINTR (Warren Young)
Re: UNIX upgrading (Christopher Browne)
Re: read(2) error EINTR ("Paul D. Smith")
Re: read(2) error EINTR ([EMAIL PROTECTED])
Re: read(2) error EINTR ("Paul D. Smith")
Re: ODBC or Access binaries (Sam Birch)
USB Support ("David Findlay")
Re: Driver devel (interruptible_sleep_on_timeout) (Peter Pointner)
Re: can I not get the value of a global variable in an interrupt handler? (Peter
Pointner)
Re: QUERY: swap to/from a char device? (H. Peter Anvin)
Re: Add 4inches in length to your penis now!!! 4950 (Lew Pitcher)
Re: Add 4inches in length to your penis now!!! 4950 (Kaz Kylheku)
What is a single address space & multi address space? ([EMAIL PROTECTED])
Re: USB Support (Markus Kossmann)
----------------------------------------------------------------------------
Date: Wed, 21 Jun 2000 17:01:46 -0600
From: Warren Young <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: Re: UDI
Gundu wrote:
>
> Wanted to know if linux has a implemented Uniform driver Interface, If
> so,
> how can i use UDI for a IBM token ring NIC.
There's work under way to port the UDI reference implementation to
Linux, but I gather that it isn't finished yet.
Most likely, when it _is_ finished, you will have to patch the UDI
functionality in yourself, like pcmcia-cs worked for the past few years.
--
= Warren -- ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
------------------------------
From: [EMAIL PROTECTED]
Subject: error number
Date: Wed, 21 Jun 2000 22:57:28 GMT
Hi,
Does a kernel api (like kmalloc) on failure set the appropriate error
code (in errno global variable).
thanks in advance.
regards
jeseem
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 21 Jun 2000 17:12:17 -0600
From: Warren Young <[EMAIL PROTECTED]>
Subject: Re: read(2) error EINTR
Alex Hooker wrote:
>
> I am just doing some testing on linux system calls,
> and I just can't seem to get read to generate the
> EINTR error. Ideally, on a blocking empty pipe read,
> you would get this error - fork() child blocks on the
> read and the parent sends constant EINTR signals via
> kill(). But the child does not terminate. I am using
> signal() to catch...
Are you confusing SIGINT with EINTR? They're not even vaguely related.
SIGINT is not a particularly special signal: it doesn't do anything more
to a process than, say, SIGWINCH does. (Except that the default SIGINT
handler kills the process which doesn't happen with SIGWINCH.) Contrast
this with signals like SIGKILL and SIGSTOP, which affect the process
without even entering the Standard C library code. There is no way to
change the behavior of that type of signal.
EINTR happens when something happens deep in the bowels of the kernel
that forces it to stop blocking on a system call. Some signals on some
OSes are known to cause this, but it's not specified to work by any
standard I know of. All EINTR says is, you need to make the system call
again. It doesn't say why, or even whether another call will succeed.
If you need to stop a process from blocking on a read, you should look
at another design. One would be to use nonblocking sockets with
select(). Create a pipe for the signal handler to communicate with the
rest of the program, and select() that pipe in along with the FD you
want to block on. When the signal handler catches SIGINT, send a byte
of data on the signal pipe. The select() call will unblock, and you can
detect that it's the signal pipe and not the data pipe that unblocked
select().
Another possibility is to get the process on the other end of the pipe
that the first one is blocked on to close the pipe. The blocking read()
will return 0, meaning that the pipe is now closed.
--
= Warren Young, maintainer of the Winsock Programmer's FAQ at:
= http://www.cyberport.com/~tangent/programming/winsock/
=
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: UNIX upgrading
Reply-To: [EMAIL PROTECTED]
Date: Wed, 21 Jun 2000 23:59:36 GMT
Centuries ago, Nostradamus foresaw a time when Waldek Hebisch would say:
>[EMAIL PROTECTED] wrote:
>: Hey all,
>: I'm new to the Linux world, so this might be a very naive question.
>: But here we go....
>: After suffering through the wasteland of DOS/Windows for a long time,
>: how often will it be necessary to upgrade my Redhat Linux? In other
>: words, if I still had Windows 3.1 on my system, I would be out of luck as
>: far as new software is concerned. Yet if I keep RH 6.1 on my system for a
>: while, will it always be able to run newer software with its regular
>: kernal? As far as older kernals, are they still viable for running new
>: software? Thanks for your help!
>
>I think that you are expecting too much. You are talking about 8 years
>timescale. In last 8 years Linux went to two big shocks:
>- change from a.out to ELF binary format
>- change from libc5 to glibc
>In both cases the old systems were unable to run new binaries. There
>were also smaller changes which could force you to upgrade large
>part of the system to get new functionality.
Unfortunately, some "aggressive early adoption of GLIBC2.0" resulted
in a few problems when the "production" release, GLIBC 2.1, came out,
which broke some programs that were coded specifically to 2.0.
>Looking forward into next 8 years I see at least two big reasons
>for new shocks:
>- 64bit computing
>- wide adoption of Unicode (UTF-8)
>I HOPE that in 8 years dominant platform will be 64-bit, and of
>course binaries for such a platform will not run on 32-bit
>processors. And since currently there is no good alternative
>to Intel archtecture we will see in next few years a bunch of
>ougly patches to cope with bigger memories and drives. Those
>changes are likly to make some programs incompatible with
>old systems.
Resolution of many of the issues involved with this are already well
under way, since there are several 64 bit platforms already in use
(notably Alpha, PPC, SPARC).
IA-32 binaries certainly won't work on these systems, but there are an
increasing population of programs where compatibility is merely a
"make clean; make all" away. (Evidenced by the available of
distributions for these platforms from Debian, Mandrake, SuSE, and
RHAT that _do_ use the same sources...)
I rather think that the transitions relating to:
a) Deployment of XFree86 4.0, and
b) The "versionitis" associated with GNOME/GTK and KDE/Qt
will represent _bigger_ issues for those wishing to deploy code than
that of platform portability.
>For Unicode -- to get full benefits the whole system should
>work with Unicode, and while most programs should work just fine,
>I may be much simpler to upgrade the whole system then to try
>isolate guilty parts.
I'm not sure at all what will happen with Unicode.
<http://www.cl.cam.ac.uk/~mgk25/unicode.html> outlines some tools and
issues; I just don't know where it will be going...
>To put things into perspective:
>- if you install from sources you should be able to substantially
> extend life of your system
Yes, indeed.
If software comes in in the form of sources, whether as a TARBALL, a
Source RPM, or a Source .DEB, then this increases the likelihood of it
surviving system changes. If there is the ability to recompile it,
that can overcome a multitude of evils. If there is _no_ ability to
recompile it, evil will overcome.
--
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>
Q: What does the function NULL do?
A: The function NULL tests whether or not its argument is NIL or not. If
its argument is NIL the value of NULL is NIL.
-- Ken Tracton, Programmer's Guide to Lisp, page 73.
------------------------------
From: "Paul D. Smith" <[EMAIL PROTECTED]>
Subject: Re: read(2) error EINTR
Date: 21 Jun 2000 23:00:41 -0400
Reply-To: [EMAIL PROTECTED]
%% Warren Young <[EMAIL PROTECTED]> writes:
wy> EINTR happens when something happens deep in the bowels of the
wy> kernel that forces it to stop blocking on a system call. Some
wy> signals on some OSes are known to cause this, but it's not
wy> specified to work by any standard I know of.
Every standard provides for the possibility that read doesn't restart.
Non-restarting reads are either the default behavior or are
easily-obtainable in every OS I've worked with.
SingleUNIX requires the SA_RESTART flag on sigaction, and says that if
it's not set, interruptible system calls will fail with EINTR... and by
their definition read(2) _is_ interruptible. So, SingleUNIX at least
requires that non-restarting read(2) be available, and I would argue
that, by virtue of the fact that if you don't set the SA_RESTART flag
you get non-restart behavior, non-restart is the default behavior.
All major UNIX versions I'm familiar with (about all except the
{Open,Net,Free}BSD versions) work this way now.
wy> If you need to stop a process from blocking on a read, you should
wy> look at another design. One would be to use nonblocking sockets
wy> with select(). Create a pipe for the signal handler to
wy> communicate with the rest of the program, and select() that pipe
wy> in along with the FD you want to block on. When the signal
wy> handler catches SIGINT, send a byte of data on the signal pipe.
wy> The select() call will unblock, and you can detect that it's the
wy> signal pipe and not the data pipe that unblocked select().
I thought of that in my case. The reason we didn't use it escapes me
right now, though; I'd have to look back through the email discussions
and see if I can find this; there may have been a race condition that
was difficult to overcome.
At the very least it's much more complex, and the fact is that every
UNIX system I've seen supports non-restartable system calls, if you ask
for them. Even SunOS 4.1.x supports them (you have to specify the
non-standard SA_INTERRUPT flag to sigaction() there, IIRC).
wy> Another possibility is to get the process on the other end of the
wy> pipe that the first one is blocked on to close the pipe. The
wy> blocking read() will return 0, meaning that the pipe is now
wy> closed.
This won't work if you need the pipe! :)
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: read(2) error EINTR
Date: Thu, 22 Jun 2000 03:14:24 GMT
Paul D. Smith <[EMAIL PROTECTED]> wrote:
> Every standard provides for the possibility that read doesn't restart.
> Non-restarting reads are either the default behavior or are
> easily-obtainable in every OS I've worked with.
Well, I recieved a thank you note this evening which indicated that
the reads are restarted when signal() is used, but not when
sigaction() is used. Thus, there are two defaults in Linux. The bottom
line is that you can't depend on signal() to specify the reliability
of signals, or the behavior of interupted system calls.
> At the very least it's much more complex, and the fact is that every
> UNIX system I've seen supports non-restartable system calls, if you ask
> for them. Even SunOS 4.1.x supports them (you have to specify the
> non-standard SA_INTERRUPT flag to sigaction() there, IIRC).
The SunOS thing is annoying. However, Linux, *BSD, and possibly others
default to restarting system calls if you use signal() rather than
sigaction(). I think the confusion about my statement of system calls
being restarted by default on most modern implementation is that I was
refering only to signal() and not sigaction().
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: "Paul D. Smith" <[EMAIL PROTECTED]>
Subject: Re: read(2) error EINTR
Date: 21 Jun 2000 23:37:26 -0400
Reply-To: [EMAIL PROTECTED]
%% [EMAIL PROTECTED] writes:
e> The bottom line is that you can't depend on signal() to specify the
e> reliability of signals, or the behavior of interupted system calls.
No argument there.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: Sam Birch <[EMAIL PROTECTED]>
Subject: Re: ODBC or Access binaries
Reply-To: [EMAIL PROTECTED]
Date: Thu, 22 Jun 2000 03:55:43 GMT
Locally or from a Windoze machine? I don't know how to do it locally
from a linux box, but there are a few ways to access the data if you
are willing to make some changes:
1) ODBCSocketServer (look for it on freshmeat.net)
2) Upscale to SQL Server (expensive)
3) Upscale to Postgres/MySQL (connect to it through ODBC if you still
need to hit this db from a Windoze box.
No solution is ideal (unless someone can point out how to access an
mdb on a linux box...), but the answer depends on how you plan to use
this: one-time shot, frequently, all the time...
HTH
Sam
On Wed, 21 Jun 2000 02:07:07 GMT, "Richard (Klendathu)"
<[EMAIL PROTECTED]> wrote:
> Has anyone dabbled in ODBC? I'm interested in being able to grab Microsoft
>Access .mdb files and either tear the information out or be able to
>interface them (preferred). Thanks a bunch.
> Please email me since I may not get back to check the newsgroup too soon.
>Thanks.
>
>Richard
>Studio B Software Engineering
>"alternative system development"
>
------------------------------
Reply-To: "David Findlay" <[EMAIL PROTECTED]>
From: "David Findlay" <[EMAIL PROTECTED]>
Subject: USB Support
Date: Thu, 22 Jun 2000 14:43:18 +1000
Does Linux have USB support? How do you write software to work with the USB
port?
David Findlay
------------------------------
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: Driver devel (interruptible_sleep_on_timeout)
Date: 22 Jun 2000 06:29:33 +0200
Espen Sand <[EMAIL PROTECTED]> wrote:
> Hi all,
> I am in the process of moving some driver code from
> a 2.0.x system to 2.2x. The driver reads data from external
> HW which sends an interrupt each time it has prepared some.
> If there is no data pending when I want to read,
> I do an interruptible sleep for a second. Normally new
> data will arrive long before the second has elapsed.
> How should this be done in 2.2x? Is the
> interruptible_sleep_on_timeout() the preferred method? To
> me it seems so, but how should I detect that a timeout has
> occurred or not? (the complier is not happy about the
> "current->signal & ~current->blocked" test below)
If you look at some drivers in the standard kernel, you will see
that (current->signal & ~current->blocked) is replaced by
signal_pending(current)
> Here is how I did it in 2.0.x
> /* wait for resonse */
> current->timeout = jiffies + i960.readTimeout;
> interruptible_sleep_on( &i960.waitQueue );
> current->timeout = 0;
> sti();
> if( current->signal & ~current->blocked )
> {
> /* New data has arrived */
> ...
> }
> /* The interrupt function */
> static void i960_interrupt( int irq, void *dev_id,
> struct pt_regs *regs )
> {
> ....
> wake_up_interruptible( &i960.waitQueue );
> ....
> }
Are you really sure that you are doing it this way? Why should
a pending signal mean that there is new data?
Peter
------------------------------
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: can I not get the value of a global variable in an interrupt handler?
Date: 22 Jun 2000 06:35:58 +0200
Bangnan Xu <[EMAIL PROTECTED]> wrote:
> Dear all,
> to test the interupt i need to have a initialized variable used in a
> interrupt
> routing in linux kernel. But strange things have happen when i try to
> do so.
Try to replace
unsigned int interruptvariable=5;
by
volatile unsigned int interruptvariable = 5;
>From the code you posted I can't see a problem not using volatile,
but your real code probably does more.
Peter
------------------------------
From: H. Peter Anvin <[EMAIL PROTECTED]>
Subject: Re: QUERY: swap to/from a char device?
Date: 21 Jun 2000 21:51:53 -0700
Followup to: <[EMAIL PROTECTED]>
By author: Tom Roberts <[EMAIL PROTECTED]>
In newsgroup: comp.os.linux.development.system
>
> The Linux kernel can swap to/from both a block device (the usual
> case such as a disk partition) and a file. Can this file be a char
> device?
>
No.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
------------------------------
From: Lew Pitcher <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Add 4inches in length to your penis now!!! 4950
Date: Wed, 21 Jun 2000 18:21:40 -0400
Larry Ebbitt wrote:
>
> On Sun, 18 Jun 2000 09:47:41 -0400, Lew Pitcher wrote:
NO, I DID NOT!!!
Get your attributions right. I _replied_ to the OP who said...
> >> you to can have the huge dick of your dreams!!!
>
> Will I have to take time away from my PC?
>
> Larry - Atlanta - IBM Global Services
--
Lew Pitcher
Master Codewright and JOAT-in-training
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Add 4inches in length to your penis now!!! 4950
Reply-To: [EMAIL PROTECTED]
Date: Thu, 22 Jun 2000 06:45:34 GMT
On Wed, 21 Jun 2000 18:21:40 -0400, Lew Pitcher <[EMAIL PROTECTED]> wrote:
>Larry Ebbitt wrote:
>>
>> On Sun, 18 Jun 2000 09:47:41 -0400, Lew Pitcher wrote:
>
>NO, I DID NOT!!!
>
>Get your attributions right. I _replied_ to the OP who said...
Give the guy a break, he's using some freaking OS/2 newsreader. :)
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED]
Subject: What is a single address space & multi address space?
Date: Thu, 22 Jun 2000 08:00:56 GMT
I have no idea about the single address space.. and multi address
space..
these terms are uttered frequently ..
What are these.. ? and What's the difference between single and multi
address space...
Please let me know these..
thank you for answering beforehand. ..
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Markus Kossmann <[EMAIL PROTECTED]>
Subject: Re: USB Support
Date: Thu, 22 Jun 2000 08:22:42 +0200
David Findlay wrote:
>
> Does Linux have USB support?
Have a look at http://www.linux-usb.org/
--
Markus Kossmann
[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 (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
******************************
