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
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,
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()
* 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
> 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:
> > 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
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
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
04/08/2009 в 02:26 -0300, Carlos A. M. dos Santos:
> On Mon, Aug 3, 2009 at 4:56 PM, Alex Zimnitsky wrote:
> > Hello, freebsd-hackers
> >
> > my system is 7.2-RELEASE
> >
> > there is a which is included in a lot of headers, but a
> > few of them instead of including it, generate "#error this file
This is amazing! Have you considered an article for publication based
on your experiences? Perhaps a handbook article?
This will be very helpful going forward.
(Although, I do kind of wish it was a "instructions fits on
the back of a napkin" kind of operation.) :)
thanks again!
-Alfred
* Gi
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
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:
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
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:
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(
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
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
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
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-
> 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.
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
_
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
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
--
Hi,
granted it took me less then a minute to figure it out, but the error is kind
of not helping:
% mount -t msdofs /dev/label/camera ~/camera
mount: /dev/label/camera : Operation not supported by device
I would expect something along the lines of "unknown file system type". Is
this fixable?
--
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
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 2009-08-04 22:45, Mel Flynn wrote:
> % mount -t msdofs /dev/label/camera ~/camera
> mount: /dev/label/camera : Operation not supported by device
>
> I would expect something along the lines of "unknown file system type". Is
> this fixable?
Yes, just use "msdosfs" instead. ;) That said, it lo
> 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
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
On Tuesday 04 August 2009 13:43:24 Dimitry Andric wrote:
> On 2009-08-04 22:45, Mel Flynn wrote:
> > % mount -t msdofs /dev/label/camera ~/camera
> > mount: /dev/label/camera : Operation not supported by device
> >
> > I would expect something along the lines of "unknown file system type".
> > Is t
30 matches
Mail list logo
