>Here is the patch.
Sorry, at least most of the patch was there. Here is the rest:
diff -r -u -N -b linux-2.4.5.ac16/include/linux/fs.h
linux-2.4.5.ac16.patched/include/linux/fs.h
--- linux-2.4.5.ac16/include/linux/fs.h Tue Jun 19 15:12:50 2001
+++ linux-2.4.5.ac16.patched/include/linux/fs.h Tu
Dear all,
The ac-kernel series include a check in default_llseek()
to not set the file position beyond the file systems
maximum file size.
This check should be done only for regular files, e.g. for
a device special file the test does not make sense.
Alan suggested that we remove the check from
t
Hi,
the ac series include a check in default_llseek() to not set the
file position beyond the file systems maximum file size.
This check should be done only for regular files, e.g. for
a device special file the test does not make sense.
Either we change the check or we have to write a llseek
met
>So I think it's reasonable to use keventd as `kinit', if you like.
>Something which knows how to launch and reap kernel daemons, and
>which provides a known environment to them.
>
>A kernel API function (`kernel_daemon'?) which does all this
>boilerplate is needed, I think.
>
I completely agree.
>> - When started during boot (low PID (9)) It becomes a zombie
>> - When started from a process that quits after sending the ioctl,
>>it is correctly "garbage collected".
>> - When started from a process that stays around, it becomes
>>a zombie too
>Take a look at kernel/kmod.c:call_
>>The stuff done in daemonize() and the exit_files could need
>>the kernel lock. At least on some 2.2.x version it does,
>>I did not check whether it is still needed on 2.4.
>
>Well, I don't really plan to backport this to 2.2.x. I'll
>try to see if my problem is related to the lack of kernel
>loc
Hi,
>> http://www.scs.ch/~frey/linux/kernelthreads.html
>Could you explain me a bit why you need the lock_kernel ? My probe
>thread is already protected by some atomic ops, but I'm considering
>changing them to semaphores. Is there any need for the bkl to be taken
>when calling daemonize or is th
ds,
Martin
--
Supercomputing Systems AG email: [EMAIL PROTECTED]
Martin Frey web: http://www.scs.ch/~frey/
at Compaq Computer Corporation phone: +1 603 884 4266
ZKO2-3P09, 110 Spit Brook Road, Nashua, NH 03062
-
To unsubscribe from this list: send the line "unsubs
ointer to a page struct, not an address
>> as in 2.2.x.
--
Supercomputing Systems AG email: [EMAIL PROTECTED]
Martin Frey web: http://www.scs.ch/~frey/
at Compaq Computer Corporation phone: +1 603 884 4266
ZKO2-3P09, 110 Spit Brook Road, Nashua, NH 03062
-
To
9 matches
Mail list logo
