Linux-Development-Sys Digest #180, Volume #8 Fri, 29 Sep 00 03:13:13 EDT
Contents:
Re: new windowing system (Drazen Kacar)
Re: tar & other systems (Juergen Heinzl)
Re: Java on Linux? (Jerry L Kreps)
disabling update of last-access and modification timestamps on files (Benjamin Rutt)
problem with ftp ("jhuman")
Re: disabling update of last-access and modification timestamps on files (Bob Hauck)
Re: RTLinux + SMP? ([EMAIL PROTECTED])
Re: vm86 system call (Tim Roberts)
Re: insmod with new kernel: unresolved symbols (Moya)
Re: smp scheduling ("D. Stimits")
Re: Linux Stack Sizes? (0/1) (MeekGeek)
Re: Linux Stack Sizes? (0/1) (MeekGeek)
Re: Linux Stack Sizes? (0/1) (MeekGeek)
Re: Linux Stack Sizes? (0/1) (MeekGeek)
Re: Interpreterexecutionbug (Lew Pitcher)
Re: smp scheduling (Mathias Waack)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Drazen Kacar)
Crossposted-To: comp.os.linux.x,comp.windows.x
Subject: Re: new windowing system
Date: 28 Sep 2000 20:35:07 GMT
Alexander Viro wrote:
> In article <[EMAIL PROTECTED]>,
> Drazen Kacar <[EMAIL PROTECTED]> wrote:
> >I'm not familiar with CORBA, so I might be wrong here. However, I believe
> >ORBit doesn't do it the way you described. I'm not sure what exactly
> >takes place in encode/decode phase, but if it's only endianess, then
>
> It's certainly _not_ only endianness.
OK, what else? There is an issue with padding in structures. But, as far
as I can see, you can have architecture where the client sends
whatever its C ABI mandates and server decodes and encodes if that's
different form its C ABI. You don't have to have encoding and decoding
in both client and server.
> >So it's the same, except for read/write vs. sendmsg/recvmsg. In case of
> >local client and server, that's the same, too.
>
> Yes, except that for client most of the crap goes away. For one thing, you
> can use several files, essentially encoding the request into the choice of
> file you are accessing. For another, you don't have to deal with RPC
> scheduling on the client side, yodda, yodda.
That's nice. Having it in the file system, I mean. But, what if it turns
out that the whole system is not good (for whatever reason) and the
new one emerges? Then you have to maintain the old one in the kernel,
because your users will probably want to have binary compatibility.
And that way lies kernel bloat, which is not something I like.
If something can be done in userland, then do it there. If it's inefficient,
then some kernel support is OK. However, I'd first like to see some
hard numbers, before saying that kernel support is needed.
> >> Damnit, the whole UNIX toolchain was designed to work with file API. Deal
> >> with it.
> >
> >Which is not necessarily the best API in all circumstances. Now, Plan 9
> >with its "everything uses UTF-8" is better than the Unix and its
> >"everything uses ASCII and if you need something else, we have these
> >fine kludges to offer."
>
> Huh? UTF-8 vs. ASCII is completely irrelevant here - neither UNIX nor Plan 9
> care about it anywhere near the code paths involved. And "ASCII" is not
> accurate - it's 7-bit and UNIX API is 8bit-clean.
Depends on what we mean by 8bit-clean. The whole point of API is to
have some applications do useful things with it. So, open() some
file on Unix and read() it. Then tell me if it uses Latin 1 or Latin 2.
Actually, tell that to your window system, because the application
needs to write the text from the file on the screen. With the correct
font, needless to say.
> BTW, you do realize that
> Plan 9 uses the aforementioned architecture for _all_ RPC-like stuff? Yup,
> including the window system, DNS, etc.
Yep, and that's nice. You have some performance penalty when compared
to using 8-bit charset, but you don't have to be in pain when you need
to do something outside of ASCII range.
> >That doesn't work well always. If you're reading from a slow NFS mount,
> >your GUI application might be very unresponsive, unless you write
> >the code which deals with NFS effects. The API is the same, read()
> >will return your data eventually, but "eventually" means very different
> >things for local file access and NFS access.
>
> Who said "NFS"?
I did, because it's perfect example of thing which uses Unix API, but has
to deal with remote servers, which might not be speedy when answering.
You'd have the same problem with CORBA and remote servers.
--
.-. .-. I don't work for my employer.
(_ \ / _)
| [EMAIL PROTECTED]
| [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: tar & other systems
Date: 28 Sep 2000 20:56:17 GMT
In article <8r001t$qsu$[EMAIL PROTECTED]>, Apple wrote:
>I want to read an exabyte from a scsi 's tape what was written with
>Sun-Solaris 7 's tar command.
>When I do tar tvf /dev/st0 I have an I/O error .
>I try to put blocking factor like tar tvfb /dev/st0 20 but it is same I/O
>error
>What can I do.
[-]
I've never tried an Exabyte tape so take this with two grains of
salt, but what's the block size ? I don't mean the blocking factor,
but see mt ( setblk ) as it can be changed and for instance I used
to write to an HP drive using 1k blocks instead of the default 0.5k
block size.
Cheers,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: Jerry L Kreps <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: Java on Linux?
Date: Thu, 28 Sep 2000 17:55:56 -0500
On IBM Linux developer website they offer (or use to) VisualAge for Java 3.0.
It is a full GUI RAD java develolper app. Very good!
JLK
On Wed, 27 Sep 2000, Bob Tennent wrote:
>On Wed, 27 Sep 2000 22:15:24 GMT, Exits Funnel wrote:
> >
> >I'm a java developer new to linux (or any unix for that matter). I'm
> >wondering what java compilers/tools most linux developers favor. I know
> >Sun's JDK is available on linux but am wondering what alternatives there
> >are. Does GNU have a Java offering?
>
>Being worked on at Cygnus I believe. IBM's Jikes is really fast as
>a "compiler" (i.e., to byte code) and it produces good error messages.
>Kaffe is a good and fast-byte code interpreter.
>
>Bob T.
------------------------------
From: Benjamin Rutt <[EMAIL PROTECTED]>
Subject: disabling update of last-access and modification timestamps on files
Date: 28 Sep 2000 17:09:35 -0600
I was wondering whether there is a way on a linux, or unix system in
general, to disable updates of the last-access and modification
timestamps on a few select files that we are updating frequently. Our
motivation is squeezing out some extra performance. Any ideas?
Benjamin
------------------------------
From: "jhuman" <[EMAIL PROTECTED]>
Crossposted-To: alt.linux,comp.os.linux.setup,linux.redhat.install,linux.redhat.misc
Subject: problem with ftp
Date: Thu, 28 Sep 2000 19:14:53 -0400
I get this error when trying to ftp to one of my linux boxes on private
lan....
421 Service not available, remote server has closed connection
What does this mean and how do I fix it....
thx in advance
--
JD Durick
[EMAIL PROTECTED]
AT&T Laboratories, ISC
Washington, DC
------------------------------
From: [EMAIL PROTECTED] (Bob Hauck)
Subject: Re: disabling update of last-access and modification timestamps on files
Reply-To: bobh{at}haucks{dot}org
Date: Thu, 28 Sep 2000 23:05:05 GMT
On 28 Sep 2000 17:09:35 -0600, Benjamin Rutt <[EMAIL PROTECTED]>
wrote:
>I was wondering whether there is a way on a linux, or unix system in
>general, to disable updates of the last-access and modification
>timestamps on a few select files that we are updating frequently.
The "noatime" option to mount can do this on a per-filesystem basis. I
don't know of any finer-grained method.
--
-| Bob Hauck
-| To Whom You Are Speaking
-| http://www.haucks.org/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RTLinux + SMP?
Date: Fri, 29 Sep 2000 01:49:56 GMT
there is a way, if you are using the scheduler that comes along with
rtlinux. you can create two threads in your module and assign them to
different cpus, then they will be executed on two cpus concurrently.
the primitives you need are pthread_create, and pthread_attr_setcpu_np
the linux kernel now allows more than one cpu to be in the kernel at the
same time. and as far as i know, rtlinux doesnt do anything to change
that. in fact, if it does, then i would be very interested to know...
-nikhil
===================================================
I want to experiment with Real Time Linux on an mutli-processor box.
Say I have two real time
processes that need to run at high priority, loaded as modules for
RTLinux. Will they ever get
scheduled to run at the same time on both processors? Or is there a
single kernel-semaphore that
will prevent this?
Best Regards
Jeff Koftinoff
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Roberts <[EMAIL PROTECTED]>
Subject: Re: vm86 system call
Date: Thu, 28 Sep 2000 19:36:30 -0700
"andrew.betts" <[EMAIL PROTECTED]> wrote:
>
>Can someone explain to me how to execute a code snippet with the vm86 system
>call.
It's complicated.... There is a package called "lrmi" (Linux real-mode
interface) that gives some good examples of calling in to the VESA BIOS.
You might search the web for it; it isn't stored where I originally found
it. If you have the XFree86 3.3.6 source code, the Savage server includes
it.
>void somecode() {
> __asm__(
> "mov %%ax,%%bx" // or something
> )
>}
>
>void go()
>{
> struct vm86plus_struct vm86s;
> vm86s.regs.eip=(void*)somecode; ?????
> vm86(VM86_ENTER,&vm86s);
>}
This is NOT the way. Remember that V86 mode is NOT 32-bit and is NOT
protect mode. It is the old 16:16 segmented memory model. Any code you
compile with gcc is going to be 32-bit protect mode. The opcodes will be
wrong.
vm86 is primarily useful for two things: executing old DOS .COM and .EXE
files, with an appropriate loader, and executing code in the ROM BIOSes.
The values you pass to vm86 in the segment registers must be segment
offsets. This means all code and data must be located in the low megabyte
of real memory. This requires magic on the part of the application.
>I have tried filling the other segment registers with __USER_DS/CS but all
>_appears_ to fail.
Yep. You need to put 16:16 segments in there. To execute the VESA BIOS at
linear 000c0000, you'd set CS to C000 and IP to 0.
>And how do return from "somecode" to the line after the syscall?
Do something that causes a trap. You could insert an illegal instruction,
or an int 3, for example. That causes vm86 to return control to you to
handle the trap.
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
------------------------------
From: Moya <[EMAIL PROTECTED]>
Subject: Re: insmod with new kernel: unresolved symbols
Date: 29 Sep 2000 03:57:31 GMT
Thomas Berkefeld <[EMAIL PROTECTED]> wrote:
> Hello,
> after updating the kernel from 2.2.14 to 2.2.17pre15, a module that has been
> compiled afterwards cannot be loaded. insmod says "unresolved symbol"
> for all symbols. Any ideas?
Have u resolved this problem??
Would you please tell me how to fix it finally?
Thanks...
------------------------------
Date: Thu, 28 Sep 2000 22:09:45 -0600
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: smp scheduling
[EMAIL PROTECTED] wrote:
>
> hi,
>
> i have a question about smp scheduling under linux. when i insert a
> module, will the entire init_module function execute on one cpu, or can
> the scheduler step in and switch cpus mid-way? i am disabling interrupts
> during the entire function, and the function does not sleep anytime.
>
> also, if the scheduler can change cpus, is there anyway i can disable
> the other cpus until the function exits.
>
> i am running a dual-cpu with pentium-133s on kernel 2.2.13
> any suggestions are welcome,
> -njm
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
This isn't an answer, but might provide something useful (hopefully).
Check out the kernel source document:
/usr/src/linux/Documentation/spinlocks.txt
------------------------------
From: MeekGeek <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: Fri, 29 Sep 2000 06:11:41 GMT
On 26 Sep 2000 14:08:51 +0000, David Wragg <[EMAIL PROTECTED]> wrote:
>"Paul D. Smith" <[EMAIL PROTECTED]> writes:
>> This is not a problem with the maximum size of the stack.
>
>Indeed.
>
>> First, you are assuming that the stack lives in high memory and grows
>> towards low memory. You cannot assume that. There is absolutely no
>> reason the stack couldn't live in low memory, and grow upwards. Many
>> implementations of UNIX and other OSs do exactly this.
>
>If he's writing (or porting or maintaining) a threading package I
>expect he knows about the system dependent aspects involved, such as
>which way the stack grows. Since he said he is porting code that
>works on Solaris and NT, I think we can assume he is concentrating on
>x86.
Yes, sort of. The Solaris/Sparc version is already working fine,
along with the Windows/Intel version. I was only having this SEGV
problem with Linux/Intel.
>> Second, you are assuming that any memory below your stack can
>> arbitrarily be written on. That's totally broken. The stack could
>> well be allocated only as needed by function calls, and memory beyond
>> what's been used is simply not available (hence traps if you try to
>> access it).
>
>This is what's causing the problem. Stack pages are only allocated as
>needed, though not explicitly by function calls.
This is what I was expecting, but did NOT get (see below).
>The kernel adds pages to the stack segment of a process on demand,
>growing it downwards (on x86) in response to page faults. But how can
>it tell if a memory access resulting in a page fault refers to the
>stack segment? It can't, so it guesses: If the faulting address is
>below the bottom of the stack segment, and is above the stack pointer
>or slightly below it, then the stack segment should be grown.
>"Slightly below" here means "no more than 32 bytes below".
The key here is that you must keep the stack pointer below the stack
memory references, something slightly different than under NT, and
something I didn't expect (and you didn't either, below).
>So when the OP's program runs off the bottom of the stack segment, the
>kernel probably won't know that the memory accesses relate to the
>stack segment and so sends a segfault.
>
>Try running so it touches memory with a stride of 32 bytes, and it
>should merrily grow the stack segment until it hits the stack resource
>limit.
This is in fact what I tried. I was hoping for the equivalent of an
NT "guard page", which this method would have worked for. (Although
in the NT case, the stride could be as large as 4K.) I tried touching
memory with a stride as small as 8 byte decrements. That didn't help,
it wasn't the size of the stride. It was the total sum of the
strides. It was no good to touch the memory, if I didn't also keep
the stack pointer below the addresses in question.
>> [snip]
>>
>> If you _must_ have it in the stack, you're going to have to actually
>> _allocate_ that much stack! You can't simply use it without previously
>> telling the compiler and/or runtime system you will need it.
Yes, you can. You don't have to call alloca() to make a function
call. You can just use PUSH. The difference is that in the case of
PUSH, the stack pointer is decremented with the memory reference.
>... or the kernel.
Yes. That's the real trouble-maker here. Under NT, the kernel knows
it's a stack page faulting, if it's within the 4K memory page
immediately below another stack page. If so, it commits the memory as
stack and the next lower 4K page becomes the "guard page".
>> For example, you could use alloca(). This smells like malloc(), but it
>> allocates memory from the stack instead of the heap (no free()
>> necessary). While this isn't a standard C function, it's supported by
>> GCC which runs on almost any UNIX system. Also, most other UNIX
>> compilers and OS's support it (certainly Solaris does, even if you use
>> SPARCWorks instead of GCC). There _are_ platforms that don't (can't)
>> support alloca(), however.
>
>An approach based on alloca() won't work reliably without knowing
>whether the stack grows up or down, and you were railing against mking
>such an assumtion. It would need something like:
>
>void grow_stack(size_t stack_size)
>{
>#ifdef STACK_GROWS_DOWN
> /* touch the stack at the bottom */
> ((char *)alloca(stack_size))[0] = 42;
>#else
> /* touch the stack at the top */
> ((char *)alloca(stack_size))[stack_size-1] = 42;
>#endif
>}
In my case, the stacks will just be used naturally, once allocated,
which in my case means calculated the task's stack address range. I
don't actually use the stack memory, although I think I'll memset()
the whole lot to a non-zero value at allocation time for debugging
purposes.
>This approach isn't too bad. You need to define STACK_GROWS_DOWN or
>not as appropriate for each platform, but every approach will need at
>least that much.
You can auto-detect that at runtime too, with simple C code, although
I don't like the way they detect that in the alloca implementation.
It depends on a compiler-specific auto variable allocation ordering.
Incidentally, I could not find an implementation of alloca in the GCC
2.95.2 source code that did not use dynamic allocation from the heap
for the memory, using malloc! I'm presuming that I haven't found the
right source file, but all of the implementations I found, including
inside alloca.c, use malloc for the memory. I'm going to have to step
through looking at the assember to see if it's really doing that in
*code*. Right now, my implementation doesn't use alloca. It just
sets the stack pointer as appropriate.
>> If you can't do that, and your compiler supports the 1999 ISO C
>> standard, you can use variable size arrays (even though this is standard
>> and alloca() isn't, I still list alloca() as more portable because not
>> too many compilers support 1999 ISO C yet, while almost all support
>> alloca()). GCC supports these, although I'm not sure if they are 100%
>> standard yet. They're standard enough for you; there just may be some
>> weird corner cases that are non-standard.
>
>There is nothing in that standard that says that VLAs have to be
>allocated off the same stack as other automatic variables. You are
>suggesting ways to stay inside the C standard when accomplishing
>something (messing with stacks in a threading package) that is
>inherently outside the scope of the C standard. You will inevitably
>have to go outside th guarantees of the C standard somewhere along the
>line, so why bother?
Thank you! I thought the author of that post was missing the point.
It was a coroutine package intended to transparently hide multitasking
from the C compiler and runtime library. This would require a little
bit of assember to get/set the stack pointer, and to save the machine
context.
>> [snip]
>>
>> If you can't do any of those things, AFAICT you're SOL and you can't
>> port your program to UNIX, or probably most any other platform. Sorry.
>
>I'm not sure why the OP wants to allocate all of the stacks within the
>initial stack, but it can be done perfectly well on Linux.
As I explained in another post, some OS kernels (NT in particular)
work a lot more smoothly if the OS knows that memory is being used as
stack. Much of my code is cross-platform, so I didn't see a need to
do it differently under Linux. I figured it should work fine, and I
believe it will (is).
It's all working now, except for a small bug in my cross-platform code
(I busted something in the process and have to fix it again). But the
SEGV's are gone, and it's the result of the excellent constructive
feedback in this NG. Thanks folks!
M.
------------------------------
From: MeekGeek <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: Fri, 29 Sep 2000 06:15:04 GMT
On 26 Sep 2000 14:14:48 +0000, David Wragg <[EMAIL PROTECTED]> wrote:
>> Does Linux support the "guard pages" concept implemented by NT on
>> Intel processors?
>
>Does it implement it for you? No, but it supports everything you need
>to implement it yourself. mprotect lets you protect a page so that
>any access will result in a SIGSEGV (LinuxThreads uses this to
>implement guard pages for thread stacks).
Thanks for that juicy tidbit too. We load some third-party libs as
extensions, and it would be nice to protect our server's data when
we're running inside the extension. How expensive is it to turn this
on and off repeatedly? I assume it is a fairly expensive operation.
We could probably support this for extension developers as an option
they could use during the (unstable) development process.
Thanks again,
M.
------------------------------
From: MeekGeek <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: Fri, 29 Sep 2000 06:19:53 GMT
On 27 Sep 2000 01:19:23 -0400, "Paul D. Smith"
<[EMAIL PROTECTED]> wrote:
>Indeed. I didn't read the post carefully enough: I read the code but
>didn't really grasp the user's reasons for wanting to play these games.
>If I had fully realized what he wanted to do I wouldn't have pushed for
>a standard solution, since there obviously isn't one.
Not a problem. It's a complicated story, one I didn't spend much time
explaining initially because I wanted to spare you all the gory
details and thought I could just ask the technical question and get a
straight response. The experienced ones tended to respond with a
"Why?" rather than a "Here's how..." as I would have done as well had
I been on the receiving end. I appreciate what you were trying to do
-- save me a lot of time and learning the hard way. Fortunately (or
unfortunately! :-) I've already learned most of the isues the hard way
over the years. I just had a specific platform-related technical
hurdle to overcome, now achieved.
Thanks everyone!
------------------------------
From: MeekGeek <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: Fri, 29 Sep 2000 06:22:09 GMT
On 28 Sep 2000 00:49:51 +0200, [EMAIL PROTECTED]
(Ulrich Weigand) wrote:
>Actually, using memory on the stack below ESP is rather hazardous
>in any case, even if it were not forbidden by the page fault handler:
>consider that a signal can arrive at any time, and the signal handler
>will by default run on the current stack, starting right below the
>current ESP ...
Good point. Although in my case, my "allocations" were really just
assignments of stack address ranges for each task. The memory below
ESP wasn't actually used until it was used naturally (through
procedure calls, etc) where the ESP was maintained as expected (and
safely).
M.
------------------------------
From: Lew Pitcher <[EMAIL PROTECTED]>
Subject: Re: Interpreterexecutionbug
Date: Thu, 28 Sep 2000 22:13:27 -0400
Danny Reinhold wrote:
>
> Hi linuxfriends,
>
> While exploring linux I found an incompatibility to other unices (at
> least SunOS, Solaris, Irix, Aix and HP-UX behave diffently from
> linux)...
>
> When you start a program in the bash, the program can read it's program
> name in argv[0]. This variable contains the _complete pathname_.
argv[0] is not guaranteed to have anything meaningful in it, but when
it does, it will be the name of the program. It is not guaranteed to
be the complete pathname; sometimes this cannot even be established,
let alone recorded. P'haps some Unices keep this information
available, or even some shells make it available, but the standards do
not require it.
> You can also write scripts that begin with an interpreter-activation
> line like:
>
> #!/usr/local/bin/myproggy
>
> or
>
> #!/usr/bin/env myproggy
>
> Then myproggy just gets the string 'myproggy' in argv[0].
> This behaviour is completely different from that of other unix-like os's
> !
>
> My only reference to this topic is the book 'Advanced programming in the
> UNIX
> environment' by W. Richard Stevens (Addison-Wesley). This book states
> that
> the complete pathname should be in argv[0].
Where in APUE? I've got my copy out, and I can't find any statement of
that sort. In fact, the example in section 7.4 demonstrates an argv[0]
that _does not_ carry a complete path.
'Tis a pity that WRS passed away; he could answer this one easily.
> This incompatibility of linux to an obviously existing standard is very
> ugly.
> Is there any standard definition (ie POSIX) ?
Yes, and Linux adheres to it.
> Is there a workaround, so that myproggy will get the complete pathname
> in argv[0] ???
No.
> It's not very helpful to know that the complete pathname of the script
> containing
> the interpreter-line is passed in argv[1], because I need to know the
> place myproggy
> is installed at...
You'll have to find other ways to locate the installation point of
'myproggy'. Anyway, your purpose may be suspect here; I believe that
you are trying to fix the wrong problem, and should be addressing the
reason you need to know the exact location your program is installed
at.
BTW: have you considered the effects of links (especially hard links)?
If you installed /usr/local/bin/myproggy, then hardlinked
/usr/bin/hisproggy to it, which name should be presented in argv[0]
when hisproggy (which is myproggy) is run?
> Is this considered a bug in the linux-kernel or is it an acceptable
> incompatibility ???
At best, you're complaining about the behaviour of a particular shell
or runtime library (which _could_ load argv[0] with a better guess as
to the program's path, based on where it found it in the $PATH). This
has _nothing_ to do with the kernel.
As for 'acceptable incompatability', do you accept AIX's
incompatability with POSIX and Linux here? You _could_ take action and
fix this 'incompatability' rather than whining that it exists.
> Thanx in advance,
> Danny
--
Lew Pitcher
Master Codewright and JOAT-in-training
------------------------------
From: Mathias Waack <[EMAIL PROTECTED]>
Subject: Re: smp scheduling
Date: 29 Sep 2000 08:33:28 +0200
[EMAIL PROTECTED] writes:
> i have a question about smp scheduling under linux. when i insert a
> module, will the entire init_module function execute on one cpu, or
> can the scheduler step in and switch cpus mid-way? i am disabling
> interrupts during the entire function, and the function does not sleep
> anytime.
Kernel code is not scheduled in the same way as user code. If you
disable all interrupts and never use functions which could sleep,
your code will never interrupted. Use spin_lock_irqsave() for this.
Thats just as I understand it.
Mathias
------------------------------
** 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
******************************
