[lkml]   [2005]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC: i386: kill !4KSTACKS
    On Tuesday 06 September 2005 18:28, Roland Dreier wrote:
    > Daniel> There are only two stacks involved, the normal kernel
    > Daniel> stack and your new ndis stack. You save ESP of the kernel
    > Daniel> stack at the base of the ndis stack. When the Windows
    > Daniel> code calls your api, you get the ndis ESP, load the kernel
    > Daniel> ESP from the base of the ndis stack, push the ndis ESP so
    > Daniel> you can get back to the ndis code later, and continue on
    > Daniel> your merry way.
    > [...]
    > Daniel> You will allocate your own stack once on driver
    > Daniel> initialization.
    > I'm not quite sure it's this trivial. Obviously there are more than
    > two stacks involved, since there is more than one kernel stack! (One
    > per task plus IRQ stacks) This is more than just a theoretical
    > problem. It seems entirely possible that more than one task could
    > be in the driver, and clearly they each need their own stack.

    Semaphore :-)

    Do you expect this to be heavily contended? On a very quick run through the
    code, it seems you don't hold any spinlocks going into the driver from
    process context. Interrupts... they better fit into a 4K stack or it's game
    over. Preemption while on the ndis stack... you can always disable
    preemption in this region, but the semaphore should protect you. Task killed
    while preempted... I dunno.

    > So it's going to be at least a little harder than allocating a single
    > stack for NDIS use when the driver starts up.
    > I personally like the idea raised elsewhere in this thread of running
    > the Windows driver in userspace by proxying interrupts, PCI access,
    > etc. That seems more robust and probably allows some cool reverse
    > engineering hacks.

    I expect the userspace approach will be a lot more work and a lot more
    overhead too, but then again it sounds like loads of fun.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-09-07 02:04    [W:0.028 / U:56.820 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site