On Tuesday 04 August 2009 12:57:25 pm Dag-Erling Smørgrav wrote:
> Ed Schouten writes:
> > Maslan writes:
> > > However, when i checked the pid & tid of the new created thread it
> > > was not the same as the parent nor as the proc0 & thread0
> > I am not sure, but sharing another process's addre
Maslan wrote:
When you did kern_open() without creating kernel thread, it worked,
because kern_open() used file descriptor table from your current
(userland) process. In FreeBSD 7.x kthread_create() creates a process
without file descriptor table, so you can't use kern_open() and actually
you sho
> When you did kern_open() without creating kernel thread, it worked,
> because kern_open() used file descriptor table from your current
> (userland) process. In FreeBSD 7.x kthread_create() creates a process
> without file descriptor table, so you can't use kern_open() and actually
> you shouldn't
On Mon, Aug 03, 2009 at 09:25:27PM +, Maslan wrote:
> No my code doesn't work, I thought it may be because that soaccept()
> -which is not found in man 9- is non-blocking, so i've to put my code
> in a thread.
> Now i got another problem, when I open a text file from this thread,
> the kernel c
On Monday 03 August 2009 5:25:27 pm Maslan wrote:
> No my code doesn't work, I thought it may be because that soaccept()
> -which is not found in man 9- is non-blocking, so i've to put my code
> in a thread.
> Now i got another problem, when I open a text file from this thread,
> the kernel crashes
Maslan wrote:
Guys,
Here is the code, just scroll down and change kthread_create2() to
kthread_create() and it will crash
NOTE: i'm still working on the socket part, u can commend it.
Something wrong with proc0, and I can't figure it out
--
Dag-Erling Smørgrav wrote:
Julian Elischer writes:
and kernel threads have not file descriptors (I think) so it
would crash...
Threads don't have filedesc tables. Processes have filedesc tables. In
theory, his thread is associated with proc0, which *does* have a
properly initialized fi
Guys,
Here is the code, just scroll down and change kthread_create2() to
kthread_create() and it will crash
NOTE: i'm still working on the socket part, u can commend it.
Something wrong with proc0, and I can't figure it out
khttp.c
Description: Binary data
_
> kernel threads may not have a file descriptor table.
> so kern_open may not work on kernel processes..
> (just speculating)
But the module's main thread belogs to proc, why this process could
use kern_open() and proc0 don't
___
freebsd-hackers@freebsd.
Julian Elischer writes:
> and kernel threads have not file descriptors (I think) so it
> would crash...
Threads don't have filedesc tables. Processes have filedesc tables. In
theory, his thread is associated with proc0, which *does* have a
properly initialized filedesc table.
DES
--
Dag-
Ed Schouten writes:
> Maslan writes:
> > However, when i checked the pid & tid of the new created thread it
> > was not the same as the parent nor as the proc0 & thread0
> I am not sure, but sharing another process's address space doesn't have
> to imply it shares the same pid, right?
The man pa
Ed Schouten wrote:
Hi,
* Maslan wrote:
man kthread says:
The kthread_create() function is used to create a kernel thread. The new
thread shares its address space with process 0, the swapper process, and
^^^
runs in kernel mode only
Maslan wrote:
I'm getting crazy,
I don't know why kern_open() works in the module's main thread, but
when I use it in another thread created by kthread_create() it crashes
the kernel ???
kernel threads may not have a file descriptor table.
so kern_open may not work on kernel processes..
(just
Maslan wrote:
OpenKETA has its own kthread_create() with a little modification from
kthread_create(), it associates the new thread with curthread not with
the thread0.
hey that's horrible...
(overiding a kernel symbol)
See /usr/sys/kern/kern_kthread.c: kthread_create()
error = fork1(
Max Laier writes:
> IIRC, kernel threads don't have root.
You mean proc0->fdp->fd_rdir is NULL? That shouldn't make any
difference, the kernel panics before it dereferences fd_rdir.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd
Maslan wrote:
Is it possible to call kern_open() from within a kernel thread anyway?
I think yes, It worked on the parent thread before creating a new kthread.
See OpenKETA source, its using the same approach.
I wouldn't count on that..
kern_open() depends on a file descriptor table, right
Maslan writes:
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address = 0x10
> fault code= supervisor read, page not present
> instruction pointer = 0x20:0xc085935b
> [...]
> #7 0xc085935b in namei (ndp=0xe6cd3bc8) at /usr/src/sys/kern/vfs
Maslan wrote:
yes kio http://people.freebsd.org/~pjd/misc/kernio/
However, It's outdated.
No, man 9 ALQ is your friend. Works a treat.
Cheers,
Lawrence
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hac
OpenKETA has its own kthread_create() with a little modification from
kthread_create(), it associates the new thread with curthread not with
the thread0.
See /usr/sys/kern/kern_kthread.c: kthread_create()
error = fork1(&thread0, RFMEM | RFFDG | RFPROC | RFSTOPPED | flags,
pages
yes kio http://people.freebsd.org/~pjd/misc/kernio/
However, It's outdated.
On Tue, Aug 4, 2009 at 9:56 AM, Ed Schouten wrote:
> * Maslan wrote:
>> > Is it possible to call kern_open() from within a kernel thread anyway?
>> I think yes, It worked on the parent thread before creating a new kthread
* Maslan wrote:
> > Is it possible to call kern_open() from within a kernel thread anyway?
> I think yes, It worked on the parent thread before creating a new kthread.
> See OpenKETA source, its using the same approach.
> > kern_open() depends on a file descriptor table, right?
> Yes, it returns a
> Is it possible to call kern_open() from within a kernel thread anyway?
I think yes, It worked on the parent thread before creating a new kthread.
See OpenKETA source, its using the same approach.
> kern_open() depends on a file descriptor table, right?
Yes, it returns a fd in the curthread->td_re
* Maslan wrote:
> I'm getting crazy,
>
> I don't know why kern_open() works in the module's main thread, but
> when I use it in another thread created by kthread_create() it crashes
> the kernel ???
Is it possible to call kern_open() from within a kernel thread anyway?
kern_open() depends on a f
I'm getting crazy,
I don't know why kern_open() works in the module's main thread, but
when I use it in another thread created by kthread_create() it crashes
the kernel ???
On Tue, Aug 4, 2009 at 9:30 AM, Ed Schouten wrote:
> Hi,
>
> * Maslan wrote:
>> man kthread says:
>> The kthread_create()
Hi,
* Maslan wrote:
> man kthread says:
> The kthread_create() function is used to create a kernel thread. The new
> thread shares its address space with process 0, the swapper process, and
^^^
> runs in kernel mode only.
>
> However,
man kthread says:
The kthread_create() function is used to create a kernel thread. The new
thread shares its address space with process 0, the swapper process, and
runs in kernel mode only.
However, when i checked the pid & tid of the new created thread it was
not the same as the parent
On Tuesday 04 August 2009 00:03:40 Dag-Erling Smørgrav wrote:
> Dag-Erling Smørgrav writes:
> > One thing that springs to mind is that kern_open() will dereference
> > td->td_proc, and AFAIK kthread_create() does not associate the thread
> > with a process.
>
> This is wrong, and contradicts what
I'm running out 7.2-RELEASE-p2
Here is my bt
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see
Dag-Erling Smørgrav writes:
> One thing that springs to mind is that kern_open() will dereference
> td->td_proc, and AFAIK kthread_create() does not associate the thread
> with a process.
This is wrong, and contradicts what I wrote further down. Just ignore
it.
DES
--
Dag-Erling Smørgrav - d..
Maslan writes:
> Now i got another problem, when I open a text file from this thread,
> the kernel crashes, I'm sure that its the thread.
If the kernel crashed, I assume you have a dump and a backtrace and can
tell us *where* it crashed?
One thing that springs to mind is that kern_open() will de
No my code doesn't work, I thought it may be because that soaccept()
-which is not found in man 9- is non-blocking, so i've to put my code
in a thread.
Now i got another problem, when I open a text file from this thread,
the kernel crashes, I'm sure that its the thread.
kthread_create((void *)thre
[please cc: the list]
Maslan writes:
> man 9 sosend:
> Data may be sent directly from kernel or user memory via the uio
> argument, or as an mbuf chain via top, avoid- ing a data copy.
> Only one of the uio or top pointers may be non-NULL
Hmm, I missed that part. It never occurre
Maslan writes:
> I can't find useful information on sosend(), I would like to send some
> plain text through sosend()
> Here is what i got so far, I don't know how to use mbuf with sosend()
> to achieve this.
You need to stick your "plain text" in an mbuf. See 'man 9 socket' and
'man 9 mbuf' for
Hello Guys,
I can't find useful information on sosend(), I would like to send some
plain text through sosend()
Here is what i got so far, I don't know how to use mbuf with sosend()
to achieve this.
ret = socreate(PF_INET, &s, SOCK_STREAM, IPPROTO_TCP,
curthread->td_ucred, curthread);
34 matches
Mail list logo
