Messages in this thread | | | Date | Mon, 16 Nov 1998 18:12:38 +0000 | From | Mark Lord <> | Subject | Re: Hacking ide.c for better pcmcia support... |
| |
Colin Plumb wrote: .. > The problem is that if something ends up holding the mount open, then > ide_unregister fails, and since it returns void, the failure goes unreported > and the kernel ends up stuck in a bad state. > > The lack of umount -f is certainly a problem, but I'd also like unregister_ide > to *do* something sensible if the device is busy.
Yeah, I noticed that too, but it is a user-bug, not a kernel-bug.
Nicer behaviour for PCMCIA CompactFlash-ATA devices would be a useful thing for 2.3.xx. There is a CODE FREEZE on 2.1.xxx now.
The required solution is to parameterize the internal IDE timeouts on a per-drive basis. That way, the pcmcia utilities could set the timeouts to zero for CompactFlash-ATA-flash cards, but use different values for CompactFlash-ATA-disk cards (like the IBM 230MB thingie).
With tiny timeouts for true flash memory, the zombie requests would die rather rapidly, unlike today.
> One question: in the ide_drive_t structure, there are already 16 bits > allocated in the bit-field range. (If FAKE_FDISK_FOR_EZDRIVE is > set.) Should I just add another flag there? Is there a reason why > the booleans before that are bytes and not bits?
The more frequently-accessed bools are bytes for faster-access, the rest are bits to save memory. I was frugal about memory at one time.. :) -- mlord@pobox.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |