On Friday 24 December 2004 07:13 am, Jan Engelhardt wrote:
> >> What should I use instead? A semaphore?
> >
> >You shouldn't have unrelated kernel threads waiting for a user
> >process at all, so this sounds like a design problem, regardless
> >of which mutual exclusion primitive you use. (Bear in
On Fri, 24 Dec 2004, Jan Engelhardt wrote:
> >> What should I use instead? A semaphore?
>
> >You shouldn't have unrelated kernel threads waiting for a user
> >process at all, so this sounds like a design problem, regardless
> >of which mutual exclusion primitive you use. (Bear in mind that I
> >
>> I wanted that the device can only be opened once,
>> and holding a mutex while it
>> is open seemed like a simple idea. (Since
>> mtx_trylock() will then fail -- easy
>> to implement.)
>
>An even more simpler idea would be to set a flag in
>the softc data structure on initialization, so as to
>a
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> >> What should I use instead? A semaphore?
>
> >You shouldn't have unrelated kernel threads waiting
> for a user
> >process at all, so this sounds like a design
> problem, regardless
> >of which mutual exclusion primitive you use. (Bear
> in mind
>> What should I use instead? A semaphore?
>You shouldn't have unrelated kernel threads waiting for a user
>process at all, so this sounds like a design problem, regardless
>of which mutual exclusion primitive you use. (Bear in mind that I
>haven't actually looked into what you're trying to do.)
On Fri, Dec 24, 2004, Jan Engelhardt wrote:
> >1) In kmi_fops.d_open():
> >|if(!mtx_trylock(&Open_lock)) { return EBUSY; }
> >|return 0;
> >
> >this can not work. You cannot return to userland with a lock acquired.
>
> So? The full code also contains a uio_read() function. If I release the
>1) In kmi_fops.d_open():
>|if(!mtx_trylock(&Open_lock)) { return EBUSY; }
>|return 0;
>
>this can not work. You cannot return to userland with a lock acquired.
So? The full code also contains a uio_read() function. If I release the
lock in uio_read(), no crash happens. It's just in uio_c
On Thu, 23 Dec 2004, Jan Engelhardt wrote:
> Hello list,
>
>
> for some reason, the Freebsd (5.3) kernel crashes whenever I do "simple
> operations", in conjunction with a (self-written) kernel module.
>
> I have trimmed the original program down from approx 120 KB to the 7 KB (lots
> of spacing a
On Thursday 23 December 2004 22:44, Jan Engelhardt wrote:
> for some reason, the Freebsd (5.3) kernel crashes whenever I do "simple
> operations", in conjunction with a (self-written) kernel module.
>
> I have trimmed the original program down from approx 120 KB to the 7 KB
> (lots of spacing and t
Hello list,
for some reason, the Freebsd (5.3) kernel crashes whenever I do "simple
operations", in conjunction with a (self-written) kernel module.
I have trimmed the original program down from approx 120 KB to the 7 KB (lots
of spacing and tabs :) to follow the common advise to find the shor
10 matches
Mail list logo
